Mint 21.3 again

[pinnerite]

I had to give up on Mint 22.0. It is user-hostile.
I had installed it twice. Th second time wiping the drive.
(I had a clone backup).

I downloaded ubuntu 24.10.
That was even more hostle. It wouldn't even install.

So I have gone back to Mint 21.3. Very smooth installation.

I now have the hassle of configuring MythTV.
Only because once I connect the backup drive, I will have to boot from
a live flash drive on Parted Magic. A bit slow.

I will have a long time to wait for Mint 23.

I think I ought to report the missing snd_hda_intel module as a bug.
I'll look up how to do it.

[Mike Easter]

Post by pinnerite
I had to give up on Mint 22.0. It is user-hostile.
I think I ought to report the missing snd_hda_intel module as a bug.
I'll look up how to do it.

That won't do anybody any good; the module is there.

Booting a live LM Cinn 22:

$ inxi -S
System:
Host: mint Kernel: 6.8.0-38-generic arch: x86_64 bits: 64
Desktop: Cinnamon v: 6.2.7 Distro: Linux Mint 22 Wilma

$ lsmod | grep snd_hda_intel
snd_hda_intel 61440 1
snd_intel_dspcfg 36864 1 snd_hda_intel
snd_hda_codec 217088 3
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core 151552 4
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_pcm 200704 3 snd_hda_intel,snd_hda_codec,snd_hda_core
snd 147456 14
snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm,snd_rawmidi

(Mind any wrapping here)

[Mike Easter]

inxi -A
If you're unable to get the sound working, you can try to go back to the older sound server called PulseAudio.
apt purge pipewire pipewire-bin
systemctl enable --user pulseaudio
sudo reboot

Of course, reboot doesn't work for those of us just doing plain live,
but some 'reboots' can be accomplished by logout/login; while some
others can't.

My inxi says my live LM 22 is pipewire + snd_hda_intel while my actual
cpu is an older AMD.

$ inxi -CA
CPU:
Info: dual core model: AMD Athlon II X2 B24 bits: 64 type: MCP cache:
L2: 2 MiB
Speed (MHz): avg: 800 min/max: 800/3000 cores: 1: 800 2: 800
Audio:
Device-1: AMD SBx00 Azalia driver: snd_hda_intel
API: ALSA v: k6.8.0-38-generic status: kernel-api
Server-1: PipeWire v: 1.0.5 status: active

[pinnerite]

On Wed, 11 Dec 2024 15:20:08 -0800

Post by Mike Easter

inxi -A
If you're unable to get the sound working, you can try to go back to the older sound server called PulseAudio.
apt purge pipewire pipewire-bin
systemctl enable --user pulseaudio
sudo reboot

Of course, reboot doesn't work for those of us just doing plain live,
but some 'reboots' can be accomplished by logout/login; while some
others can't.
My inxi says my live LM 22 is pipewire + snd_hda_intel while my actual
cpu is an older AMD.
$ inxi -CA
L2: 2 MiB
Speed (MHz): avg: 800 min/max: 800/3000 cores: 1: 800 2: 800
Device-1: AMD SBx00 Azalia driver: snd_hda_intel
API: ALSA v: k6.8.0-38-generic status: kernel-api
Server-1: PipeWire v: 1.0.5 status: active
--
Mike Easter

I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

Thanks, Alan

[Paul]

Post by pinnerite
On Wed, 11 Dec 2024 15:20:08 -0800

Post by Mike Easter

inxi -A
If you're unable to get the sound working, you can try to go back to the older sound server called PulseAudio.
apt purge pipewire pipewire-bin
systemctl enable --user pulseaudio
sudo reboot

Of course, reboot doesn't work for those of us just doing plain live,
but some 'reboots' can be accomplished by logout/login; while some
others can't.
My inxi says my live LM 22 is pipewire + snd_hda_intel while my actual
cpu is an older AMD.
$ inxi -CA
L2: 2 MiB
Speed (MHz): avg: 800 min/max: 800/3000 cores: 1: 800 2: 800
Device-1: AMD SBx00 Azalia driver: snd_hda_intel
API: ALSA v: k6.8.0-38-generic status: kernel-api
Server-1: PipeWire v: 1.0.5 status: active
--
Mike Easter

I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.
Thanks, Alan

Verify the sha256sum of the thing.

Paul

[Mike Easter]

Post by pinnerite
I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

I *always* check the hash when I dl .iso/s. In the past I have been
very dutiful about checking the .sig, but that is MUCH more of a pain
because of the variety of approaches that the various distro providers
take to key availability and because it is quite a bit of trouble on my
end to maintain the keys. So now I only go to that much trouble for the
'fun' of doing it. (ie not so much fun)

[Paul]

Post by pinnerite
I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

I *always* check the hash when I dl .iso/s.  In the past I have been very dutiful about checking the .sig, but that is MUCH more of a pain because of the variety of approaches that the various distro providers take to key availability and because it is quite a bit of trouble on my end to maintain the keys.  So now I only go to that much trouble for the 'fun' of doing it.  (ie not so much fun)

Some of the distros on DVD, they actually verify the
materials as they come off the DVD. if the DVD was
to be corrupted somehow, some of the setups can now
detect that, in flight. But that is also adding
a lot to the boot time. So much of the DvD is
being read, that if you are actually *using* a DVD,
you'd select the TORAM=yes option. This means, to
install Ubuntu that way, you need 6GB+2GB of RAM or so.

If you have a large enough machine, you can do a
TORAM=yes to buffer the media in RAM, and those
same checksum routines will verify the RAM content
is correct, before the installation step starts.

It's not all quite as open loop as it used to be.
People are adding in some checks to avoid corruption.
Even though there is no proposed corruption mechanism.

But all that being said, I would definitely be
verifying the overall ISO download sha256sum . The CPU can
do that at 300MB/sec and it doesn't take that long
to check the ISO you downloaded.

Paul

[David]

Post by Paul

Post by pinnerite
I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

I *always* check the hash when I dl .iso/s.  In the past I have been very dutiful about checking the .sig, but that is MUCH more of a pain because of the variety of approaches that the various distro providers take to key availability and because it is quite a bit of trouble on my end to maintain the keys.  So now I only go to that much trouble for the 'fun' of doing it.  (ie not so much fun)

Some of the distros on DVD, they actually verify the
materials as they come off the DVD. if the DVD was
to be corrupted somehow, some of the setups can now
detect that, in flight. But that is also adding
a lot to the boot time. So much of the DvD is
being read, that if you are actually *using* a DVD,
you'd select the TORAM=yes option. This means, to
install Ubuntu that way, you need 6GB+2GB of RAM or so.
If you have a large enough machine, you can do a
TORAM=yes to buffer the media in RAM, and those
same checksum routines will verify the RAM content
is correct, before the installation step starts.
It's not all quite as open loop as it used to be.
People are adding in some checks to avoid corruption.
Even though there is no proposed corruption mechanism.
But all that being said, I would definitely be
verifying the overall ISO download sha256sum . The CPU can
do that at 300MB/sec and it doesn't take that long
to check the ISO you downloaded.
Paul

How often have you found a checksum to be incorrect, Paul?

[Paul]

Post by David

Post by Paul

Post by pinnerite
I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

I *always* check the hash when I dl .iso/s.  In the past I have been very dutiful about checking the .sig, but that is MUCH more of a pain because of the variety of approaches that the various distro providers take to key availability and because it is quite a bit of trouble on my end to maintain the keys.  So now I only go to that much trouble for the 'fun' of doing it.  (ie not so much fun)

Some of the distros on DVD, they actually verify the
materials as they come off the DVD. if the DVD was
to be corrupted somehow, some of the setups can now
detect that, in flight. But that is also adding
a lot to the boot time. So much of the DvD is
being read, that if you are actually *using* a DVD,
you'd select the TORAM=yes option. This means, to
install Ubuntu that way, you need 6GB+2GB of RAM or so.
If you have a large enough machine, you can do a
TORAM=yes to buffer the media in RAM, and those
same checksum routines will verify the RAM content
is correct, before the installation step starts.
It's not all quite as open loop as it used to be.
People are adding in some checks to avoid corruption.
Even though there is no proposed corruption mechanism.
But all that being said, I would definitely be
verifying the overall ISO download sha256sum . The CPU can
do that at 300MB/sec and it doesn't take that long
to check the ISO you downloaded.
    Paul

How often have you found a checksum to be incorrect, Paul?

Never :-)

I've had two backup images with bad integrity, so
there has been a case here of something getting corrupted,
but that was traceable to bad RAM being installed in
the machine during the backup. The file integrity is
generally speaking, pretty good.

But every computer room has different stories to tell,
which is why you do the occasional check to be sure.

The distros I was referring to, they do internal
checks on packages, and checksum them while you
are running a LiveDVD. And that can add a considerable
delay to the desktop appearing.

Paul

[David]

Post by Paul

Post by David

Post by Paul

Post by pinnerite
I think my iso download may have been at fault. I haven't had time to
check it but I am happy with 21.3 for now.

I *always* check the hash when I dl .iso/s.  In the past I have been very dutiful about checking the .sig, but that is MUCH more of a pain because of the variety of approaches that the various distro providers take to key availability and because it is quite a bit of trouble on my end to maintain the keys.  So now I only go to that much trouble for the 'fun' of doing it.  (ie not so much fun)

Some of the distros on DVD, they actually verify the
materials as they come off the DVD. if the DVD was
to be corrupted somehow, some of the setups can now
detect that, in flight. But that is also adding
a lot to the boot time. So much of the DvD is
being read, that if you are actually *using* a DVD,
you'd select the TORAM=yes option. This means, to
install Ubuntu that way, you need 6GB+2GB of RAM or so.
If you have a large enough machine, you can do a
TORAM=yes to buffer the media in RAM, and those
same checksum routines will verify the RAM content
is correct, before the installation step starts.
It's not all quite as open loop as it used to be.
People are adding in some checks to avoid corruption.
Even though there is no proposed corruption mechanism.
But all that being said, I would definitely be
verifying the overall ISO download sha256sum . The CPU can
do that at 300MB/sec and it doesn't take that long
to check the ISO you downloaded.
    Paul

How often have you found a checksum to be incorrect, Paul?

Never :-)
I've had two backup images with bad integrity, so
there has been a case here of something getting corrupted,
but that was traceable to bad RAM being installed in
the machine during the backup. The file integrity is
generally speaking, pretty good.
But every computer room has different stories to tell,
which is why you do the occasional check to be sure.
The distros I was referring to, they do internal
checks on packages, and checksum them while you
are running a LiveDVD. And that can add a considerable
delay to the desktop appearing.

That's good to know!

Thank you, Paul.

[azigni]

FWIW, I have found Torrents to be corrupted, though not often. If I
download using torrent I always do a checksum to verify.