Home / ubuntu / Questions / 1289288
In Process
senthor
Asked: 2020-11-04 03:23:00 +0800 CST

beep not working since upgrade to 20.04.1 LTS

  • 772

I've just finished upgrading to Ubuntu Server 20.04.1 LTS, and so far, only one issue has come up: The beepcommand returns beep: Error: Could not open any device when run as user. Running sudo beep does not work, as expected. After a little bit of research, I have found that no beep group is existent on the system, as expected by the man page. I have tried reinstalling and reconfiguring without success.

To make things even stranger, beep works during boot via rc.local; at some point, however, it stops working and returns the error, thus breaking my rc.local-routine. Also, this command works just fine:

sudo env -u SUDO_GID -u SUDO_COMMAND -u SUDO_USER -u SUDO_UID beep

For clarification: I am running a headless home server that is not connected to any speakers; the simple noise-making-speaker is used for simple feedback during boot and if errors occur that require intervention. My setup used to work fine under Ubuntu Server 18.04 LTS.

sound udev evdev

3 Answers

  1. Adding my user to group input worked for me, ie:

    sudo usermod -aG input USERNAME

    The change isn't visible until you log in again (On Ubuntu, I had to restart, not just log out and back in, before a new shell would display the new group in the output of groups.) To see the change within one shell, open a new login shell:

    su USERNAME -
    • 3

  2. Bad solution:

    I'm pretty sure this is a permissions issue, but I am not sure how to solve it. I tried creating udev files and groups according to the ArchLinux Wiki, but that wouldn't work.

    Then, I changed permissions on the device itself:

    sudo chmod 777 /dev/input/by-path/platform-pcspkr-event-spkr

    While this does work, it's surely a bad idea to make devices just writeable for anyone.

    • 1

  3. One solution suggested in the doc PERMISSIONS.md is to create a system group called 'beep' and then use ACLs to allow members of that group write access to the device.

    $ addgroup --system beep

    Then create a rule for udev, e.g.

    /lib/udev/rules.d/90-pcspkr-beep.rules :

    # Add write access to the PC speaker for the "beep" group
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", RUN+="/usr/bin/setfacl -m g:beep:w '$env{DEVNAME}'"

    Then you should be able to add users to this group and they can write to the speaker:

    $ usermod user_name -a -G beep

    Of course the above will only work if you have ACLs turned on. If you can't or won't do that, they have a different suggestion for the udev rule:

    # Give write access to the PC speaker only to the "beep" group
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", GROUP="beep", MODE="0620"

    But this will remove the speaker from being written to by the default system group 'input'--adverse effects are probably negligible since this method is suggested in the documentation.

    • 1