Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: arts
Date: Fri, 08 Jul 2005 09:24:35
In Reply to: [gentoo-amd64] arts by Benny Pedersen
Benny Pedersen posted
<36728.×××××××××.org>, excerpted below, 
on Fri, 08 Jul 2005 05:23:49 +0200:

> Sound server informational message: > Error while initializing the sound driver: device /dev/dsp can't be opened > (Permission denied) The sound server will continue, using the null output > device. > > i get a requester when starting x11 now and i don't know how to solve this > one :( > > using udev 0.58
There was just a problem with that, with the new udev-061, now masked pending a fix. However, if you're running 058, that shouldn't be the one you are having. Expanding on what Zac said, ensure your user is in the audio group, and that udev is set up to use that group for audio devices and that the mode is 660. Also, check your PAM settings, console.perms IIRC. Gentoo is moving away from using the PAM console-perms module by default, because it causes issues, but I've no idea if that's now on stable or if stable is still running console-perms by default. Basically, the idea of console-perms is to have the sound hardware and certain other devices belong to the first logged in console user. After they log off, perms switch to the second, etc. If nobody is logged in at the console, perms would switch to root only. Note that it is *NOT* necessary to be logged in at the console while you have an X session running, and this is in fact one of the big problems with pam-console-perms, and the reason Gentoo has decided to switch off of it. For those who don't understand how it works, it ends up looking like sometimes the perms work as expected, sometimes they don't, randomly, which of course causes serious support headaches. Anyway, if you aren't on a network and it's basically a single user at a time machine, you could probably get away with setting both PAM (if necessary) and UDEV permissions to 666, allowing all users to read/write the audio hardware, regardless of whether they are in the audio group. That's not necessarily a good thing on a decent sized office network, of course, because it's all too easy for someone else to login remotely, and set it playing embarrassing noises at the wrong time <g>, not to mention potential buffer overflows and the like, but for a single computer or home/SOHO network where all users are trusted and behind a suitable firewall, that'd generally be the least complicated thing to do. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in -- gentoo-amd64@g.o mailing list


Subject Author
Re: [gentoo-amd64] Re: arts Peter Humphrey <prh@××××××××××.uk>
Re: [gentoo-amd64] Re: arts Benny Pedersen <me@××××.org>