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: > >> 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.
> > Please tell if you make booting with metadata 1.2 work. > > I havn't tested that. > It is NOT supported. The kernel has no code to do so, you need an > initramfs. That said, nowadays I believe you can actually load the > initramfs into the kernel so it's one monolithic blob ... With my patch from yesterday (corrected today), you can indeed instruct the kernel to assemble RAID devices with metadata 1.2. It wasn't a difficult patch by any means. One wonders why the md kernel team hadn't done it a long time ago. initramfs's are ugly ungainly things, often many times larger than the kernel itself, and appear not to have been well thought out. They are surely a source of complication and error, and are best avoided, if possible. I've never actually built one myself, and will go to some lengths, like hacking the kernel, to avoid it. > 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. > I guess it was the fact your rescue disk booted from CDROM or whatever > made THAT sda, and pushed the other disks out of the way. No, you've misunderstood my situation. What got scrambled by the rescue disc was the assignment of /dev/md127 and /dev/md126. This has been solved by explicitly specifying the assignment with md parameters in the kernel command line. So now my system boots just fine, even after the assignment of the devices (the "preferred-minor" field in the MD superblock) has been scrambled by the rescue disk. > 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. > It just so happens that the "seed" rarely changes, so in normal use > the same values happen to get chosen every time - until something DOES > change, and then you wonder why everything falls over. The same is > also true of md127, md126 et al. If your raid counts up from md1, md2 > etc then those I believe are stable, but I haven't seen them for > pretty much the entire time I've been involved in mdraid (maybe a > decade or so?) > 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. 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. > Cheers, > Wol -- Alan Mackenzie (Nuremberg, Germany).
