OVH Cloud OVH Cloud

[gentoo-user-fr] udev et ALSA

15 réponses
Avatar
Stéphan BERNARD
Bonjour,

Depuis la dernière mise à jour d'udev, xmms (et d'autres applis telles
que gnome-alsamixer etc...) ne trouvent plus ma carte son. En passant
par OSS, ma carte son est reconnue mais muette (pourtant les réglages
des mixers ne le sont pas).

Il semblerait que j'ai un problème de droits, car alsamixer me renvoie
'alsamixer: function snd_ctl_open failed for default: Permission denied'

Un ls -lh /dev/snd/* me donne :
crw------- 1 root audio 116, 0 Jun 30 08:39 controlC0
crw------- 1 root audio 116, 24 Jun 30 08:39 pcmC0D0c
crw------- 1 root audio 116, 16 Jun 30 08:39 pcmC0D0p
... etc ...

alors que ls -lh /dev/sound/* me donne :
crw-rw---- 1 root audio 14, 12 Jun 30 08:39 adsp
crw-rw---- 1 root audio 14, 4 Jun 30 08:39 audio
crw-rw---- 1 root audio 14, 3 Jun 30 08:39 dsp
... etc ...

Visisblement, le groupe audio (mon utilisateur en fait bien partie) n'a
pas les droits sur /dev/snd/*. Pourtant, j'ai bien, dans
/etc/udev/permissions.d/50-udev.permissions les lignes :
sound/*:root:audio:0660
snd/*:root:audio:0660

Un
grep snd `find /etc/udev/ -name '*'`
ne me donne rien d'autre que les lignes ci-dessus et les udev-rules qui
n'ont rien à voir avec les droits.

Quelqu'un aurait-il une explication ? Je suis aussi preneur d'une
solution, bien sûr ;) !

Merci.
--
gentoo-user-fr@gentoo.org mailing list

10 réponses

1 2
Avatar
Yoann Pannier
Stéphan BERNARD wrote, On 06/30/2005 10:51 AM:

Pourtant, j'ai bien, dans
/etc/udev/permissions.d/50-udev.permissions les lignes :



Un
grep snd `find /etc/udev/ -name '*'`
ne me donne rien d'autre que les lignes ci-dessus et les udev-rules qui
n'ont rien à voir avec les droits.



Dans /usr/portage/sys-fs/udev/ChangeLog :

*udev-051 (03 Feb 2005)

03 Feb 2005; Greg Kroah-Hartman
+files/udev.conf.post_050, +udev-051.ebuild:
update to 051 release. This fixes (or should) the firmware oops. Also,
please note that the .permissions files are now gone! If you had
custom ones
in the past, you need to move that logic into the .rules files (if not,
you'll just get root only access to the devices, so it's not a security
issue...)


Possible que ce soit ça.

--
Yoann Pannier

--
mailing list
Avatar
Stéphan BERNARD
Yoann Pannier wrote:
03 Feb 2005; Greg Kroah-Hartman
+files/udev.conf.post_050, +udev-051.ebuild:
update to 051 release. This fixes (or should) the firmware oops. Also,
please note that the .permissions files are now gone! If you had
custom ones
in the past, you need to move that logic into the .rules files (if not,
you'll just get root only access to the devices, so it's not a security
issue...)


Possible que ce soit ça.


C'est bien ça. Il m'a fallu ajouter MODE="0660" aux lignes concernant le
son dans /etc/udev/rules.d/50-udev.rules et la carte son est maintenant
bien reconnue, ce qui m'a permis de lancer alsamixer ; ensuite j'ai vu
la case cochée qui explique le mutisme de la carte en mode OSS.

Merci beaucoup.
-- Stéphan BERNARD
--
mailing list
Avatar
Christophe PEREZ
Le Thu, 30 Jun 2005 13:57:39 +0200, Stéphan BERNARD a écrit :

C'est bien ça. Il m'a fallu ajouter MODE="0660" aux lignes concerna nt le
son dans /etc/udev/rules.d/50-udev.rules



Ah, ben j'ai appris quelque chose ;-)
J'ai voulu l'appliquer à mon scanner, pour lequel je dois à chaque
boot mettre les bonnes permissions au /proc/bus/usb/00x/00y correspondant
et dont le /etc/udev/permissions.d/20-scanner.permissions
# scanner devices
scanner:root:scanner:0660
usb/scanner*:root:scanner:0660

est des plus inefficace, mais je n'ai pas trouvé par quelle ligne il es t
crée dans le /etc/udev/rules.d/50-udev.rules.
Quelqu'un a une idée ?

--
Christophe PEREZ
--
mailing list
Avatar
Aki
> Quelqu'un a une idée ?



Hum, je dirais a tout hasard, est tu sur d'etre en full udev et non pa
en devfs dans le kernel ? je me suis deja fait avoir comme ca :)

--
mailing list
Avatar
Stéphan BERNARD
Aki wrote:
Hum, je dirais a tout hasard, est tu sur d'etre en full udev et non pa
en devfs dans le kernel ? je me suis deja fait avoir comme ca :)


C'est intéressant ce que tu écris car ce matin au démarrage, même
pathologie qu'hier. En fait, après avoir modifié les droits dans
udev.rules, j'avais lancé udevstart. Il a fallu que je le relance à la
papatte ce matin pour qu'ALSA fonctionne de nouveau. Du coup j'ai mis
udevstart dans le local.start.

Mais comment savoir si l'on est en udev ? Comment se fait-il que je sois
obligé d'ajouter udevstart dans /etc/conf.d/local.start alors qu'aucune
doc ne le mentionne ?

--
Stéphan BERNARD
--
mailing list
Avatar
Bertrand Jacquin
tu peut forcer l'utilisation d'udev grave au fichier /etc/conf.d/rc

On 7/1/05, Stéphan BERNARD wrote:
Aki wrote:
> Hum, je dirais a tout hasard, est tu sur d'etre en full udev et non pa
> en devfs dans le kernel ? je me suis deja fait avoir comme ca :)
C'est intéressant ce que tu écris car ce matin au démarrage, même
pathologie qu'hier. En fait, après avoir modifié les droits dans
udev.rules, j'avais lancé udevstart. Il a fallu que je le relance à la
papatte ce matin pour qu'ALSA fonctionne de nouveau. Du coup j'ai mis
udevstart dans le local.start.

Mais comment savoir si l'on est en udev ? Comment se fait-il que je sois
obligé d'ajouter udevstart dans /etc/conf.d/local.start alors qu'aucune
doc ne le mentionne ?

--
Stéphan BERNARD
--
mailing list





--
mailing list
Avatar
Stéphan BERNARD
Bertrand Jacquin wrote:
tu peut forcer l'utilisation d'udev grave au fichier /etc/conf.d/rc


Exact, je l'avais déjà oublié. Mais vérification faite, j'ai bien
RC_DEVICES="udev"

Donc je suis en udev, mais les /dev/snd/* ne sont accessibles au groupe
audio qu'après exécution de /sbin/udevstart. Grâce au local.start, mon
problème est résolu, mais je trouve ça étrange.

--
Stéphan BERNARD
--
mailing list
Avatar
Aki
Regarde si dans ta config de kernel devfs est activé ( de memoire
c'est ca j'ai pa de linux sous la main pour le moment ) [ ] /dev
filesystem support ou quelquechose de semblable

Le 01/07/05, Stéphan BERNARD a écrit :
Bertrand Jacquin wrote:
> tu peut forcer l'utilisation d'udev grave au fichier /etc/conf.d/rc
Exact, je l'avais déjà oublié. Mais vérification faite, j'ai bien
RC_DEVICES="udev"

Donc je suis en udev, mais les /dev/snd/* ne sont accessibles au groupe
audio qu'après exécution de /sbin/udevstart. Grâce au local.start, mon
problème est résolu, mais je trouve ça étrange.

--
Stéphan BERNARD
--
mailing list





--
mailing list
Avatar
Neo Yoyo
------=_Part_4642_5039425.1120212184938
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le 01/07/05, Aki a écrit :

Regarde si dans ta config de kernel devfs est activé ( de memoire
c'est ca j'ai pa de linux sous la main pour le moment ) [ ] /dev
filesystem support ou quelquechose de semblable





Si tu génére ton kernel avec genkernel pense aussi à mettre l'option --udev
qui regle par defaut les param du noyau pour le udev.

Le 01/07/05, Stéphan BERNARD a éc rit :
> Bertrand Jacquin wrote:
> > tu peut forcer l'utilisation d'udev grave au fichier /etc/conf.d/rc
> Exact, je l'avais déjà oublié. Mais vérification faite, j'ai bi en
> RC_DEVICES="udev"
>
> Donc je suis en udev, mais les /dev/snd/* ne sont accessibles au groupe
> audio qu'après exécution de /sbin/udevstart. Grâce au local.start , mon
> problème est résolu, mais je trouve ça étrange.
>
> --
> Stéphan BERNARD
> --
> mailing list
>
>

--
mailing list





------=_Part_4642_5039425.1120212184938
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le 01/07/05, <b class="gmail_sendername">Aki</b> &lt;<a href="mailto:ac "></a>&gt; a écrit :<div><span class= "gmail_quote"></span><blockquote class="gmail_quote" style="border-left : 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e x;">
Regarde si dans ta config de kernel devfs est activé ( de memoire<br>c'es t ca j'ai pa de linux sous la main pour le moment ) [ ] /dev<br>filesystem support ou quelquechose de semblable</blockquote><div><br>
<br>
Si tu génére ton kernel avec genkernel pense aussi à mettre l'option
--udev qui regle par defaut les param du noyau pour le udev.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Le 01/0 7/05, Stéphan BERNARD&lt;<a href="mailto: ref.fr">
</a>&gt; a écrit :<br>&gt; Bertrand J acquin wrote:<br>&gt; &gt; tu peut forcer l'utilisation d'udev grave au fic hier /etc/conf.d/rc<br>&gt; Exact, je l'avais déjà oublié. Mais vér ification faite, j'ai bien
<br>&gt; RC_DEVICES=&quot;udev&quot;<br>&gt;<br>&gt; Donc je suis en udev , mais les /dev/snd/* ne sont accessibles au groupe<br>&gt; audio qu'aprè s exécution de /sbin/udevstart. Grâce au local.start, mon<br>&gt; probl ème est résolu, mais je trouve ça étrange.
<br>&gt;<br>&gt; --<br>&gt; Stéphan BERNARD<br>&gt; --<br>&gt; <a href= "mailto:"></a> mailing li st<br>&gt;<br>&gt;<br><br>--<br><a href="mailto: ">
</a> mailing list<br><br></blockquote></div><br>

------=_Part_4642_5039425.1120212184938--
--
mailing list
Avatar
Stéphan BERNARD
> Le 01/07/05, *Aki* <mailto: a
écrit :

Regarde si dans ta config de kernel devfs est activé ( de memoire
c'est ca j'ai pa de linux sous la main pour le moment ) [ ] /dev
filesystem support ou quelquechose de semblable


Il n'est pas activé.

Neo Yoyo wrote:
Si tu génére ton kernel avec genkernel pense aussi à mettre l'option
--udev qui regle par defaut les param du noyau pour le udev.


Ce n'est pas le cas, j'utilise les vanilla-sources, actuellement en
version 2.6.11.11.

Merci de votre aide.
--
mailing list
1 2