Are you running ubuntu?
I find the same problem in Ubuntu if /etc/mdadm/mdadm.conf cites MD
arrays as /dev/md/somearrayname .
Only the short form /dev/mdX works. If you go into the file and change
the names with the short form (then regenerate initramfs and reboot) it
will probably work.
The longer form triggers some bug in I-don't-know-where in the boot
sequence for which a preliminary device md_d'something gets created as
soon as the first raid element is detected, and then the other drives
(detected later) cannot form a nondegraded array anymore. This does not
happen on all arrays but a few yes, like 3-4 drives in 8 raid1 (2
elements) arrays.
I don't know if this is a "mdadm --incremental" bug (Ubuntu uses mdadm
--incremental in udev for each drive discovered), an udev bug or
udev-rules bug, a race condition or something else. Might also have
something to do with the symlinks.
I'm not sure if mdadm --incremental is safe in a highly racy situation
like when tens of drives and tens or hundreds of partitions are detected
at the same time. Does it lock properly?
Also I don't understand why in Ubuntu when using the long names i see 4
drives for each array:
/dev/md/arrayname
/dev/md/arrayname1
/dev/md/arrayname2
/dev/md/arrayname3
/dev/md/arrayname4
/dev/md/anotherarray
/dev/md/anotherarray1
/dev/md/anotherarray2
/dev/md/anotherarray3
/dev/md/anotherarray4
...
the first has MD major number, the others have 254, which I don't know
what refers to. I don't know what they are, my raid arrays are not
partitionable!
This one I don't know
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html