LinuxQuestions.org - [SOLVED] sound issues in -current

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - sound issues in -current (https://www.linuxquestions.org/questions/slackware-14/sound-issues-in-current-4175582049/)

sound issues in -current

I have been battling sound issues for quite a while now with no success. The problems seem to get more difficult with each batch of updates. Upon reboot I will have no sound, pulseaudio will even eventually crash. After restarting kaudio sound will return I assume falling back to ALSA. The problem seems to go all the way back to the boot process:

Code:

[    5.206907] udevd[1991]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/sg1': No such file or directory

[    5.240704] udevd[2000]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/sr0': No such file or directory

[    5.485454] udevd[2062]: failed to execute '/usr/sbin/obex-check-device' '/usr/sbin/obex-check-device 04f2 b071': No such file or directory

[    5.523459] udevd[2066]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/seq': No such file or directory

[    5.526279] udevd[2067]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/sequencer': No such file or directory

[    5.527388] udevd[2068]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/sequencer2': No such file or directory

[    5.527880] udevd[2070]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/timer': No such file or directory

[    5.645699] udevd[2080]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/pcmC1D2p': No such file or directory

[    5.646240] udevd[2078]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/controlC1': No such file or directory

[    5.646681] udevd[2081]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/audio1': No such file or directory

[    5.647321] udevd[2079]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/dsp1': No such file or directory

[    5.648291] udevd[2082]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/pcmC1D0c': No such file or directory

[    5.648844] udevd[2084]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/hwC1D0': No such file or directory

[    5.649497] udevd[2083]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/snd/pcmC1D0p': No such file or directory

[    5.650138] udevd[2085]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/mixer1': No such file or directory

[    5.948629] udevd[2098]: failed to execute '/lib/udev/udev-acl' 'udev-acl --action=add --device=/dev/video0': No such file or directory

According to some of the posts I have already read, having /usr on its own partition is at least part of this problem. I have not been able to figure out how to remedy that yet.

This seems to be the most logical place to start, I'll jump the pulseaudio hurdles once I get this sorted out.

Just a shot in the dark, because I'm not familiar enough with what does what and when on the boot process, but maybe you need to add your sound modules into the initrd if udev is trying to add entries to /dev/ before /usr/ is mounted.

On second look, maybe it's actually /lib/ not mounting soon enough, and it can't find the command /lib/udev/udev-acl?

If /usr is on its own partition, the initrd won't find udev-acl.

Code:

cranium@hp635:/boot/initrd-tree$ ls -l lib/udev/udev-acl 

lrwxrwxrwx 1 root root 21 Apr  4 08:20 lib/udev/udev-acl -> /usr/libexec/udev-acl*

flacy@hp635:/boot/initrd-tree$

Code:

bash-4.3# lsblk

NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda      8:0    0 111.8G  0 disk 

|-sda1  8:1    0  9.3G  0 part /

|-sda2  8:2    0    1K  0 part 

|-sda3  8:3    0  37.3G  0 part /usr

|-sda4  8:4    0  62.9G  0 part /home

`-sda5  8:5    0  2.3G  0 part [SWAP]

My partitions are shown above

I'm not very familiar with this since I don't run a separate /usr/ partition, but you could try extracting your initrd, adding the files needed to run that command, and then repack the initrd. Assuming it doesn't need to call any additional files, it might be enough to get that command to run before /usr/ is mounted.

(If you called your initrd.gz something else, make sure you take that into account)

Code:

su -

cd

mkdir initrd-tmp

cd initrd-tmp

gzip -dc /boot/initrd.gz | cpio -id

mkdir -p usr/libexec

cp /usr/libexec/udev-acl usr/libexec/

cp /usr/lib64/{libffi.so.6,libgobject-2.0.so.0} usr/lib64/

cp /lib64/{libacl.so.1,libattr.so.1} lib64/

find . | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/initrd-test.gz

Then add a new entry to your lilo.conf with the same kernel and referencing your new initrd (so you can keep your working entry intact), save it, run lilo, and then reboot and pray. I have no idea if this will work, but it's a shot in the dark. The libs being copied over are based on the ldd of udev-acl and are not present in my initrd I created in a relatively old -current install (Oct 2015). Even then, udev-acl might require additional things that aren't referenced in the ldd, so it may still not work.

Richard Cranium might have a better suggestion on how to handle this, because I believe he uses a separate /usr/ partition and might've ran into something similar.

I've been experimenting with editing /etc/rc.d/rc.S and placing...

Code:

# reload udev rules.

if [ -x /etc/rc.d/rc.udev ]; then

    /bin/sh /etc/rc.d/rc.udev reload

fi

...just before the line with the comment

Code:

# Start cgmanager (or cgproxy in a container):

I haven't seen any issues doing so (I'm using the laptop with that code on it to type this) and I don't see any harm in doing this.

You'll still get errors during the initrd boot, but you never have all of /usr during that portion of the boot anyways.

Is this correct:

Quote:

Originally Posted by bassmadrigal (Post 5559825)

Code:

cp /usr/lib64/{libffi.so.6,/libgobject-2.0.so.0} usr/lib64/

Quote:

Originally Posted by gezley (Post 5559849)

Is this correct:

?

Oops, nope, it got caught up in my copy/paste. Fixed!

Thanks!

I like the simplicity and logic behind Richard Cranium's solution. I have implemented that and it seems to eliminate the error messages. The original messages are still there but now when I see "Reload udev rules" message during startup there are no more errors. Now it seems time to start fighting with pulseaudio. If pulse audio is running kmix shows nothing and sound is mute. If I kill all pulseaudio processes and chmod -x pulseaudio to keep it from coming back I can get kmix to show the proper audio controls, but still no sound.

Code:



bash-4.3$ aplay -l

**** List of PLAYBACK Hardware Devices ****

card 1: HDMI [HDA Intel], device 0: VT1708S Analog [VT1708S Analog]

  Subdevices: 1/1

  Subdevice #0: subdevice #0

card 1: HDMI [HDA Intel], device 2: VT1708S Alt Analog [VT1708S Alt Analog]

  Subdevices: 1/1

  Subdevice #0: subdevice #0





bash-4.3# lspci -k | grep -iA3 audio

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)

        Subsystem: Santa Cruz Operation 82801I (ICH9 Family) HD Audio Controller

        Kernel driver in use: snd_hda_intel

        Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)

not sure where to go now

Are you talking about removing the execute permission of rc.pulseaudio? Because that isn't supposed to be executable (read the file for more info).

bassmadrigal No. Even after changing to autostart=no pulse audio would restart itself after I killed it so to ensure it stayed dead I removed execute permission from /usr/bin/pulseaudio. Since this has accomplished nothing, /usr/bin/pulseaudio is once again executable.

Try running pavucontrol instead of kmix.

Success!!!! Pavucontrol showed me a more usable error which suggested I run start-pulseaudio-x11 manually, which in turn rendered a cryptic but eventually even more usable error message. Chasing this down it turns out that (as usual) I was my own worst enemy. I had built a library that pulseaudio required sometime in the past from SBo. I forget which one now because excitement begets poor documentation. I had SBo packages blacklisted in slackpkg/blacklist. The lesson here is that every once in a while one should un-blacklist SBo packages and see if Pat has incorporated the same into Slackware. Thank you all for the help.

You might want to take out the change to rc.S to see if it still works. :)

I'm actually thinking about playing with udev and getting it to stop trying to load too early. I think you are right though, it will probably work just fine without the reload step.