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):
Maybe something on the order of 25%.
Steps to Reproduce:
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
There's nothing funny about this system; it's a Thinkpad X41 with simple non-LVM
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
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
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:
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.
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
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.