Hello, Karl. On Fri, Dec 20, 2024 at 15:50:53 +0100, k...@aspodata.se wrote: > Alan Mackenzie: > ... > > The cause was me booting up the machine with a rescue disk. This > > assembled my RAID partitions /dev/md127 and /dev/md126 reversed, but > > also wrote those wrong identifiers, 126 and 127, into the "preferred > > minor" field of the partitions' super blocks. In essence, they got > > swapped. > ... > > Just for the record, all my RAID arrays have metadata version 0.90, the > > (old fashioned) one that allows auto-assembly by the kernel without the > > need of an initramfs.
> > The moral of the story: if your system uses software RAID, be careful > > indeed before you boot up with a rescue disk. > So, why don't you simple add "root=902 md=2,/dev/sda2,/dev/sdb2" or similar to > your boot loader kernel command line ? Because I didn't know about it. I found out about it this morning, and immediately tested it by setting up an "md=126,/dev/nvme0n1p4,/dev/nvme1n1p4" on the kernel command line, using the rescue disk to make the "preferred minor"s wrong, and testing it. It worked! If I understand things correctly, with this mechanism one can have the kernel assemble the RAID arrays at boot up time with a modern metadata, but still without needing the initramfs. My arrays are still at metadata 0.90. > /// > And... what is the need for dynamic minors now when dev_t is 32bits: Dynamic minors? I don't think I follow you, here. > $ grep dev_t /Net/git/linux-stable/include/linux/types.h > typedef u32 __kernel_dev_t; > typedef __kernel_dev_t dev_t; > $ > and we have 20 bits minors: > $ grep -A1 MINORBITS /Net/git/linux-stable/include/linux/kdev_t.h > #define MINORBITS 20 > #define MINORMASK ((1U << MINORBITS) - 1) > #define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS)) > #define MINOR(dev) ((unsigned int) ((dev) & MINORMASK)) > #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany).
