# [Solved] Waiting for uevents to be processed ... Forever

## shrike

Emerge --sync --update yesterday caused my x86 system to freeze at 'Waiting for uevents to be processed ...'. Checked Bugzilla, searched forums, reviewed elogs.. nothing except rm old udev lib and 70-persistent-net rule which I did.

Part of my problem is 'Waiting for uevents to be processed ...' never indicates what event is failing. Is there a way to get more verbosity with udev? Yesterday, the only udev update was for virtual-udev (197-r2 I think) but I don't use sys-fs/eudev (should I ??). Today, sync brought sys-fs/udev up to version 200 but that doesn't solve my problem.

Is anybody else in this boat?

Thanks..Last edited by shrike on Tue Apr 02, 2013 11:41 am; edited 1 time in total

----------

## Randy Andy

shrike,

did you respect all hints given in the latest news?

 *Quote:*   

> 
> 
> 2013-03-29-udev-upgrade
> 
>   Title                     udev upgrade from 197 (or older) to 200 (or newer)
> ...

 

and did you already once using this command while on your upgrade path before:

```
emerge -av1 $(qfile -q -S -C /usr/lib/udev)
```

Much success, Andy.

----------

## SamuliSuominen

Are you using USE="-*" or is USE flag "firmware-loader" otherwise enabled or disabled for >=sys-fs/udev-200? I've heard problems with it disabled, which has something to do with the kernel failing to load the firmware while it's  supposed to be able to (?)

Enable it and the delay should go away

This is just educated guess!

And you can always enable more logging from /etc/rc.conf, /etc/udev/udev.conf, /etc/conf.d/udev, for extra output in /var/log/messages and 2 more udev logs in /run directory.

----------

## shrike

Randy Andy,

Thanks. I did read that news but I'm not sure if I removed udev-postmount from any run level. I don't see udev-postmount in /etc/init.d/.

The command 'emerge -av1 $(qfile -q -S -C /usr/lib/udev)' errors out presumably because 'qfile -q -S -C /usr/lib/udev' returns no result or match.

ssuominen,

I am not using 'USE="-*"' in make.conf and the 'firmware-loader' shows enabled

```

(chroot) sysresccd linux # eix sys-fs/udev

[I] sys-fs/udev

     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}

     Installed versions:  200^t(12:12:49 PM 03/30/2013)(acl firmware-loader kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)

     Homepage:            http://www.freedesktop.org/wiki/Software/systemd

     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

```

I did review /etc/udev/udev.conf and manned udev(7). But the point I tried to make is it would help to see what 'uevent' is being processed during bootup. I can only guess what is causing the problem. When the boot process freezes like this my only option is the reset button, ACPId is apparently not available for a graceful shutdown. Beg pardon for not being clear.

FWIW in a chroot:

```

(chroot) sysresccd linux # emerge --info

Portage 2.1.11.55 (default/linux/x86/13.0, gcc-4.5.4, glibc-2.15-r3, 3.0.25-std260-i586 i686)

=================================================================

System uname: Linux-3.0.25-std260-i586-i686-VIA_C7_Processor_1000MHz-with-gentoo-2.1

KiB Mem:      959656 total,    705976 free

KiB Swap:    1046524 total,   1046524 free

Timestamp of tree: Sat, 30 Mar 2013 16:30:01 +0000

ld GNU ld (GNU Binutils) 2.22

app-shells/bash:          4.2_p37

dev-lang/python:          2.7.3-r3, 3.2.3-r2

dev-util/pkgconfig:       0.28

sys-apps/baselayout:      2.1-r1

sys-apps/openrc:          0.11.8

sys-apps/sandbox:         2.5

sys-devel/autoconf:       2.69

sys-devel/automake:       1.11.6

sys-devel/binutils:       2.22-r1

sys-devel/gcc:            4.5.4, 4.6.3

sys-devel/gcc-config:     1.7.3

sys-devel/libtool:        2.4-r1

sys-devel/make:           3.82-r4

sys-kernel/linux-headers: 3.7 (virtual/os-headers)

sys-libs/glibc:           2.15-r3

Repositories: gentoo

ACCEPT_KEYWORDS="x86"

ACCEPT_LICENSE="* -@EULA"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=native -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-O2 -march=native -pipe"

DISTDIR="/usr/portage/distfiles"

FCFLAGS="-O2 -march=i686 -pipe"

FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"

FFLAGS="-O2 -march=i686 -pipe"

GENTOO_MIRRORS="http://www.gtlib.gatech.edu/pub/gentoo http://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo"

LANG="en_US.utf8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

MAKEOPTS="-j1"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY=""

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="acl acpi bash-completion berkdb bindist bzip2 cli cracklib crypt cxx dbus dri fortran gdbm gpm iconv ipv6 modules mpi mudflap ncurses nls nptl openmp pam pcre readline session ssl tcpd udev unicode usb x86 zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

```

Many thanks for your help,

shrike

----------

## Randy Andy

Hi shrike.

 *shrike wrote:*   

> 
> 
> The command 'emerge -av1 $(qfile -q -S -C /usr/lib/udev)' errors out presumably because 'qfile -q -S -C /usr/lib/udev' returns no result or match.
> 
> 

 

Then it's not necessary or already fixed.  :Wink: 

Same behaviour here, but few versions ago it works in this way, and seems to be necessary during the upgrade path to the actual version 200.

Could you please show us additional, while in your chroot enviroment, l the output of 

cat /usr/src/linux/.config | grep DEVTMPFS

cat /usr/src/linux/.config | grep FIRMWARE

and your fstab for sure.

----------

## shrike

Hello Randy Andy,

BTW, my kernel version is 3.5.7. I should also mention that I enabled reiserfs as a module on the day (03-29) this problem started. But running the previous kernel also freezes at 'uevents' so I don't think the reiserfs module is the issue. Still, it would be easy to remove the reiserfs module and boot with the old kernel.

Here's the .config and fstab:

```

(chroot) sysresccd / # grep DEVTMPFS /usr/src/linux/.config

CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

(chroot) sysresccd / # grep FIRMWARE /usr/src/linux/.config

CONFIG_PREVENT_FIRMWARE_BUILD=y

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE=""

# CONFIG_FIRMWARE_EDID is not set

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set

(chroot) sysresccd / # cat /etc/fstab

/dev/sda1      /boot      ext2      noauto,noatime   1 2

/dev/sda3      /      ext3      noatime      0 1

/dev/sda2      none      swap      sw      0 0

/dev/cdrom      /mnt/cdrom   auto      noauto,ro   0 0

# /dev/fd0      /mnt/floppy   auto      noauto      0 0

```

My next avenue of inquiry will be the packages that were upgraded starting with kmod I think. Review change logs, readme's.

Elogv for 03-29 (nwipe and viaideinfo are new installs, all else upgrades):

```

* app-crypt/nwipe-0.14 - 03/29/2013

* sys-block/viaideinfo-0.5 - 03/29/2013

* sys-apps/hwids-20130302 - 03/29/2013

* sys-apps/util-linux-2.22.2 - 03/29/2013

* virtual/udev-197-r2 - 03/29/2013

* sys-kernel/gentoo-sources-3.7.10 - 03/29/2013

* dev-lang/python-2.7.3-r3 - 03/29/2013

* dev-lang/python-3.2.3-r2 - 03/29/2013

* sys-apps/kmod-12-r1 - 03/29/2013

* net-misc/openntpd-20080406 - 03/29/2013

* dev-libs/libxslt-1.1.28-r1 - 03/29/2013

* sys-kernel/linux-headers-3.7 - 03/29/2013

* sys-process/procps-3.3.4 - 03/29/2013

* app-admin/eselect-python-20111108 - 03/29/2013

* sys-apps/man-pages-3.47 - 03/29/2013

* app-admin/eselect-1.3.4 - 03/29/2013

* sys-devel/gettext-0.18.2 - 03/29/2013

* sys-devel/bc-1.06.95 - 03/29/2013

* dev-python/python-exec-0.2 - 03/29/2013

* sys-libs/timezone-data-2012j - 03/29/2013

* sys-apps/portage-2.1.11.55 - 03/29/2013

* sys-fs/zerofree-1.0.1 - 03/29/2013

* sys-fs/dosfstools-3.0.13 - 03/17/2013

```

Thanks for your help,

shrike

----------

## Randy Andy

shrike,

Can't see the fault into the configs you post to us.

now I guess you should do what ssuominen advises to get more verbose messages, so that we don't need to shoot longer into the dark.

Otherwise we don't know the direction he have to go.

Eventually this gives you more ideas for double checking some point of failures.

https://forums.gentoo.org/viewtopic-t-955686-highlight-.html

https://forums.gentoo.org/viewtopic-t-955610-highlight-.html

Andy.

----------

## shrike

The problem is solved by adding a frame-buffer (vga-16 and VESA) in the kernel. Being a headless, noX file server I did not see the need. Oddly though, after reverting back to a framebuffer-less kernel to confirm the cause, the system booted up normally. All kernel builds were preceded with a 'make mrproper' command. Prior to FB'ing the kernel I did convert to Predictable Network Interface Names which did not resolve the udev problem. Anyway, I consider this problem solved.

Thanks,

shrike

----------

## yoosty69

 *ssuominen wrote:*   

> Are you using USE="-*" or is USE flag "firmware-loader" otherwise enabled or disabled for >=sys-fs/udev-200? I've heard problems with it disabled, which has something to do with the kernel failing to load the firmware while it's  supposed to be able to (?)
> 
> Enable it and the delay should go away
> 
> 

 

Enabling the USE flag "firmware-loader" decreased my "Waiting for uevents.." pause from ~5-10 seconds to ~0 seconds. Thanks for mentioning this!

----------

## Shamus397

There's nothing I hate more than seeing resolutions like this that amount to little more than "wave a dead chicken". So here's what I did to troubleshoot and fix my similar problem:

First, I removed udev from running automatically on boot:

```
# rc-update del udev sysinit
```

After that, I was able to boot up without using a rescue CD. I then tried starting udev manually, after booting up normally and logging in as root:

```
# /etc/init.d/udev start
```

It hung forever on the "Waiting for uevents..." line. I was then able to switch to another VT and do a dmesg. It turned out that udev was perpetually trying to insert an nvidia kernel module which was too new for my video card. Once I masked the newer driver and re-emerged it, I was able to successfully start udev.

Hopefully that will help someone else troubleshoot their problem if they run into the dreaded "Waiting for uevents..." hang.  :Wink: 

----------

## albright

 *Quote:*   

> There's nothing I hate more than seeing resolutions like this that amount to little more than "wave a dead chicken". So here's what I did to troubleshoot and fix my similar problem: 

 

thanks for that!!

(but in my case, a ctrl-c stops the uevents processing and then I can

apply your advice ...)

----------

## june3474

[quote="Shamus397"]

Hopefully that will help someone else troubleshoot their problem if they run into the dreaded "Waiting for uevents..." hang. ;)[/quote]

Thanks Shamus397

You saved the day!

----------

## ShadowCat8

 *Shamus397 wrote:*   

> There's nothing I hate more than seeing resolutions like this that amount to little more than "wave a dead chicken". So here's what I did to troubleshoot and fix my similar problem:
> 
> First, I removed udev from running automatically on boot:
> 
> ```
> ...

 

And, another Thanks to Shamus397 for helping resolve this issue intelligently.  Thanks again!

----------

## peterius

 *Shamus397 wrote:*   

> 
> 
> It hung forever on the "Waiting for uevents..." line. I was then able to switch to another VT and do a dmesg. It turned out that udev was perpetually trying to insert an nvidia kernel module which was too new for my video card. Once I masked the newer driver and re-emerged it, I was able to successfully start udev.

 

Thanks!  I had the same nvidia framebuffer problem.  I moved the nvidia directory out of /lib/modules/kernel<>/video/fb/ and now it works.

----------

