[arch-general] [arch-dev-public] Changing raid/raid-partitions initcpio hooks

[Michal Soltys]

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 :)