[Pkg-alsa-devel] Bug#848395: Bug#848395: udev rule fails with exit code 99

Tue Dec 20 10:09:07 UTC 2016

Control: severity -1 wishlist

Dear Elimar,

On 12/20/16 10:50, Elimar Riesebieter wrote:
> * Paul Menzel <pmenzel at molgen.mpg.de> [2016-12-20 10:24 +0100]:

>> On 12/19/16 18:19, Elimar Riesebieter wrote:
>>> * Paul Menzel <pmenzel at molgen.mpg.de> [2016-12-19 17:29 +0100]:
>>>
>>> [...]
>>>> $ sudo alsactl init
>>>> alsactl: sysfs_init:48: sysfs path '/sys' is invalid
>>>
>>> Please post the output of:
>>>
>>> dpkg -l | grep -E "(alsa|asound)"
>>
>> ii  alsa-utils                            1.1.2-1       amd64
>> Utilities for configuring and using ALSA
>> ii  libasound2:amd64                      1.1.2-1       amd64        shared
>> library for ALSA applications
>> ii  libasound2-data                       1.1.2-1       all
>> Configuration files and profiles for ALSA drivers
>> ii  libasound2-plugins:amd64              1.1.1-1       amd64        ALSA
>> library additional plugins
>
> Looks reasonable.
>
>>> [...]
>>>> After restarting the system, the udev error message is gone, as expected.
>>>>
>>>> But functionality wise, nothing changed. Until I log in in the graphical
>>>> session no sound devices are found.
>>>
>>> Hmm, did you logged in on a vt (i.e. <Alt> <F2> and checked sound?
>>
>> No, I just checked over SSH. Logging over the TTY, the sound does work.
>>
>>> I assume that you have an alsa or udev config somewhere in /etc which
>>> prevents alsa to start. Could you please rebuild your initrd.img and
>>> try rebooting?
>>
>> Running the process under strace it turns out to be a permission problem.
>>
>> $ strace aplay -l # over SSH
>> […]
>> open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission
>> denied)
>> […]
>
> As which user did you logged in? Is this user in group audio?

No, the user is not member of the group `audio`.

```
$ grep audio /etc/group
audio:x:29:pulse
```

>> $ ls -l /dev/snd/controlC0
>> crw-rw----+ 1 root audio 116, 2 Dec 20 10:14 /dev/snd/controlC0
>
>> $ sudo aplay -l
>
> This is fired up as root. You should do that as normal user with no
> probs.

I know. That was just to demonstrate that this is a permission issue.

>> **** List of PLAYBACK Hardware Devices ****
>> X11 connection rejected because of wrong authentication.
>> xcb_connection_has_error() returned true
>> card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>> card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>> card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>
> So your sound card is up ;-)
>
>> $ ls -l /dev/snd/controlC0 # over SSH, after logging in in “local” session
>> crw-rw----+ 1 root audio 116, 2 Dec 20 10:14 /dev/snd/controlC0
>
>
>
>> $ strace aplay -l # over SSH, after logging in in “local” session
>> open("/dev/snd/controlC0", O_RDWR|O_CLOEXEC) = 3
>> fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
>> ioctl(3, SNDRV_CTL_IOCTL_PVERSION, 0x7ffcce69b764) = 0
>> ioctl(3, SNDRV_CTL_IOCTL_CARD_INFO, 0x7ffcce69ba70) = 0
>> ioctl(3, SNDRV_CTL_IOCTL_PCM_NEXT_DEVICE, 0x7ffcce69bc44) = 0
>> ioctl(3, SNDRV_CTL_IOCTL_PCM_INFO, 0x7ffcce69b940) = 0
>> ```
>>
>> So the permissions of the file haven’t changed, but the user is allowed to
>> access the device. Very strange.
>
> Why do you test sound over ssh? Don't you have direct access to this
> machine?

Because I want to start playing something remotely.

> To test it not from X just login on a virtual console via <Alt> <F2>.

I did that, and mentioned that in my last message.

 > Logging over the TTY, the sound does work.

>>> Please post the output of:
>>> # journalctl | grep -E "(sound|alsa)"
>>
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Digital PCBeep as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH Rear Mic as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH Front Mic as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH Line Out as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH Front Headphone as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
>> Dec 20 10:08:14 plumpsklo kernel: input: HDA Intel PCH HDMI/DP,pcm=7 as
>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
>
> Your card is configured while booting.
>
>>> $ cat /proc/version
>>> would be of my interest as well.
>>
>> $ more /proc/version
>> Linux version 4.8.0-2-amd64 (debian-kernel at lists.debian.org) (gcc version
>> 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)
>
> So you have the actual sound drivers available.
>
> In summary your sound system works as expected. You should fix your
> users/ssh to have access to it.
>
> Do you agree to close this bug now?

Well, the last messages deal with a different issue than my original report.

I still find it confusing, that the behavior changes, when I am logged 
in locally or not.

But to my original report, I still think it’s bad for the udev rule to 
print an error during every startup. Especially – as in my experience – 
most sound cards are integrated (mostly onboard) into the system.

I don’t know if it should be considered an upstream problem or a 
packaging problem. But I consider it a cosmetic issue, so downgrade the 
severity to *wishlist*.

Kind regards,

Paul