FS#8878 - Slow bootup as "Loading UDev uevent" takes its time at bootup

Attached to Project: Arch Linux
Opened by Christopher Thorjussen (Joffer) - Sunday, 09 December 2007, 13:02 GMT
Last edited by Thomas Bächler (brain0) - Monday, 12 April 2010, 21:27 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Summary and Info:

I've got a more or less new Arch system installed with more or less only the "basic" packages installed (base+internet stuff+gnome) at the moment. After I rebooted when the latest kernel update "kernel26-2.6.23.9-1" was installed I'm stuck at the bootup screen for looking at "Loading UDev uevent" staying in [BUSY] mode for over a minute before the system goes ahead and loads further. What can cause this "time-out"/waiting? And why now with just a ".8-1 to .9-1" update?

uname -a:
Linux archbox 2.6.23-ARCH #1 SMP PREEMPT Mon Nov 26 21:15:02 UTC 2007 i686 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

/etc/rc.conf:
[code]LOCALE="en_US.utf8"
HARDWARECLOCK="localtime"
TIMEZONE="Europe/Oslo"
KEYMAP="no-latin1"
CONSOLEFONT="default8x16"
CONSOLEMAP=
USECOLOR="yes"

MOD_AUTOLOAD="yes"
MOD_BLACKLIST=()
MODULES=(atl1 mii slhc snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-intel soundcore fuse uinput)
USELVM="no"

HOSTNAME="armor.joffer.net"
eth0="dhcp"
INTERFACES=(eth0)
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)

DAEMONS=(syslog-ng network netfs crond dbus hal fam alsa sshd gpm avahi-daemon)[/code]
/etc/mkinitcpio.conf:
[code]MODULES="pata_jmicron ata_generic ahci ata_piix"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap resume filesystems"[/code]

More people have reported this. See forum: http://bbs.archlinux.org/viewtopic.php?id=40797



Steps to Reproduce:
Not sure, perhaps install from CD and do an update
This task depends upon

Closed by  Thomas Bächler (brain0)
Monday, 12 April 2010, 21:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  This was fixed years ago, reopening it serves no purpose.

Please open a new bug report, thank you.
Comment by Dan McGee (toofishes) - Sunday, 09 December 2007, 17:12 GMT
  • Field changed: Attached to Project (Pacman → Arch Linux)
Please file under the correct project next time- this has nothing to do with pacman.
Comment by Tobias Powalowski (tpowa) - Sunday, 09 December 2007, 17:14 GMT
it could be that the module initialisation takes longer now
Comment by Aaron Griffin (phrakture) - Monday, 10 December 2007, 17:25 GMT
I don't think there's a whole lot we can do if udev is slow. The best thing you could do is boot once, run lsmod, then put all those modules into the MODULES array in rc.conf, and set MOD_AUTOLOAD="no" this will shut off udev's autoloading, and might make things happen faster.
Comment by Thomas Bächler (brain0) - Monday, 10 December 2007, 19:08 GMT
Disabling autoloading is a bad idea, especially if you use hotpluggable devices (which everyone does).

I think the problem is /lib/udev/load-modules.sh, which is called about 100 times at bootup and is way too complicated for that.
Comment by Aaron Griffin (phrakture) - Monday, 10 December 2007, 19:17 GMT
That is true, but it is forked, so it shouldn't be a huge issue...
Still, I'll take a peek at that script and try to optimize it.
Comment by Christopher Thorjussen (Joffer) - Monday, 10 December 2007, 20:20 GMT
Not sure if it's important but I just ran pacman -Syu now and my system wanted to install a new version of hwd package. Then I remembered that I ran 'hwd -u' after the hwd package was updated. I did it again now (still has a copy of the first version of pci and usb.ids) and the output started like this:

[root@matrix hwdata]# hwd -u
Testing: kernel (2.6.23-ARCH) supports uevents
Update pci-, usb.ids, and xorgtable.
Are you connected and ready to update(y/n)? [n] y
...
(files are downloaded and replaced)

What I noticed this time is that is says "Testing:", and it's in bold and color so guess it's not ready for prime time and perhaps the reason?
Comment by Christopher Thorjussen (Joffer) - Monday, 10 December 2007, 20:41 GMT
I copied back the original files from before I first ran the command and booted. Did not help. Still about a minute of waiting
Comment by Aaron Griffin (phrakture) - Monday, 10 December 2007, 22:24 GMT
hwd has nothing to do with udev at all.
Comment by Anonymous (Chaos-Keeper) - Thursday, 20 March 2008, 16:20 GMT
I think, I found the solution!
Could you (Joffer) please check, if the file "/etc/udev/rules.d/99-btnx.rules" is existent? This file slows down UDev massively! You can safely remove it, if you have a new version of btnx installed because it is not needed anymore. The version available in AUR should be already enough. The problem is: This file is not longer in the btnx-package but it gets not removed when updating btnx so you have got to remove it manually.
Comment by MarcoRosso (MarcoRosso) - Sunday, 11 April 2010, 00:06 GMT
The bug has come back after the new update to Kernel 2.6.33, and udev 151-3. I have attempted bypassing the load_modules.sh file, and the problem still persists. I also tried commenting out udev's uevents from /etc/rc.sysinit; this caused a failure of the mounting for root filesystem.
Comment by MarcoRosso (MarcoRosso) - Monday, 12 April 2010, 03:58 GMT
I have changed the order of the udev uevents processing in /etc/rc.sysinit. However this should not be needed, As the file was unaltered prior to the updates.
The change can be seen on the same forum post that is in the bug topic.
Comment by MarcoRosso (MarcoRosso) - Monday, 12 April 2010, 21:07 GMT
I have changed the order of the udev uevents processing in /etc/rc.sysinit. However this should not be needed, As the file was unaltered prior to the updates.
The change can be seen on the same forum post that is in the bug topic.
Comment by Thomas Bächler (brain0) - Monday, 12 April 2010, 21:27 GMT
Ehm, why did we reopen a bug from 2008? This is probably not related at all to a bug that is way over 2 years old, despite the similar symptoms - slow uevent processing time can have a large number of causes, one of which was solved 2 years ago.

This is most likely an entirely new problem, please open a NEW bug report with all the details - all that reopening an old and probably unrelated bug does is confuse people. Thank you.

Loading...