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
