Three and a bit months later... On Sun, Dec 22, 2024 at 13:43:08 +0000, Alan Mackenzie wrote: > Hello, Wol.
> On Sun, Dec 22, 2024 at 12:02:49 +0000, Wols Lists wrote: > > On 20/12/2024 17:44, k...@aspodata.se wrote: [ .... ] > > By the way, as to the other point of putting /dev/sda etc on the > > kernel command line, it's the kernel that's messing up and > > scrambling which physical disk is which logical sda sdb et al > > device, so explicitly specifying that will have exactly NO effect > > when your hardware/software combo changes again. > /dev/sda (or, in my case, /dev/nvme0n1), etc. don't, in my experience, > get scrambled by the kernel. They're plugged into the same sockets on > the motherboard from day to day, so unless you're physically inserting > or removing them, you won't have trouble. [ .... ] > > sda, sdb, sdc et al are allocated AT RANDOM by the kernel. > Only in the sense that it may be difficult on a new machine to predict > in advance which physical HDD becomes which sdx. As I said, the > assignment of physical drives to logical devices is repeatable, and > doesn't change from day to day. Wol was right and I was wrong. My two SSDs get allocated randomly to /dev/nvme0n1 and /dev/nvme1n1. Most of the time I didn't notice this since all my partitions apart from /boot (and swap) are RAID-1 devices using the kernel's md facility. However, today I built a new kernel (6.12.21) and wrote it to /boot. Unfortunately, this was on the wrong SSD, because of the scrambling Wol warned me about in December. So I couldn't find the syslinux configuration file which is only on the "first" SSD. It took me most of the day to figure out what had happened. In the end, I fixed the problem by using the UUID for /dev/nvme0n1p1 in the entry for /boot in /etc/fstab. The other partitions which get assembled into MD devices are fine, since it doesn't matter which order they're in. [ .... ] > > You need to use those UUID/GUID things. I know it's a hassle finding out > > whether it's a guid or a uuid, and what it is, and all that crud, but > > trust me they don't change, you can shuffle your disks, stick in another > > SATA card, move it from SATA to USB (BAD move - don't even think of it > > !!!), and the system will still find the correct disk. Indeed. > The trouble being that a kernel command line, or /etc/fstab, using lots > of these is not human readable, and hence is at the edge of > unmaintainability. This maintenance difficulty surely outweighs the > rare situation where the physical->logical assignment changes due to a > broken drive. That's what we've got rescue disks for. So I now have an /etc/fstab which isn't properly human readable. I regret this, but getting the correct partition mounted on /boot was more important. > > Cheers, > > Wol -- Alan Mackenzie (Nuremberg, Germany).
