Re: [gentoo-user] Fun with mdadm (Software RAID)

[Alan Mackenzie <acm@muc.de>]

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, karl@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).