Relevant packages installed: - baselayout-1.8.6.8-r1 - raidtools-1.00.3-r1 Reproducible: Always - Set up a RAID array, with a properly defined raidtab - Make sure the partition types of all RAID members is 0xfd (linux RAID) - Reboot Kernel: - linux-2.4.20-gentoo-r5 with MD support built-in The problem is that /sbin/raidstart will return 1 for any error. Including an "already running" error. With any result code > 0, checkfs drops to shell while trying to start RAID. This wouldn't be so bad except that checkfs starts a maintenance root shell instead of booting. Either raidtools' raidstart needs to be patched to emit different result codes, or checkfs needs to capture error output and read it. A third way to go might be to add a config variable that makes checkfs skip RAID startup. This looks like a regression; at least as of baselayout-1.8.6.6, autostart RAIDs appeared to be handled normally (<A href="http://bugs.gentoo.org/show_bug.cgi?id=20378">Bug #20378</A>).
No way to detect 'already running' ? Sorry, no real experience in software RAID.
The issues related to checkfs's raid startup code have hit bugs.gentoo.org several times, and they're never resolved to everyone's satisfaction. On one particular system I have, it is a requirement for everything to work correctly that I have two both autodetected and non-auto-detected raid devices. In this case the current checkfs is doubly broken. Furthermore, I have /dev/md/X in my raidtab rather than /dev/mdX. Both are legal, and the one I'm using is the real location in devfs, the shorter one is a compat softlink. The current raid startup can't hack this at all. It seems to me the only reasons to maintain the current clunky raid startup code is: 1) To support obsolete raid startup with raid0add/raidrun (seems like a bad idea to break working modern setups for this) 2) To support not starting devices which are for noauto filesystems in fstab (again, doesn't seem worth it, if a raid device is defined in raidtab, it should start or give us errors regardless, if you dont want to be stopped on bootup, then fix your raid device or remove it from your raidtab?) If you're willing to throw those two things out the window, you can let raidtools and/or mdadm do everything for you, correctly, and it will work on all systems without all these bug reports, e.g.: if [ -f /proc/mdstat -a -f /etc/raidtab -a -f /sbin/raidstart ] then raidstart -a fi if [ -f /proc/mdstat -a -f /etc/mdadm.cf -f /sbin/mdadm ] then mdadm -Sa fi and be done with it (of course I don't use mdadm so I'm sure my syntax was wrong or the config name was wrong, and I left out return value checking, but you get the idea :)
ok, this is finally fixed mdadm-1.9.0-r1 / raidtools-1.00.3-r4 utilizes code similar to what you've posted here (with fixed syntax for mdadm of course !) baselayout-1.11.10+ will take advantage of their addins
