Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Occasional extra long delays starting udev|
|Product:||[Fedora] Fedora||Reporter:||Bruno Wolff III <bruno>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-23 06:11:31 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Bruno Wolff III 2008-02-22 02:26:41 EST
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.
Comment 1 Zack Cerza 2008-03-03 12:41:54 EST
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.
Comment 2 Horst H. von Brand 2008-03-05 09:37:23 EST
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)
Comment 3 Horst H. von Brand 2008-03-09 11:53:32 EDT
Yesterday I had to reboot 3 times before udev started OK
Comment 4 Horst H. von Brand 2008-03-11 18:08:55 EDT
Now I measured udev startup time (2nd try, when it started OK). A full 35 seconds (!).
Comment 5 Harald Hoyer 2008-03-12 14:39:45 EDT
try to add "udevinfo" or "udevdebug" to the kernel command line
Comment 6 Harald Hoyer 2008-03-12 14:40:34 EDT
you may hit ctrl-c, if it takes too long also...
Comment 7 Harald Hoyer 2008-03-13 09:17:43 EDT
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.
Comment 8 Harald Hoyer 2008-03-13 10:48:16 EDT
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>
Comment 9 Jóhann B. Guðmundsson 2008-03-13 11:34:40 EDT
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.
Comment 10 Harald Hoyer 2008-03-13 11:42:03 EDT
with recent rawhide udev-118-8.fc9 you may also try to boot with "udevnopersist" in the kernel command line.
Comment 11 Harald Hoyer 2008-03-13 12:49:05 EDT
udev-118-9.fc9 now has support for a "modprobedebug" kernel command line, which may identify a kernel module causing the delay.
Comment 12 Harald Hoyer 2008-03-13 12:58:19 EDT
Comment 13 Bruno Wolff III 2008-03-15 21:47:33 EDT
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.
Comment 14 Bruno Wolff III 2008-04-06 00:51:53 EDT
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.
Comment 15 Harald Hoyer 2008-04-07 10:06:13 EDT
should I close this bug then?
Comment 16 Bruno Wolff III 2008-04-07 12:57:16 EDT
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.