# udev-098 broke my system!!

## supermihi

Hi, I updated to udev-098 an hour ago. After the nex reboot, my gentoo wouldn't boot. At 'letting udev process events' in sysvinit, it would say that my slash-partition (which is a LVM logical volume) had a bad superblock. But the filesystem is ok. I booted with the gentoo livecd, chrooted and re-emerged udev-096-r1, and etc-updated to use the configuration files from that version (perhaps actually the config files broke it, not udev itself).

However this wasn't a pacifying experience, so be warned, gentoo users.  :Wink: 

Here's my emerge --info:

```
$ emerge --info

Portage 2.1.1_rc1-r2 (default-linux/amd64/2005.1, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.17-gentoo-r7 x86_64)

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

System uname: 2.6.17-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3500+

Gentoo Base System version 1.12.4

Last Sync: Thu, 31 Aug 2006 18:30:01 +0000

ccache version 2.4 [enabled]

app-admin/eselect-compiler: 2.0.0_rc2-r1

dev-lang/python:     2.4.3-r3

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     2.4-r2

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.18.1

sys-devel/autoconf:  2.13, 2.60

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.17

sys-devel/gcc-config: 1.3.13-r3

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.16

ACCEPT_KEYWORDS="amd64 ~amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict"

GENTOO_MIRRORS="http://gentoo.ITDNet.net/gentoo http://mirror.uni-c.dk/pub/gentoo/"

LANG="de_DE.utf8"

LC_ALL="de_DE.utf8"

LINGUAS="de"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

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

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

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

USE="amd64 X a52 aac alsa apache2 avi bash-completion bitmap-fonts bluetooth browserplugin bzip2 cairo caps cdda cdr cli crypt cups dbus dga divx4linux dlloader dri dts dvb dvd dvdr dvdread elibc_glibc emboss encode exif fbsplash ffmpeg firefox flac foomaticdb fortran gif gpm hal imlib input_devices_keyboard input_devices_mouse insecure-savers ipod isdnlog jack java jpeg kde kdeenablefinal kdehiddenvisibility kdepim kernel_linux libcaca linguas_de linuxthreads-tls lirc lirc_devices_devinput lm_sensors logitech-mouse logrotate lzw lzw-tiff mad matroska mjpeg mozilla mozsvg mp3 mpeg mplayer musicbrainz ncurses nis nls no-seamonkey nptl nptlonly nsplugin nvidia offensive ogg oggvorbis opengl pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection samba sasl sdl session smime spl ssl stream svg tcpd tetex theora threads tidy tiff truetype truetype-fonts type1-fonts unicode usb userland_GNU userlocales v4l v4l2 vcd video_cards_nv video_cards_nvidia video_cards_v4l video_cards_vga visualization vlm vorbis wmf xcomposite xext xine xinerama xorg xpm xv xvid xvmc zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## Kosa

I thinks it's better to post this to bugzilla for developers  :Smile: 

----------

## AaronPPC

I don't completely agree.  I think it would be good to post on bugzilla, but I think it is just as important to post here.  If udev-098 is breaking people's systems, I want to know about it before I let it break my system.

----------

## Kosa

You're right, i missed this.

----------

## supermihi

I think both of you are right.  :Wink: 

Unfortunately I'm not at home for the next days, so I won't be able to post on bugzilla. All I know is that the problem still remains, i.e. there's no new version of udev. I forgot about the problem and emerged -uD world again, and *wham* once more I needed the gentoo CD to chroot and re-emerge the older udev.  :Wink: 

But since there don't seem to be much people with that problem, I assume it is related to my special configuration, something with LVM maybe.

----------

## ArneBab

I can't get my lvm2 root partition to mount in my newer kernel (2.6.17-r3 is the last one I got to work, 2.6.17-r7 doesn't work, but I'm working on gettin it to do). 

Might be something similar.

----------

## ArneBab

I found a solution for my problem, maybe it also helps you: 

Just update /etc/genkernel.conf

There might be some quite ancient module-descriptions in there. 

Here's what i changed (didn't remember to copy teh old version somewhere before changing, so can't give a diff): 

-----------------------------

MODULE_INIT_TOOLS_VER="3.2.2-r1"

MODUTILS_VER="2.4.27-r1"

DIETLIBC_VER="0.30-r1"

UDEV_VER="099"

DEVICE_MAPPER_VER="1.02.09"

LVM2_VER="2.02.09"

-----------------------------

----------

## mroconnor

I dont use LVM but sure enough after an emerge -vuD world  I am stuck w/ a unbootable system(~x86 kernel 2.6.17). Once the liveCD is finished burning I will downgrade udev. I wish I could remember not to upgrade udev, this seems to happen everytime I do!!! ugh.....  :Confused: 

----------

## sonicbhoc

I've never ever had a single problem with upgrading udev. strange. Are you guys using genkernel? Do you think that has anything to do with it? And what does the error message say?

----------

## supermihi

I am using genkernel because my root partition is on LVM2. I am trying to reboot now with the above changes to genkernel.conf and a new kernel, hope it will work.

----------

## mroconnor

hmmm emerging udev-096-r1 and etc-update did not solve the issue boot sequence still hangs at:

```

* Letting udev process events ...

```

Has this been filed as a bug? I didnt see anything yet. Any ideas on a fix?

Cheers

----------

## ArneBab

I just filed it as critical bug (can stop the system from booting): 

https://bugs.gentoo.org/show_bug.cgi?id=146860

----------

## supermihi

With udev-100 and the modified genkernel.conf, it now works for me. There are still some udev messages at boot, but they don't seem to be critical.

----------

## ArneBab

Great! 

It's a good feeling to be able to help  :Smile: 

----------

## supermihi

Yeah, thanks very much ... I don't know why genkernel.conf wasn't updated by etc-update.

----------

## mroconnor

ok....what gives?

 I have tried udev-099 & udev-100, run etc-update and I still can not boot. Unfortunatly I don't use genkernel so I have no genkernel.conf to change. I guess next I can try upgrading my kernel to 2.6.17-r7???

Damn you udev!!!!!!

 :Evil or Very Mad: 

Any thoughts?

Cheers

----------

## mroconnor

ok I lied....the kernel is 2.6.17-r6. 

BUT the system boots with gentoo-sources 2.6.17-r5.....more detective work!

----------

## ArneBab

Try setting the "symlink" useflag. 

Then an update should update your kernel symlink automatically. Maybe that sorts that out. 

But remember to emerge any external plugins again after buidling the kernel (like the ati-drivers, i.e.).

----------

## mroconnor

Well emerged 2.6.17-r7 last and all is well. I really hate udev updates...ugh.

Thanks for the help guys I appreciate it. 

Cheers  :Smile: 

----------

## Headrush

 *progresso wrote:*   

> more detective work!

 

 *progresso wrote:*   

> Damn you udev!!!!!! 

 

 *progresso wrote:*   

> I really hate udev updates...ugh.

 

That's what you get for insisting on running ~arch.   :Razz: 

----------

## olger901

 *Headrush wrote:*   

>  *progresso wrote:*   more detective work! 
> 
>  *progresso wrote:*   Damn you udev!!!!!!  
> 
>  *progresso wrote:*   I really hate udev updates...ugh. 
> ...

 

Well be glad that there are people running on ~arch, because they are the ones testing everything, reporting bugs to the developers to fix things which eventually leads to a stable version which YOU are using.

----------

## Headrush

 *olger901 wrote:*   

> Well be glad that there are people running on ~arch, because they are the ones testing everything, reporting bugs to the developers to fix things which eventually leads to a stable version which YOU are using.

 

It's a joke buddy. I'm running an ~arch version myself.

Plus, its a huge assumption that everyone running ~arch packages is indeed helping testing developersand that their info is useful.

(Sorry, some user have no clue. (I'm not not specifically referring to you progresso.)

And you're missing the irony in that if you HATE these problems, you shouldn't be one of the testers. We know ~arch can at times cause problems.   :Rolling Eyes: 

----------

## damato

Sorry guys, but can we please go back to the discussion as I am still searching for help.. I fully updated my arch system to the very latest with kernel 2.6.17-r8 and udev-100 and it immediately stops booting right after the message

 *Quote:*   

> 
> 
> * Letting udev process events...
> 
> 

 

Anyone have an idea what might be wrong and how to quickly fix it? I really can't figure out what might stop it from processing the events?!? I see no debug output nor any messages in any log file after I have booted from CD.

I also read through other entries in that forum, but unfortunatley they all seem to point into the direction that "coldplug" seems to be required, but since udev-98 no separate coldplug scripts are supported nor needed. I am really out of idea what might actually be the root of the issue.

Any help appreciated....

cheers,

jens

----------

## mroconnor

Headrush: I agree.....no offense taken m8. I enjoy running ~arch for two reasons.....learning and helping developers when I can...so cheers!

damato: I wish I could be more help but like you I did not find any good debug info either. If I come up with something I will let you know.

Good luck!

----------

## Leo Lausren

For me - with a new udev-100 - 

```
touch /dev/.tmp-3-0
```

 solved the problem.

----------

## damato

Hi,

 *Leo Lausren wrote:*   

> For me - with a new udev-100 - 
> 
> ```
> touch /dev/.tmp-3-0
> ```
> ...

 

And for me the update to the latest udev-100-r1 solved the problem as well. It seems the developers also finally noticed the issue. Now my system perfectly boots as expected. Moreover the system doesn't show the "Letting udev process events..." thing during bootup anymore.

No matter what, it works now and I can only suggest that everyone also having that problem updates to udev-100-r1 ASAP

cheers,

jens

----------

## Headrush

 *damato wrote:*   

> No matter what, it works now and I can only suggest that everyone also having that problem updates to udev-100-r1 ASAP

 

The changelog says that udev-100-r1 is very buggy and has a bootup issue and udev-100-r2 is recommended.

So don't update to udev-100-r1 ASAP.   :Razz:   :Smile: 

----------

## _dA_CyANIDe

Solution is here : https://bugs.gentoo.org/show_bug.cgi?id=147221

----------

## damato

Hi,

 *Headrush wrote:*   

>  *damato wrote:*   No matter what, it works now and I can only suggest that everyone also having that problem updates to udev-100-r1 ASAP 
> 
> The changelog says that udev-100-r1 is very buggy and has a bootup issue and udev-100-r2 is recommended.
> 
> So don't update to udev-100-r1 ASAP.   

 

Damn, you are right. So now I updated to udev-100-r2 and now my problem is back again  :Sad: 

The system immediately hangs on "Letting udev process events..." And also the "touch /dev/.tmp-3-0" didn't solve that issue.

So am I really the only one seeing this problem with recent kernels and udev versions? damn, I really just want to get that beast booting normally again....

cheers,

jens

----------

## _dA_CyANIDe

 *damato wrote:*   

> Hi,
> 
>  *Headrush wrote:*    *damato wrote:*   No matter what, it works now and I can only suggest that everyone also having that problem updates to udev-100-r1 ASAP 
> 
> The changelog says that udev-100-r1 is very buggy and has a bootup issue and udev-100-r2 is recommended.
> ...

 

Did you try this patch?

--- /sbin/rc.old	2006-09-11 19:49:06.000000000 -0700

+++ /sbin/rc	2006-09-11 19:49:41.000000000 -0700

@@ -289,7 +289,7 @@

 		if [ "${udev}" = "yes" ]

 		then

 			if get_bootparam "noudev" || \

-			   [ ! -x /sbin/udev -o ${devfs_automounted} = "yes" ] || \

+			   [ ! -x /sbin/udevd -o ${devfs_automounted} = "yes" ] || \

 			   [ "$(get_KV)" -lt "$(KV_to_int '2.6.0')" ]

 			then

 				udev="no"

@@ -426,7 +426,7 @@

 	export START_CRITICAL="yes"

 	# We do not want to break compatibility, so we do not fully integrate

-	# these into /sbin/rc, but rather start them by hand ...

+	# these into //rc, but rather start them by hand ...

 	for x in ${CRITICAL_SERVICES}

 	do

 		splash "svc_start" "${x}"

----------

## Sebi

Hi,

same here, system hangs at "letting udev process...". The patch proposed by _dA_CyANIDe won´t help as /sbin/rc from baselayout-1.12.5 contains another (proper?) udev check:

...

if get_bootparam "noudev" || ! has_addon udev-start.sh

...

Really annoying bug. I wonder why only a few persons come around this bug?!

Did anyone solve it yet?

Sebi

----------

## astaroth_pod

Exact same problem here, it hangs at the "Letting udev process events".

It does however only hang if both cores are enabled (Intel Core Duo) and the kernel version is 2.6.18.

If I disable dual core in the bios, it boots fine on 2.6.18.

If I boot 2.6.17, it works with both dual core and single core.

The udev is version 103, and it's been upgraded and etc-updated, and also removed completely and installed from scratch...

----------

## japrogrammer

Just to add one more data point.  Running 2.6.18-gentoo-r2 with udev-103.  Hangs after message "letting udev process events"

However if I change the udev_log variable in /etc/udev/udev.conf from "err" to "info" it boots, albeit slowly with a lot of extraneous messages in the console.  Maybe it is some sort of timing issue

----------

