Arch Linux

It's a known issue:
I think I understand what's the problem. In the initramfs, there are
two hooks which tries to assemble the raid array: udev and mdadm. One
of them succeed and one of them fails. This explains how come my
system boots fine even though I'm getting these error messages about
missing devices. I'm pretty sure that it's udev which is failing: the
error messages have a [udevd] in front of them and if I disable or
modify the mdadm hook, the boot fail. The errors happens before the
start of the initscripts. It's a kernel/udev/initramfs issue.

We are still trying to figure out why it happens and how to fix it.

Specifically, the errors are showing up because at that stage in boot, we are still within the initramfs, so the udevd there is calling the mdadm rules at /lib/udev/rules.d/64-md-raid.rules, and these rules expect there to be a /sbin/mdadm binary within the initramfs temporary root. Because this binary does not exist, these udev rules are failing visibily. Editing /etc/mkinitcpio.conf to include /sbin/mdadm causes the initramfs udevd to not fail on the rules that call this binary.

All that being said, if there is some sort of duplication of raid initialization effort between the mdadm hook (/hooks/mdadm within the initramfs) and the udev rules, then including this binary into the initramfs may only cure the symptoms (udevd's error messages during boot) while having other unintended consequences.

$ pacman -Q kernel26 udev mkinitcpio mdadm
kernel26 2.6.39.1-1
udev 171-2
mkinitcpio 0.6.12-1
mdadm 3.2.1-3

Applies to mkinitcpio 0.6.13-1 as well.

mkinitcpio 0.6.14-1 just hit testing, but the sign-off thread doesn't seem to indicate anything related to this.

No, we need to fix it in the mdadm package.

I confirm that adding "/sbin/mdadm" to the add_binary line and removing the SCRIPT="mdadm" in /lib/initcpio/install/mdadm fix the problem.

i propose the following patchs

zut.

Tobias, Seblu's patch looks like the right solution.

I noticed that in the PKGBUILD patch, the pkgrel was bumped to 3.1 instead of 4. Is that a typo?

It's a good idea if you want to test packages locally without preventing pacman to upgrade once a new version hits the official repositories.

you should bump to 4. I use 3.1 to because it's not an official version and this let pacman update correctly when 4 will be out.

So this will be fixed in the next mdadm version?

The version in testing should work. I guess it'll be moved shortly.

tnx :)

I guess this can be closed now? Can anyone confirm the fix?