Randy Terbush wrote:
Thanks for the suggestions from Dan and others. I've managed to pin the names of the raid devices. Getting closer to figuring out the startup problem hopefully. kernel trace included below... This is running on Gentoo with kernel 2.6.30. Linux hifi 2.6.30-gentoo-r9 #1 SMP Mon Mar 22 08:25:58 MDT 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
[..]
And /proc/mdstat says: # cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md127 : active (read-only) raid5 sdb[3] sdc[2] sdd[1] sde[0] 2930280448 blocks super external:/md0/0 level 5, 64k chunk, algorithm 0 [4/4] [UUUU] resync=PENDING md0 : inactive sde[3](S) sdb[2](S) sdc[1](S) sdd[0](S) 9028 blocks super external:imsm unused devices: <none>
This shows that Gentoo is most likely not including mdmon in their initramfs environment. mdadm assembles the array readonly, but then mdmon is required to mark the array writable.
And a look at the kernel messages from dmesg says:
[..]
[ 22.918983] ------------[ cut here ]------------ [ 22.918986] kernel BUG at drivers/md/md.c:6139!
I believe I hit this bug before and it came down to a mismatch between the readonly status of the array. The block device was marked read-write according to blockdev --getro, but the internal md device state was readonly. I believe this has been fixed upstream (but the commit escapes me), but would also be addressed by having mdmon available when the array is assembled. It would be nice if Gentoo would adopt Dracut for their initramfs generation tool as it already comprehends the mdmon wrangling issues.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html