View previous topic :: View next topic |
Author |
Message |
buptwugh Tux's lil' helper
Joined: 16 Jan 2012 Posts: 101 Location: Beijing,China
|
Posted: Wed Feb 29, 2012 3:07 am Post subject: [Solved] udevd failed to execute '/usr/sbin/alsactl' |
|
|
When the system boot
Some confuse message show:
Code: |
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,
Wugh
Last edited by buptwugh on Wed Feb 29, 2012 12:07 pm; edited 1 time in total |
|
Back to top |
|
|
VoidMage Watchman
Joined: 14 Oct 2006 Posts: 6196
|
Posted: Wed Feb 29, 2012 4:29 am Post subject: |
|
|
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. |
|
Back to top |
|
|
buptwugh Tux's lil' helper
Joined: 16 Jan 2012 Posts: 101 Location: Beijing,China
|
Posted: Wed Feb 29, 2012 4:45 am Post subject: |
|
|
Thanks,
But is there any method to fix it except changing my partitions |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Wed Feb 29, 2012 8:19 am Post subject: |
|
|
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 _________________
|
|
Back to top |
|
|
buptwugh Tux's lil' helper
Joined: 16 Jan 2012 Posts: 101 Location: Beijing,China
|
Posted: Wed Feb 29, 2012 12:06 pm Post subject: |
|
|
Thanks aCOSwt,
My Audio device work perfectly , So The Message should not be a problem.
Just Ignore this. |
|
Back to top |
|
|
VoidMage Watchman
Joined: 14 Oct 2006 Posts: 6196
|
Posted: Wed Feb 29, 2012 2:37 pm Post subject: |
|
|
@aCOSwt: bzzzzt, wrong - at least partially.
See the NEWS file in the udev tarball, the last block in 174 part. |
|
Back to top |
|
|
aCOSwt Bodhisattva
Joined: 19 Oct 2007 Posts: 2537 Location: Hilbert space
|
Posted: Wed Feb 29, 2012 3:26 pm Post subject: |
|
|
VoidMage wrote: | @aCOSwt: bzzzzt, wrong - at least partially.
See the NEWS file in the udev tarball, the last block in 174 part. |
Do you mean udev-174-news wrote: | The support for 'udevadm trigger --type=failed, and the
RUN{fail_event_on_error} attribute was removed. | ?
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
I infered it was buptwugh's case as well.
Thank you for the warning anyway. I'll take care on some future update. _________________
|
|
Back to top |
|
|
viralex Apprentice
Joined: 24 Apr 2008 Posts: 237 Location: Viareggio (Lu,Italy)
|
Posted: Fri Apr 13, 2012 9:30 pm Post subject: |
|
|
I have to manually run "udevadm trigger" to get soundcard revealed by pulseaudio ... every boot with udev-182-r3
udev-postmount script doesn't call udevadm trigger on new udev versions...
I could change postmount scpript myself
but i'd rather prefer to understand what's going on |
|
Back to top |
|
|
MerlinYoda n00b
Joined: 23 May 2007 Posts: 17 Location: Indiana, United States, Earth, Sol System, Milky Way Galaxy, "The Universe"
|
Posted: Wed Sep 19, 2012 6:28 am Post subject: |
|
|
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. |
|
Back to top |
|
|
|