The /etc/init.d/mdraid rc script suffers from a race condition whereby the stable-named /dev/disk/... device symlinks setup by udev may not be setup by the time mdraid is running, at which point the mdadm command it runs will fail, and the init system continues on to other scripts which may suffer the same fate. For example, /etc/init.d/fsck. mdraid's depends cause the fsck init script to run after mdraid. But if mdraid exits without having assembled the arrays (or without having ensured they're assembled), fsck may attempt (and fail) to run checks on a not-yet-existent (or not yet fully assembled) md device (assuming you have such a device in fstab and it's enabled for checks). For me, this resulted in my /home RAID array not being mounted after bootup. If mdraid declares `need udev-settle` in its `depend()` function, then this won't be a problem anymore. One could certainly add this themselves via a rc_need="udev-settle" line in /etc/conf.d/mdraid, but for everyone's benefit I think it should be in there by default. This took me several hours to debug, and I'm sure there are others who have been bit by it. There is also no official Gentoo guide for mdadm setup, otherwise I'd edit it to suggest this workaround. FWIW I don't think it is appropriate or necessary for the fsck init script to depend on udev-settle, because these stable-named symlinks are all derived from device properties that can be referred to explicitly in fstab entries, without having to resort to /dev/disk/... symlinks. Reproducible: Always
udev-settle itself is quite racy; devices may appear at any time.
