Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#24663 - [mdadm] Kernel boot messages - udevd and mdadm

Attached to Project: Arch Linux
Opened by Clouseau2 (Clouseau2) - Friday, 10 June 2011, 12:01 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 12 July 2011, 02:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

Hello, I have this problem http://old.nabble.com/-signoff--udev-170-1-td31661717.html I've managed to "fix" like the original poster did, it fixed itself with the numerous upgrade/downgrade of udev and kernel.

But yesterday when I upgraded to 2.6.38-1 the messages are back... I tried also few differrent kernels and donwgrading/upgrading udev but this time the messages are still here. Any idea?

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Eric Belanger (Snowman)
Tuesday, 12 July 2011, 02:22 GMT
Reason for closing:  Fixed
Comment by Eric Belanger (Snowman) - Friday, 10 June 2011, 22:49 GMT
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.
Comment by Davie (daschu117) - Sunday, 12 June 2011, 09:57 GMT
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
Comment by Davie (daschu117) - Sunday, 12 June 2011, 19:41 GMT
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.
Comment by Thomas Bächler (brain0) - Sunday, 12 June 2011, 20:11 GMT
No, we need to fix it in the mdadm package.
Comment by Eric Belanger (Snowman) - Sunday, 12 June 2011, 22:53 GMT
I confirm that adding "/sbin/mdadm" to the add_binary line and removing the SCRIPT="mdadm" in /lib/initcpio/install/mdadm fix the problem.
Comment by Sébastien Luttringer (seblu) - Tuesday, 14 June 2011, 11:47 GMT
i propose the following patchs

Comment by Sébastien Luttringer (seblu) - Tuesday, 14 June 2011, 11:47 GMT
zut.
   mdadm_hook.diff (0.3 KiB)
   mdadm_install.diff (0.4 KiB)
   PKGBUILD.diff (1 KiB)
Comment by Thomas Bächler (brain0) - Tuesday, 14 June 2011, 11:54 GMT
Tobias, Seblu's patch looks like the right solution.
Comment by Eric Belanger (Snowman) - Tuesday, 14 June 2011, 20:15 GMT
I noticed that in the PKGBUILD patch, the pkgrel was bumped to 3.1 instead of 4. Is that a typo?
Comment by Thomas Bächler (brain0) - Tuesday, 14 June 2011, 20:22 GMT
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.
Comment by Sébastien Luttringer (seblu) - Tuesday, 14 June 2011, 20:30 GMT
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.
Comment by Clouseau2 (Clouseau2) - Sunday, 03 July 2011, 19:19 GMT
So this will be fixed in the next mdadm version?
Comment by Thomas Bächler (brain0) - Sunday, 03 July 2011, 20:59 GMT
The version in testing should work. I guess it'll be moved shortly.
Comment by Clouseau2 (Clouseau2) - Monday, 04 July 2011, 06:59 GMT
tnx :)
Comment by Tom Gundersen (tomegun) - Monday, 11 July 2011, 10:31 GMT
I guess this can be closed now? Can anyone confirm the fix?

Loading...