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

Aaron Griffin aaronmgriffin at gmail.com
Wed Feb 18 16:46:07 EST 2009

On Wed, Feb 18, 2009 at 3:40 PM, Tobias Powalowski <t.powa at gmx.de> 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.
> Suggestion:
> Shouldn't we replace all this with 1 hook which can handle all these cases?
> Now comes the point, to achive this, mdadm will be needed in initramfs which
> means having a 900k static binary in early boot sequence.
> (raid-partitions hook already uses this binary)
> The trick i thought of, would be to generate dynamically a mdadm.conf file
> from boot commandline, which will use the old syntax of assembling + adding a
> new syntax for UUID support.
> Sample code is uploaded here:
> http://www.archlinux.org/~tpowa/mdadm.hook
> (not yet tested to boot a system, it's sample code!)
> Problems:
> Should this replace an existing hook or a be brand new hook?
> What should happen to the other hooks, in order to not break a user setup.
> Doing it with a NEWS Item and a installation message should be fine imho.
> What do you guys think of this?
> Thanks for your input.

Haven't thought too hard on this, but a couple of points:

klibc should have basic raid assembly functionality built it. I was
under the impression it worked for basic cases. If this is still true
then we shouldn't replace it, but make sure people are aware the klibc
one is real basic and the mdadm one is more indepth.

The sample code with all those nested calls is real ugly and hard to
read - readability is always preferred if other people are going to be
looking at / fixing / working with the code. It'd be nice to break
that into more lines so that it's easier to understand

Other than that, the idea seems sound. I do not have a raid system to
play with, though

More information about the arch-dev-public mailing list