Bug 329079 – sys-fs/udev-160 init script, mounting already mounted root disk, causes udev event flooding

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Navid Zamani 2010-07-20 09:59:27 UTC]

Sorry for the vague description. The problem is quite concrete though.

I have this kernel lines in grub.conf (aka menu.lst):
title  Gentoo Linux (current kernel)
root   (hd0,2)
kernel /boot/kernel root=/dev/md0 md=0,/dev/sda3,/dev/sdb5 raid=noautodetect console=tty1 # radeon.modeset=1 video=1600x1200-32 splash=silent,fadein,fadeout,theme:natural_gentoo
#initrd (hd0,2)/boot/initramfs-bootsplash.cpio.lzma
#The noautodetect and md is needed for it to work. Disabled bootsplash, to see it happening.

Now the thing boots, and very early, I get the flood of messages from udev, as can be seen in the upcoming attachment of the udev-monitor output.

This hangs the system for 60 seconds, until the timeout is reached, and the system continues to boot up anyway.




Reproducible: Always

Steps to Reproduce:
1. Create a small raid1 test partition with mdadm, and install/copy a basic Gentoo with raid support, but without splash support, on it.
2. Create grub menu entry like above, adapted to your partitions.
3. Enable boot-time udev monitoring in /dev/conf.d/udev
4. Boot up and watch how the described problem happens.
5. Look at /dev/.udev/udevmonitor.log, and compare to my attachment.

Actual Results:  
As described above.

Expected Results:  
Udev should not try to mount an already mounted partition, or it should be the only one (which i think would not be possible in this case).
Hence booting would not hang and the timeout would never be reached, as the system would boot up normally.

I would maybe have solved this myself. If there were any useful documentation about the whole udev bootup process for Gentoo. (When does which init script do what, and when is which udev rule file from where used?)

[Comment 1 Navid Zamani 2010-07-20 10:01:34 UTC]

Created attachment 239531 [details]
Boot-time udev-monitor-logged output, showing the flooding.

[Comment 2 Jeroen Roovers (RETIRED) 2010-07-20 18:12:23 UTC]

Please post the output of `emerge --info sys-fs/udev' too.

[Comment 3 Navid Zamani 2010-07-20 23:01:37 UTC]

Created attachment 239611 [details]
emerge --info udev

[Comment 4 Navid Zamani 2010-07-20 23:02:07 UTC]

Sorry, forgot to mention the version.

[Comment 5 Navid Zamani 2010-07-24 10:36:41 UTC]

Ok, since nobody answered, I looked into it a bit myself.

It’s the /etc/init.d/udev init script. In there, the function populate_dev calls “udevadm trigger --action="add" --attr-match=dev” to trigger add actions, and later waits for the events to settle.
But the problem is, that the never-ending flood of 
  KERNEL[1279974188.810128] change   /devices/virtual/block/md0 (block)
  UDEV  [1279974188.813204] change   /devices/virtual/block/md0 (block)
does prevent it from being settled.
The "udevadm settle --timeout=${udev_settle_timeout:-60}" function also mentions it, when it’s had enough.

***************************************************************************
The core question is: Who or what does create that flood of change actions
for the md0 device? Which script? (I guess it must be a script.)
Who’s the one who knows that?
***************************************************************************

[Comment 6 Navid Zamani 2010-07-24 10:37:57 UTC]

Changed the summary, to reflect the actual problem.

[Comment 7 Maciej Mrozowski 2010-08-06 14:30:05 UTC]

I confirm the problem in my ~amd64 chroot

[Comment 8 Matthias Schwarzott 2010-08-07 12:53:20 UTC]

Did you check if this is a duplicate of Bug #322711 ?

[Comment 9 Navid Zamani 2010-08-07 13:07:42 UTC]

(In reply to comment #8)
> Did you check if this is a duplicate of Bug #322711 ?

Well, I always check if a bug exists, before creating a new one. But of course I did not check for bugs for mdadm, since I thought it’s a udev bug.
I can not yet confirm that it’s a dupe. But I’m going to downgrade mdadm, to check, and then report back. Thanks for the hint.

[Comment 10 Navid Zamani 2010-08-09 10:35:03 UTC]

Ok, I downgraded the package, rebooted, and lo and behold… the problem is gone!
So interestingly, this really is a dupe. :)

*** This bug has been marked as a duplicate of bug 322711 ***