# udev problems, cant boot anymore

## wiier

well... whenever i boot my system i get the following error somewhere in the middle of the init proccess:

```

udevd -event[####]: run_program: exec of program '/sbin/udev_run_devd' failed

udevd -event[####]: run_program: exec of program '/sbin/udev_run_hotplugd' failed

```

change the '####'s with an increasing number, and those two lines repeat themselves on and on and on forever

i really dont know what going on, i tried all i can but with no use  :Sad: 

some of the things i tried:

-change 'udev' to 'static' in /etc/conf.d/rc

-update world

-enable the use of a tarball for devices in /etc/conf.d/rc

and maybe some other things i forgot...

----------

## HTS

What kernel are you using? Do you actually need udev? Did you try to un-merge re-emerge it? 

The binaries should be where udev expects them: what do you get if you do a 

```
ls -l /sbin | grep udev
```

I get 

```
ls -l /sbin | grep udev

-rwxr-xr-x 1 root root  39840 Jun 28 22:08 udev

-rwxr-xr-x 1 root root   7952 Jun 28 22:08 udev_run_devd

-rwxr-xr-x 1 root root   7740 Jun 28 22:08 udev_run_hotplugd

-rwxr-xr-x 1 root root  10432 Jun 28 22:08 udevcontrol

-rwxr-xr-x 1 root root  48120 Jun 28 22:08 udevd

-rwxr-xr-x 1 root root  14780 Jun 28 22:08 udevsettle

-rwxr-xr-x 1 root root  39860 Jun 28 22:08 udevstart

-rwxr-xr-x 1 root root  14868 Jun 28 22:08 udevtrigger

```

Try 

```
emerge -C udev

emerge udev
```

If this doesn't solve your issue, the links are not created for some reason during the emerge, or you may have messed up with an etc-update. Try 

```
slocate -u /

locate udev_run_devd
```

 and manually create the links.

Cheers then,

HTS

----------

## wiier

thanks for your reply..

i tried to remerge it, unmerge and merge again, but nothing changed

it seems to be that 'udevsettle' and 'udevtrigger' are missing from /sbin , i also have 'udevsend' which you dont seem to have

sorry for not giving all the info in the first post, my head was spinning that night -_- im using gentoo-sources-2.6.16-r9, and udev-087-r1

im going to try and unmask udev-90-r1 and see what happens

----------

## wiier

tried udev-90 and it didnt do any thing...

 *Quote:*   

> 
> 
> If this doesn't solve your issue, the links are not created for some reason during the emerge, or you may have messed up with an etc-update. Try
> 
> ```
> ...

 

can you tell me what links to what? im kinda lost here  :Sad: 

----------

## HTS

Hmmmm.... the locate didn't return anything? Means you don't have the executables installed? Maybe you use the nvidia drivers?

My config is:

kernel: sys-kernel/gentoo-sources 2.6.17

udev: sys-fs/udev-094

Your version differs, but: 

```
locate udev | grep bin
```

 should return something. Can you post the log of the merge?

```
cat /var/log/emerge.log | grep udev-090
```

I guess your kernel config is ok?

```
General setup --->

  [*] Support for hot-pluggable devices

File systems --->

  [*] Inotify file change notification support

  Pseudo filesystems --->

    [*] /proc file system support

    [*] Virtual memory file system support (former shm fs)
```

You can also refer to the Gentoo udev Guide for more info.

We need an expert here, something must be broken somewhere....   :Evil or Very Mad: 

----------

## wiier

The binaries are there, 'udevsettle' and 'udevtrigger' did show up after i merged udev-90-r1

I was asking about when you said "manually create the links", what links? And to what?

I dont have

```

General setup --->

  [*] Support for hot-pluggable devices

```

in my kernel :s i guess its 2.6.17 only...

I can't post the log right now, but it has nothing interesting, just a log of a normal sucessful merge. Anyway I'll post it later.

PS: It used to work perfectly using the same kernel  :Sad: 

All that I remmeber that might have caused the trouble in the first place is emerging fuse (which I will unmerge now), and adding a user to the "disk" group while gnome-volume-manager was running (i have undone this, but i dont know about any other side effects)

----------

## HTS

Sorry for the late reply I was away from my computer.

For the links; I was talking about the binaries that cause the errors:

'/sbin/udev_run_devd'

'/sbin/udev_run_hotplugd'

My first idea was that the binaries were not present or in the wrong place for some reason. So in that case you could have created some links from these binaries to /sbin/

If the binaries are there and the errors remain... I don't know what the problem might be.

Did you try udev-0.94?

I wish I could help more.

Found that on google: *Quote:*   

> On Wednesday 15 February 2006 22:12, Christian Beutenmueller wrote:
> 
> > Comments/Problems:
> 
> > udevd-event[xxxx]: run_program: exec of program
> ...

 You definitely need to try udev-0.94

----------

## five0

I getting the same (many) messages with udev-094.

edit: I'm using 2.6.17 (beyond-sources)

```

# ls -al /sbin | grep udev

-rwxr-xr-x 1 root root  36808 2006-07-06 18:51 udev*

-rwxr-xr-x 1 root root   9948 2006-07-06 18:51 udevcontrol*

-rwxr-xr-x 1 root root  47372 2006-07-06 18:51 udevd*

-rwxr-xr-x 1 root root   7120 2006-07-06 18:51 udev_run_devd*

-rwxr-xr-x 1 root root   6992 2006-07-06 18:51 udev_run_hotplugd*

-rwxr-xr-x 1 root root  14208 2006-07-06 18:51 udevsettle*

-rwxr-xr-x 1 root root  39092 2006-07-06 18:51 udevstart*

-rwxr-xr-x 1 root root  14228 2006-07-06 18:51 udevtrigger*

```

----------

## mebrelith

I just noticed this with udev 096... it seems something in udev is looking for vol_id, path_id, ata_id and edd_id in /lib/udev/ when they actually are in /sbin/...

Im clueless so far...

----------

## MerlinTheWizard

Yup, just happened to me too after upgrading to udev-096. All was fine before that with udev-094.

It doesn't prevent my comp from booting, but it's certainly annoying and probably not what should be expected. What happened?

----------

## geekounet

I've managed to correct these errors with udev 096. Just look for each IMPORT{program}= in /etc/udev/rules.d/* and correct the path of the executable by prefixing if with /sbin/.

For example :

```
BUS=="usb", IMPORT{program}="usb_id -x"          <== wrong line 

BUS=="usb", IMPORT{program}="/sbin/usb_id -x"    <== corrected line
```

Hope this to be usefull  :Smile: 

----------

## MerlinTheWizard

 *pierreg wrote:*   

> I've managed to correct these errors with udev 096. Just look for each IMPORT{program}= in /etc/udev/rules.d/* and correct the path of the executable by prefixing if with /sbin/.
> 
> For example :
> 
> ```
> ...

 

Nicely spotted.

Can't believe that went unnoticed...  :Shocked: 

----------

## jasn

I have the same problem with suspend2-sources-2.6.17-r2 and udev 096. Edited the following udev rules files;

/etc/udev/rules.d/60-persistent-input.rules

/etc/udev/rules.d/60-persistent-storage.rules

for instances of ata_id, edd_id, path_id, scsi_id, usb_id, and vol_id, so they include the full path. (i.e. /sbin/ata_id)

Now no more udev error messages when booting. However, I have another annoying problem since updating my system last. When the boot process is completing, gdm comes up and after a few seconds, I get kicked back out to the boot screen during the net setup. Then the boot process completes and it sits waiting at the text login screen. I have to hit Alt-F7 to get back to the gdm login screen. I guess it's not udev related, but I don't know what's causing it.. (perhaps it was the xgl update I picked up with the udev update..)

----------

## abhay

Thanks for the program tip. That solved the error here as well  :Smile: 

 *jasn wrote:*   

> However, I have another annoying problem since updating my system last. When the boot process is completing, gdm comes up and after a few seconds, I get kicked back out to the boot screen during the net setup. Then the boot process completes and it sits waiting at the text login screen. I have to hit Alt-F7 to get back to the gdm login screen. I guess it's not udev related, but I don't know what's causing it.. (perhaps it was the xgl update I picked up with the udev update..)

 

Wow! I never even thought that someone else could be also having this exactly same problem. Though, I don't have XGL installed it seems to be a splashutils thing. Do you have splashutils installed? I updated to the latest 1.3-r1 version last time and it started happening since then. Here are other programs that I updated

```
     Sun Jul 16 00:13:07 2006 >>> media-gfx/splashutils-1.3-r1

     Sun Jul 16 03:30:33 2006 >>> sys-apps/portage-2.1.1_pre3

     Sun Jul 16 03:31:05 2006 >>> sys-apps/help2man-1.36.4

     Sun Jul 16 03:32:00 2006 >>> x11-libs/libdrm-2.0.2

     Sun Jul 16 03:33:22 2006 >>> sys-fs/udev-096

     Sun Jul 16 04:31:46 2006 >>> net-im/kopete-0.12.1

     Sun Jul 16 04:40:15 2006 >>> media-gfx/gwenview-1.3.92

     Sun Jul 16 04:41:08 2006 >>> app-editors/nano-1.3.12-r1

     Sun Jul 16 04:41:40 2006 >>> sys-libs/libcap-1.10-r8

     Sun Jul 16 04:42:34 2006 >>> app-arch/unrar-3.6.7
```

----------

## michel7

The same problem here, solved after updating /etc/udev/rules.d/60-persistent-input.rules and 

/etc/udev/rules.d/60-persistent-storage.rules

Thank you!

----------

## Marx

Exactly the same problem, Thanks for the easy solution  :Smile: 

----------

## MerlinTheWizard

 *abhay wrote:*   

> 
> 
>  *jasn wrote:*   However, I have another annoying problem since updating my system last. When the boot process is completing, gdm comes up and after a few seconds, I get kicked back out to the boot screen during the net setup. Then the boot process completes and it sits waiting at the text login screen. I have to hit Alt-F7 to get back to the gdm login screen. I guess it's not udev related, but I don't know what's causing it.. (perhaps it was the xgl update I picked up with the udev update..) 
> 
> Wow! I never even thought that someone else could be also having this exactly same problem. Though, I don't have XGL installed it seems to be a splashutils thing. Do you have splashutils installed? I updated to the latest 1.3-r1 version last time and it started happening since then.

 

I get this exact problem too on my other gentoo box, although on this one, everything's fine now that I have corrected the udev rules files!

They both have the latest splashutils, so I don't know what went wrong...

----------

## jasn

 *abhay wrote:*   

> Wow! I never even thought that someone else could be also having this exactly same problem. Though, I don't have XGL installed it seems to be a splashutils thing. Do you have splashutils installed? I updated to the latest 1.3-r1 version last time and it started happening since then.

 

Abhay,

Thanks very much for that. With your reminder, I remembered that splashutils was also updated on my system with the most recent update. So I emerged the prior version;

emerge =media-gfx/splashutils-1.1.9.10-r1

and my boot process is back to normal. Don't know what in 1.3-r1 was causing the switch problem, but running the earlier splashutils seems to have fixed it for me.. Thanks again..

----------

## corsair

Hi,

I just hit the same problem with udev 096 and found this forum entry. unfortunatly it would have been nice to open a bug for this to get a solution into portage (or did my bugzilla search just did not find it?).   :Rolling Eyes: 

So I did: Bug #140668

Regards,

Markus

----------

## HTS

Yup, this is a bug in udev 0.96... Weird that it went unnoticed so far...   :Rolling Eyes: 

The fix is simple enough to quickly release a patch...   :Rolling Eyes: 

 *Georgi Georgiev wrote:*   

> Shouldn't helper programs be installed in /lib/udev anyway? For consistency
> 
> with upstream?
> 
>  *Quote:*   RELEASE-NOTES: udev 089
> ...

 

----------

## dencar

Thank you, jasn. The latest udev versions seem to be betas.

----------

## HTS

The bug was fixed in udev-096-r1

You can safely etc-update your udev config files.

----------

## MerlinTheWizard

 *HTS wrote:*   

> The bug was fixed in udev-096-r1
> 
> You can safely etc-update your udev config files.

 

was it? After upgrading to udev-096-r1 and etc-updating, the paths to the udev utilities are again without the "/sbin/" prefix. Is that normal?

----------

## HTS

Yes because that's the correct path. The bug was that the binaries were not in the right place.

Well, the messages disappeared on my box after upgrading to 0.96-r1

If you want to know more, you can read the conversation in Bug #140668.   :Laughing: 

----------

## jasn

 *jasn wrote:*   

> Edited the following udev rules files;
> 
> /etc/udev/rules.d/60-persistent-input.rules
> 
> /etc/udev/rules.d/60-persistent-storage.rules
> ...

 

As noted the updated udev 096-r1 now installs the above mentioned programs into /lib/udev/ which meant that when I updated to this new udev, I needed to go back and re-edit the same rules files mentioned above, and now DELETE the /sbin/ path wherever I added it previously. Oh well.. teach me to make a backup file of the original from now on..

----------

## HTS

 *jasn wrote:*   

> As noted the updated udev 096-r1 now installs the above mentioned programs into /lib/udev/ which meant that when I updated to this new udev, I needed to go back and re-edit the same rules files mentioned above, and now DELETE the /sbin/ path wherever I added it previously. Oh well.. teach me to make a backup file of the original from now on..

 

Or you can use Vim and easily delete all your sbins with a one-liner   :Smile: 

----------

## geekounet

 *HTS wrote:*   

>  *jasn wrote:*   As noted the updated udev 096-r1 now installs the above mentioned programs into /lib/udev/ which meant that when I updated to this new udev, I needed to go back and re-edit the same rules files mentioned above, and now DELETE the /sbin/ path wherever I added it previously. Oh well.. teach me to make a backup file of the original from now on.. 
> 
> Or you can use Vim and easily delete all your sbins with a one-liner  

 

Or just run etc-update.

----------

## HTS

 *pierreg wrote:*   

>  *HTS wrote:*    *jasn wrote:*   As noted the updated udev 096-r1 now installs the above mentioned programs into /lib/udev/ which meant that when I updated to this new udev, I needed to go back and re-edit the same rules files mentioned above, and now DELETE the /sbin/ path wherever I added it previously. Oh well.. teach me to make a backup file of the original from now on.. 
> 
> Or you can use Vim and easily delete all your sbins with a one-liner   
> 
> Or just run etc-update.

 Unless you have personal settings in the file  :Wink: 

----------

## geekounet

 *HTS wrote:*   

>  *pierreg wrote:*    *HTS wrote:*    *jasn wrote:*   As noted the updated udev 096-r1 now installs the above mentioned programs into /lib/udev/ which meant that when I updated to this new udev, I needed to go back and re-edit the same rules files mentioned above, and now DELETE the /sbin/ path wherever I added it previously. Oh well.. teach me to make a backup file of the original from now on.. 
> 
> Or you can use Vim and easily delete all your sbins with a one-liner   
> 
> Or just run etc-update. Unless you have personal settings in the file 

 

Personnal settings must be in an other file, for example /etc/udev/rules.d/01-custom.rules. This way, you can safely update the other files.

----------

## HTS

pierreg you are right indeed, that's why said that in my earlier post:

 *HTS wrote:*   

> The bug was fixed in udev-096-r1
> 
> You can safely etc-update your udev config files.

 

I was trying to figure out why jasn wanted to manually update his config files and I thought he might have some tweaks in them  :Smile: 

----------

## pholthau

things are starting to get weird.

first i got the same problem as stated in the first post. various failure messages about usb_id etc. showed up at boot time.

then i followed the hint to change the executable to /sbin/... seemed to work. now i read here that the new udev 096-r1 corrects the problems so i decided to upgrade. now everything is messed  :Wink:  there are no more messages at boot time that binaries are missing so i guess these are found.

but now there are messages about wireless lan and bluetooth about not getting started during boot. if i do "modprobe ipw2100" wlan will get to work perfectly but seems as the modules are not loaded at boot time  :Sad:  same with bluetooth and usb mouse...

do you have any hints why this happens, i switched to 094 now.

----------

## sjaveed

 *HTS wrote:*   

> The bug was fixed in udev-096-r1
> 
> You can safely etc-update your udev config files.

 

Folks, looks like either I'm doing something wrong or this is a different bug.  I'm running the following system:

Hardware: AthlonXP 1800 + 1G RAM + GeForce3Ti200 + 3 tuners (PVR-350, VoodooTV 200, STB TV-PCI - yes I know the last two are ancient  :Wink: )

Arch: ~x86

Profile: 2006.0

kernel-2.6.17-gentoo-r5 - compiled time and time again with slight variations e.g. removing usb devices etc

ivtv-0.7.0

udev-096-r1 - emerged and re-emerged a couple of times  :Smile: 

I've verified that the usb_id and other _id utilities are all in /lib/udev and that any rules files with IMPORT{program} directives are pointing to binaries that are all in /lib/udev.

My problem occurs at boot when I see a message saying "Letting udev process events" and the machine hangs shortly thereafter.  I do notice that my TV shows me a green screen the same way it should when the ivtv driver loads but the green screen doesn't go away.  This lead me the think that perhaps the ivtv driver was outdated so I re-emerged that a few times but no luck.  The gentoo livecd boots up fine of course.

Any ideas?  Anything I should check for and re-post in the forum?

Thanks!

----------

## sjaveed

Folks,

Looks like my problem wasn't udev after all :-/  Looks like after I unmerged ivtv (instead of re-emerging it) I was able to boot into my system just fine.  The problem seems to be that ivtv and bttv (the kernel driver for the older cards) don't seem to like each other too much.

After booting into the box I emerged ivtv after removing all copies of the downloaded files and any dependency caches etc and tried to modprobe ivtv-fb.  Lo and behold, /var/log/messages had a message where ivtv said it couldn't connect to the pvr-350 etc and a few seconds later it went belly up.  Hopefully after unmerging ivtv, recompiling the kernel w/o support for bttv and re-emerging ivtv, I should be good.

On that note, is there a reason why an unmerge of ivtv didn't clean out the kernel modules it installed in /lib/modules?

Thanks!

----------

## HTS

This seems related to some new udev/baselayout approach. The "letting udev process events" will coldplug and hotplug lots of device. I guess the idea of this new behaviour is to eventually remove the "modules.autoload".

You can still revert back to the old behaviour by changing entries in /etc/conf.d/rc

RC_HOTPLUG="no"

RC_COLDPLUG="no"

----------

## Gentree

unless you really enjoy this sort of shit , just lock your udev once it works (package.mask) and dont update it until there's a good reason. 

```
bash-3.1#emp udev

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-fs/udev-079-r1  

```

I got bored with this sort of jive a long time back.

Of course if you find it fun , carry on.

 :Cool: 

----------

