Tobias Powalowski wrote:

Hi guys, while experimenting with different raid setups in kvm, i found out our raid support is not really ideal.

The status now: - raid hook(inlcuded in mkinitcpio package) does assemble normal raid: but if a drive fails it will fail to boot after it. i'm not 100% sure if it can handle all types of raid levels, partitionable mdp raid doesn't work at all with this hook for sure. - raid-partitions(included in mdadm package) can only assemble 1 raid partition array, which is imho bad you should be able to assemble more than one raid partition device from commandline, if you wish to do so. - UUID is not supported in any of both.

A few notes, as I have mentioned it a few times in the past year(s) regarding the hooks you use. Why to rely on kernel commandline and in-kernel detection ? This is kinda legacy and deprecated (as far as I know) approach. IIRC in-kernel assembly also has problems with 1.x md superblocks, recalling mailing list - but I'm not sure as I never really use kernel assembly. Having initramfs generator like mkinitcpio, just make sure proper /etc/mdadm.conf is included into generated image through install part of the hook. In most systems I use, I have root on lvm on raid. Regardless of what is used for initramfs image, the part responsible for md basically requires module loading (if necessary) and mdadm -As. Mdadm doesn't need any manual device nodes creation, neither does mdassemble.auto. Udev rules in the background do the rest, so one can have e.g. root=/dev/disk/by-..... should it be needed. I described the general idea in http://bugs.archlinux.org/task/9122 It also tries to dynamically create mdadm.conf in case one doesn't exist (going from mdadm -Es, instead of parsing kernel commandline). And it detects required modules as well. Also, as of current kernel and mdadm, each md raid is partitionable by default. Old naming scheme for partitionable raids remained for backwards compatibility. Remarks, as the above is already 1+ year old: Device access is still needed to trigger partition uevents. Future mdadm (3.x) will work with udev properly, recalling long discussion about it on linux-raid. Some of the simple changes to udev ruels I suggested made it into upstream as well. Most generic one (including scanner helper for custom raid names and etc., not mentioned in the above bugreport) didn't, being too hackish. Still - simple naming, once you decide on single arch preferred standard is pretty trivial without any external helpers. The only "drawback" is having libc or static mdadm / mdassemble.auto in the image Unless someone is trying to boot Arch on machine with incredibly low amount of ram (even for P2 ages), this is hardly any problem. On a related note - arch's udev rules (81-...) still have entry for md, which should likely be removed, as 64-... takes care of it. Current udev also allow overriding NAME in further rules, should that matter for arch. FYI. Sorry for crossposting, no other way though :)