[arch-general] Fwd: udev events and /usr not mounted
---------- Forwarded message ---------- From: Myra Nelson <outerrimlogging@gmail.com> Date: Fri, Nov 25, 2011 at 15:45 Subject: udev events and /usr not mounted To: General Discussion about Arch Linux <arch-general@archlinux.org> No gripes, complaints, or rants, just a question about udev rules. This is one of those /usr not mounted things that's broken. Fri Nov 25 12:06:54 2011: :: Loading User-specified Modules [BUSY] udevd[398]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 0': No such file or directory It's easy to work around but I was wondering, is it possible to move 78-sound-card.rules and/or 90-alsa-restore.rules to say /etc/udev/rules.d then source them, myself, after /usr is mounted? Or would that cause other unwanted and unnecessay problems, security issues, or just plain not work? Currently I don't want to try to migrate /usr to /. / is only 4 GB and /usr is 8+ GB and everything works to well so I'll just do a fresh install later. Otherwise sudo /usr/bin/alsactl start works well. Myra Brain Dead -- Chaos! Panic! Disaster! (My work here is done) -- Life's fun when your sick and psychotic!
Am 25.11.2011 23:44, schrieb Myra Nelson:
---------- Forwarded message ---------- From: Myra Nelson <outerrimlogging@gmail.com> Date: Fri, Nov 25, 2011 at 15:45 Subject: udev events and /usr not mounted To: General Discussion about Arch Linux <arch-general@archlinux.org>
No gripes, complaints, or rants, just a question about udev rules. This is one of those /usr not mounted things that's broken.
Fri Nov 25 12:06:54 2011: :: Loading User-specified Modules [BUSY] udevd[398]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 0': No such file or directory
It's easy to work around but I was wondering, is it possible to move 78-sound-card.rules and/or 90-alsa-restore.rules to say /etc/udev/rules.d then source them, myself, after /usr is mounted? Or would that cause other unwanted and unnecessay problems, security issues, or just plain not work?
Currently I don't want to try to migrate /usr to /. / is only 4 GB and /usr is 8+ GB and everything works to well so I'll just do a fresh install later. Otherwise sudo /usr/bin/alsactl start works well.
Myra
Brain Dead
You can work around this by mounting /usr from initramfs. There are RFC patches around for doing this, I don't know where right now (search this mailing list, this topic has come up). It is known that having /usr separate causes problems like the ones you describe, see [1]. [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
On Fri, Nov 25, 2011 at 11:44 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
---------- Forwarded message ---------- From: Myra Nelson <outerrimlogging@gmail.com> Date: Fri, Nov 25, 2011 at 15:45 Subject: udev events and /usr not mounted To: General Discussion about Arch Linux <arch-general@archlinux.org>
No gripes, complaints, or rants, just a question about udev rules. This is one of those /usr not mounted things that's broken.
Fri Nov 25 12:06:54 2011: :: Loading User-specified Modules [BUSY] udevd[398]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 0': No such file or directory
It's easy to work around but I was wondering, is it possible to move 78-sound-card.rules and/or 90-alsa-restore.rules to say /etc/udev/rules.d then source them, myself, after /usr is mounted? Or would that cause other unwanted and unnecessay problems, security issues, or just plain not work?
You can't really "source" udev rules, so I don't think this would work (you'd have to somehow replay the relevant events, but I don't know how you'd manage to only trigger some specific rule files, so I don't think it is a good idea). You could just wait for the /usr support to land in initramfs (should be "any day now"), which would solve this and similar problems. However, I think in the case of alsa, this is not a real problem. Provided you also enable the alsa rc script. If I understand correctly it is ok for the alsa udev rules to fail on boot, because the rc script would anyway do the same job (restore mixer levels). The point of the udev rules is to deal with hotplugged sound devices that are added after boot (and hence would not be dealt with by the rc script). I have not looked at the rules/scripts in any detail so please take this with a grain of salt :-) Cheers, Tom
On Fri, Nov 25, 2011 at 17:21, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Nov 25, 2011 at 11:44 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
---------- Forwarded message ---------- From: Myra Nelson <outerrimlogging@gmail.com> Date: Fri, Nov 25, 2011 at 15:45 Subject: udev events and /usr not mounted To: General Discussion about Arch Linux <arch-general@archlinux.org>
No gripes, complaints, or rants, just a question about udev rules. This is one of those /usr not mounted things that's broken.
Fri Nov 25 12:06:54 2011: :: Loading User-specified Modules [BUSY] udevd[398]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl restore 0': No such file or directory
It's easy to work around but I was wondering, is it possible to move 78-sound-card.rules and/or 90-alsa-restore.rules to say /etc/udev/rules.d then source them, myself, after /usr is mounted? Or would that cause other unwanted and unnecessay problems, security issues, or just plain not work?
You can't really "source" udev rules, so I don't think this would work (you'd have to somehow replay the relevant events, but I don't know how you'd manage to only trigger some specific rule files, so I don't think it is a good idea).
You could just wait for the /usr support to land in initramfs (should be "any day now"), which would solve this and similar problems.
However, I think in the case of alsa, this is not a real problem. Provided you also enable the alsa rc script. If I understand correctly it is ok for the alsa udev rules to fail on boot, because the rc script would anyway do the same job (restore mixer levels). The point of the udev rules is to deal with hotplugged sound devices that are added after boot (and hence would not be dealt with by the rc script). I have not looked at the rules/scripts in any detail so please take this with a grain of salt :-)
Cheers,
Tom
Tom: Thanks for the reply. As I said it's not a problem, I was just trying to determine how or if I needed to correct the problem. It doesn't seem to cause any problems and as I said, sudo /usr/bin/alsactl restore works from a terminal after the machine boots. Myra -- Life's fun when your sick and psychotic!
Myra Nelson wrote:
Currently I don't want to try to migrate /usr to /. / is only 4 GB and /usr is 8+ GB and everything works to well so I'll just do a fresh install later. Otherwise sudo /usr/bin/alsactl start works well.
You could also put a line into etc/rc.local : /etc/rc.d/alsa start || echo "cannot '/etc/rc.d/alsa start': $?" clemens
On Sat, Nov 26, 2011 at 9:27 PM, clemens fischer <ino-news@spotteswoode.dnsalias.org> wrote:
Myra Nelson wrote:
Currently I don't want to try to migrate /usr to /. / is only 4 GB and /usr is 8+ GB and everything works to well so I'll just do a fresh install later. Otherwise sudo /usr/bin/alsactl start works well.
You could also put a line into etc/rc.local :
/etc/rc.d/alsa start || echo "cannot '/etc/rc.d/alsa start': $?"
Should be enough to add "alsa" to your DAEMONS array in rc.conf. /usr is always mounted by the time the daemons are started. Cheers, Tom
On Sat, Nov 26, 2011 at 14:35, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Nov 26, 2011 at 9:27 PM, clemens fischer <ino-news@spotteswoode.dnsalias.org> wrote:
Myra Nelson wrote:
Currently I don't want to try to migrate /usr to /. / is only 4 GB and /usr is 8+ GB and everything works to well so I'll just do a fresh install later. Otherwise sudo /usr/bin/alsactl start works well.
You could also put a line into etc/rc.local :
/etc/rc.d/alsa start || echo "cannot '/etc/rc.d/alsa start': $?"
Should be enough to add "alsa" to your DAEMONS array in rc.conf. /usr is always mounted by the time the daemons are started.
Cheers,
Tom
To all: Alsa is in my daemons array and starts. The problem is the udev rule to restore the volume levels fails as it is run before /usr is mounted. That's why I was asking about udev rules and why [ /usr/bin/alsactl restore ] works from the console after I've booted. After reading through the initscripts, rc.d, and mkinitcpio code I think it may be possible to run: [ run_hook sysinit_postmount udevam control --reload-rules run_hook single_end ] in rc.local. I have some research to do. My thought process was to automate the task, laziness is the mother of invention, rather than remembering to run alsactl restore after I boot. Thanks for the replies. Maybe Dave could weigh in on this for some clarification on the hooks for the rc files and if I'm on the right track. Myra -- Life's fun when your sick and psychotic!
Myra Nelson wrote:
Alsa is in my daemons array and starts. The problem is the udev rule to restore the volume levels fails as it is run before /usr is mounted. That's why I was asking about udev rules and why [ /usr/bin/alsactl restore ] works from the console after I've booted. After reading through the initscripts, rc.d, and mkinitcpio code I think it may be possible to run:
[ run_hook sysinit_postmount
udevam control --reload-rules
run_hook single_end ]
in rc.local.
The hooks don't work like this, rc.local might run too late. You'd make a file eg. /etc/rc.d/functions.d/my-hooks.sh: my_sysinit_postmount_udevadm() { udevadm control --reload-rules || echo "my_sysinit_postmount_udevadm: udevadm err $?" return 0 } add_hook sysinit_postmount my_sysinit_postmount_udevadm Putting the file into etc/rc.d/functions.d/ will let the hooks system see and source it, and add_hook() will put your function into the array of functions to run at a specific point. The list of hooks is in etc/rc.d/functions and a custom hook function is a regular shell function. No special error handling or sandboxing is done on them, so you want to make sure they don't block or kill the shell. This is why I'd recommend to use the "|| ..." clause after some user command and to return a zero at the end, though ATM neither seems strictly necessary. It will make a hook funtion future proof, I presume. clemens
On Sun, Nov 27, 2011 at 13:06, clemens fischer < ino-news@spotteswoode.dnsalias.org> wrote:
Myra Nelson wrote:
Alsa is in my daemons array and starts. The problem is the udev rule to restore the volume levels fails as it is run before /usr is mounted. That's why I was asking about udev rules and why [ /usr/bin/alsactl restore ] works from the console after I've booted. After reading through the initscripts, rc.d, and mkinitcpio code I think it may be possible to run:
[ run_hook sysinit_postmount
udevam control --reload-rules
run_hook single_end ]
in rc.local.
The hooks don't work like this, rc.local might run too late.
You'd make a file eg. /etc/rc.d/functions.d/my-hooks.sh:
my_sysinit_postmount_udevadm() { udevadm control --reload-rules || echo "my_sysinit_postmount_udevadm: udevadm err $?" return 0 } add_hook sysinit_postmount my_sysinit_postmount_udevadm
Putting the file into etc/rc.d/functions.d/ will let the hooks system see and source it, and add_hook() will put your function into the array of functions to run at a specific point. The list of hooks is in etc/rc.d/functions and a custom hook function is a regular shell function. No special error handling or sandboxing is done on them, so you want to make sure they don't block or kill the shell. This is why I'd recommend to use the "|| ..." clause after some user command and to return a zero at the end, though ATM neither seems strictly necessary. It will make a hook funtion future proof, I presume.
clemens
Clemens:
Thanks for the reply. I figured out the hook didn't work that way but it didn't keep me from booting. Removing the run_hook around the udevadm command and leaving it in rc.local takes care of the problem. It's only necessary to restore the volume state stored in the asound file in /etc and the udevadm command takes care of it. However I will take your response and study the hooks and how to use them and learn something from this experience. Myra -- Life's fun when your sick and psychotic!
participants (4)
-
clemens fischer
-
Myra Nelson
-
Thomas Bächler
-
Tom Gundersen