https://bugzilla.novell.com/show_bug.cgi?id=832501
https://bugzilla.novell.com/show_bug.cgi?id=832501#c6
Neil Brown
If your /boot is on a separate raid device from your /, mkinitrd does not add any information in the initrd to start the raid device, so boot will fail.
Hi Peter, I'm a bit confused by this part of the problem description. As I understand it, the initrd does not need to access the /boot filesystem at all. The boot loader (e.g. grub) does of course so that it can load the kernel and the initrd, But all the initrd need access to is the root filesystem and the swap partition. Once it mounts root, the scripts in there will take over to mount /boot and anything else. Clearly you are having a problem and it does seem to be related to the md device containing /boot, but I think it needs to be fixed in the regular boot scripts, not in the initrd. Handling freshly degraded arrays at boot is somewhat tricky with the dependency driven boot sequence that systemd uses. As devices are discovered, udev runs "mdadm -I $DEVICE" and mdadm incrementally assembles the arrays. Once all components are there the array is started. But if all components never arrive, the array will never be started with just that mechanism. To address this you can run "mdadm -IRs" which essentially says "all devices have arrived, time to start any remaining md arrays which are degraded". systemd need to do this when it times out waiting for a device. But I don't know how to tell it (not that I have really looked recently). The initrd does have a call to "mdadm -IRs" half way through timing out for the root device. This is why your boot works if you tell the initrd to assemble the boot device. But that isn't really the right fix. I'll do some reading about systemd and see if I can figure out how to give it an action to perform on timeout. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.