Description of problem: Dummy output is only selection for audio master channel unless user is in the audio group in a default boot of runlevel 3. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. clean install beta1 DVD + updates 2. login as a normal user 3. startx 4. Right click speaker icon in task bar 5. pick Select Master Channel Dummy output is only selection. 6. use mcc to add audio group to user 7. log out/in 8. run steps 2 through 5 notice you can select your audio card.
Shouldn't be needed. Please attach the output of "getfacl /dev/snd/*".
CC: (none) => davidwhodgins
Created attachment 1620 [details] getfacl results
Colin what is needed for having sound in the init 3 ?
CC: (none) => mageia
Can you check what systemd-loginctl outputs? You should be registered as a session on multi-user.target (it is for me). Not sure what happens when you run startx, but I'm guessing it's maybe doing something strange with console-kit, so with that in mind can you provide: 1. Boot to multi-user.target (aka runlevel 3) 2. Login to getty. 3. Get output from systemd-loginctl and ck-list-sessions 4. Check getfacl /dev/snd/* (just confirm or not whether your user is listed in the ACLs) 5. startx 6. Get output from systemd-loginctl and ck-list-sessions again. 7. Check getfacl /dev/snd/* again.
Status: NEW => ASSIGNEDAssignee: bugsquad => mageia
Created attachment 1652 [details] systemd-loginctl, ck-list-sessions and getfacl count
Oh and one more thing: After startx: udevadm info --query=env -n /dev/snd/pcm* It should have a line: TAGS=:uaccess: (I strongly suspect it will not) I believe the problem is that the xinit package contains no systemd-logind-xinit-session binary (it currently contains source to build a console-kit version of this). No such binary exists and thus it needs to be written.
Source RPM: (none) => xinit-1.3.2-1.mga2.src.rpm
(actually it might contain that tag... it just won't apply it due to it not detecting the current session as the current and active one).
(In reply to comment #7) > (actually it might contain that tag... $ udevadm info --query=env -n /dev/snd/pcm* DEVNAME=/dev/snd/pcmC0D0c DEVPATH=/devices/pci0000:00/0000:00:14.5/sound/card0/pcmC0D0c MAJOR=116 MINOR=4 SUBSYSTEM=sound TAGS=:uaccess: UDEV_LOG=3 USEC_INITIALIZED=14497221 > it just won't apply it due to it not detecting the current session as the > current and active one). I'll agree with that.
OK, so this is basically something that other distros are phasing out and no longer supporting. Essentially doing proper session management (something that systemd does) is more or less orthogonal to the idea of startx. The problem is that you have an existing session and you are trying to create a new one from that. It could ultimately be supported, however I suspect it will take too much engineering work to do that (we would have to create a setuid wrapper that spoke to pam and then logged your user in with a new session after starting x). Here is the upstream explanation (Lennart describes the problem much better than me): http://lists.freedesktop.org/archives/systemd-devel/2012-February/004614.html So I suspect that this will sadly have to be a WONTFIX for mga2... of course if someone wants to work on the utility needed (either by hacking gdm or writing something independent) then I'd be more than willing to look into it :)
Status: ASSIGNED => RESOLVEDResolution: (none) => WONTFIXSummary: 2_b1: no master audio channel unless user in audio group at runlevel 3 => 2_b1: Running startx from text login does not register a new session.