Red Hat Bugzilla – Bug 433933
Occasional extra long delays starting udev
Last modified: 2008-04-23 06:11:31 EDT
Occasionally after the "Starting udev:" prompt there is a delay on the order of a minute instead of the normal roughly 5 seconds before proceding. Version-Release number of selected component (if applicable): udev-118-1.fc9.i386 How reproducible: Maybe something on the order of 25%. Steps to Reproduce: 1.reboot 2. 3. Actual results: After the starting udev prompt there is an usually long delay. Expected results: After the prompt is displayed there should only be a short pause before moving on. Additional info:The raid arrays are raid 1 using pata drives and the fs is ext3.
udev-118-5.fc9.i386 is taking several minutes here, and timing out. Sometimes, the system never ends up booting. This started happening with rawhide kernels after -28. I'm now on kernel-2.6.25-0.82.rc3.git2.fc9.i686 . There's nothing funny about this system; it's a Thinkpad X41 with simple non-LVM disk partitions.
udev-118-5.fc9.i386 here, now kernel-2.6.25-0.90.rc3.git5.fc9.i686 on dual-core i686, symptoms as in comment 1. Machine is Toshiba Tecra, has a USB mouse plugged in. No RAID, LVM for handling the disk. And no, udev doesn't take anywere near 5 seconds to start, more like 20 (unless it times out). And here it times out roughly 50% of the time. This doesn't show on x86_64 dual core desktop (also rawhide, roughly the same packages installed)
Yesterday I had to reboot 3 times before udev started OK
Now I measured udev startup time (2nd try, when it started OK). A full 35 seconds (!).
try to add "udevinfo" or "udevdebug" to the kernel command line
you may hit ctrl-c, if it takes too long also...
hmm, you can also try to identify the culprit in the udev rules files. just move away some rules files from /etc/udev/rules.d and boot into single mode first try all files that do not belong to udev or initscripts. if the problem persists, try the *persistent* files.
oh, and you may try to blacklist modules, to see, if the delay comes from a module just add to /etc/modprobe.conf: blacklist <modulename>
See if it's still there after rawhide 20080313 updates. I was experince the similar thing and then it seemed to be related to selinux and udev you can add selinux=0 to the boot parameter and see if you takes as long ( I just got stuck on udev,if I had selinux enabled and in disabled,permissive or enforcing mode I could not get passed udev, after rawhide 20080313 updates it seems to be fixed.
with recent rawhide udev-118-8.fc9 you may also try to boot with "udevnopersist" in the kernel command line.
udev-118-9.fc9 now has support for a "modprobedebug" kernel command line, which may identify a kernel module causing the delay.
http://koji.fedoraproject.org/koji/buildinfo?buildID=42806
I am still seeing some variability of the pauses with udev-118-5.fc9.i386. I don't think the worst case is as bad as it was previously. I'll install 118-9 and add modprobedebug to grub.conf and keep an eye on it.
Things seem mostly better now. I haven't seen a long hang in a long time. No single module seems to pause for more than 2 seconds and most appear to take no noticeable time.
should I close this bug then?
I think it is OK to. If I see it happen again I can reopen it. My only hesitation is that I don't know what fixed it.