# [Solved] udevd  failed to execute '/usr/sbin/alsactl'

## buptwugh

When the system boot

Some confuse message show:

```

udev[16025]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 0': No such file or directory 

udev[16029]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 1': No such file or directory 

```

How to fix it?

I find the answer by Google.

And It seem that I can not put "/usr" on separate partition.

Thank you,

WughLast edited by buptwugh on Wed Feb 29, 2012 12:07 pm; edited 1 time in total

----------

## VoidMage

The simple answer is that /usr needs to be accessible when udev is run - it means if /usr is separate, initramfs needs to mount it.

----------

## buptwugh

Thanks,

But is there any method to fix it except changing my partitions

----------

## aCOSwt

VoidMage is indeed correct and initramfs is probably a solution for you.

However :

1/ Keep in mind that your problems might not be limited to /usr.

alsactl restore will need /var/lib/alsa/asound.state

So, if your /var tree is also in a separate partition...

2/ If this is the only problem you face with udev at boot then it should not be a problem.

I get this kind of messages too but my system works perfectly well and the mixer levels are actually restored.

Check if they are correctly restored on your system and if it is the case then...

You can safely ignore these messages and the initramfs workaround becomes needless.

How comes ? *udev-postmount wrote:*   

> 
> 
> # Run the events that failed at first udev trigger
> 
> udevadm trigger --type=failed -v

 

Basically, all the scripts that will have failed before localmount are put into a queue and will be retried after localmount.

As you do not get you error repeated, it simply means that these scripts were successful at postmount.

There is an interesting debate about all this (and more) you can find there : http://archives.gentoo.org/gentoo-dev/msg_948f10553ba75ca1b99b08f17e842f9d.xml

----------

## buptwugh

Thanks aCOSwt,

My  Audio device work perfectly , So The Message should not be a problem.

Just Ignore this.

----------

## VoidMage

@aCOSwt: bzzzzt, wrong - at least partially.

See the NEWS file in the udev tarball, the last block in 174 part.

----------

## aCOSwt

 *VoidMage wrote:*   

> @aCOSwt: bzzzzt, wrong - at least partially.
> 
> See the NEWS file in the udev tarball, the last block in 174 part.

 

 :Embarassed: 

Do you mean  *udev-174-news wrote:*   

> The support for 'udevadm trigger --type=failed, and the
> 
> RUN{fail_event_on_error} attribute was removed.

 ?

 :Evil or Very Mad: 

Well well... I was forced to fetch this 174 version on sources.buildroot.net

BTW, I am running Gentoo you know and latest portage's normally available version for udev is 171  :Wink: 

I infered it was buptwugh's case as well.

Thank you for the warning anyway. I'll take care on some future update.   :Evil or Very Mad: 

----------

## viralex

I have to manually run "udevadm trigger" to get soundcard revealed by pulseaudio ... every boot with udev-182-r3  :Evil or Very Mad: 

udev-postmount script doesn't call udevadm trigger on new udev versions...

I could change postmount scpript myself   :Confused: 

but i'd rather prefer to understand what's going on

----------

## MerlinYoda

I realize I'm a little late to the game on this one, but I just figured out that the root source of the error messages which the OP posted is actually due to a script placed into udev's rules.d directory by the media-sound/alsa-utils package (specific file being /lib/udev/rules.d/90-alsa-restore.rules). 

My particular solution was to have /usr in the root file system (a partition on a (Fake)RAID1 HDD array) so that the necessary files would be present prior to the "real" /usr partition (residing on an SSD) being mounted over the afformentioned /usr folder. This way I get both a speed boost and redundancy out of the deal (as long as I make a point to back up the data in the SSD partition to the underlying the root file system as needed). However, in cases where such data duplication is either not desired or not an option, the aformentioned script file may be set aside (either deleted or tucked out of the way somewhere else in the filesystem) and the errors should disappear on startup.

Also, since the alsasound init script should (and seems to) *already* handle this, as it was touched upon earlier posts, the udev script shouldn't be necessary to have working sound. Given this, it would apper that alsa-utils really *shouldn't* be adding this script to udev rules.d directory in the first place but handling these details itself (and only once everything in fstab has actually been *mounted* first!!!) rather than to shuffe this particular task off through the udev init script for whatever reasons they had for doing so in the first place.

----------

