On 2012/05/05 13:37 (GMT+0100) Colin Guthrie composed:
'Twas brillig, and Felix Miata did gyre and gimble:
Can you clarify "sound does not work"?
Nothing but background hum coming from connected AV amp connected speakers.
00:06.0 Multimedia audio controller: nVidia Corporation NForce2 AC97
Audio Controler (MCP) (rev a1)
If so please do attach the output from "pacmd ls"
No package named pacmd.
# urpmi pulseaudio-utils
...
# pacmd ls
No PulseAudio daemon running, or not running as session daemon.
Did you run it as root? If so, run it as a regular user instead.
Doesn't help as user.
You may
with to run "pactl stat" first
First before what? As root on tty2 before logging in as user in KDM?
if you are in a console as this will
trigger an autospawn of pulseaudio if it's not already running (pacmd
does not trigger autospawn as it's a debugging tool not a regular client).
# startx
Is this how you start X always?
Not always, but as root often, and on fresh installs and testing
alpha/beta/RCs, more often than not at least initially following completing
of an install. I rarely boot a test system directly into runlevel 5, and
never on first boot, so as to fix kdmrc, Xresources, fstab, hosts,
bootsplash, smb.conf, resolv.conf, menu.lst and other things that are broken
for my environment as initialized.
If so you should know from previous
discussions that this behaviour isn't really officially recommended as
it does not allow for proper user session tracking and thus has various
permissions related issues. It *should* work most of the time, but it is
highly recommended that you use a proper DM to login.
https://bugs.mageia.org/show_bug.cgi?id=5760 and other reasons during release
next evaluation and troubleshooting make an xdm an annoying time waster that
I typically avoid except when testing the xdm itself.
If this is a simple permissions issue, then you can test by running
"loginctl" before startx and noting if your sessions is listed. If it
is, it should have a number next to it (e.g. 1) and if it is listed you
can do: "loginctl session-status 1" (or whatever the number). This
should confirm that the session is active. When the session is active
# loginctl
SESSION UID USER SEAT
16 0 root seat0
17 2000 tst2000 seat0
18 0 root seat0
# loginctl session-status 17
17 - tst2000 (2000)
Since: Sat, 05 May 2012 13:37:34 -0400; 9min ago
Leader: 4855 (login)
Seat: seat0; vc4
TTY: tty4
Service: login; type tty; class user
Active: no
CGroup: /user/tst2000/17
Γö£ 4855 login -- tst2000
Γöö 4859 -bash
your user should be listed in the ACL for the sound device nodes
(getfacl /dev/snd/pcm*).
# getfacl /dev/snd/pcm*
# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---
# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---
# file: dev/snd/pcmC0D1c
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---
# file: dev/snd/pcmC0D2p
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---
After issuing startx, try the same commands and, in particular, make
sure your session is still active. I've tried to ensure that it is kept
active (i.e. there is no VT switch), but this isn't 100% reliable.
# loginctl
SESSION UID USER SEAT
16 0 root seat0
17 2000 tst2000 seat0
# loginctl session-status 17
17 - tst2000 (2000)
Since: Sat, 05 May 2012 13:37:34 -0400; 1min 21s ago
Leader: 4855 (login)
Seat: seat0; vc4
TTY: tty4
Service: login; type tty; class user
Active: no
CGroup: /user/tst2000/17
Γö£ 4855 login -- tst2000
Γö£ 4859 -bash
Γö£ 4907 /bin/sh /usr/bin/startx
Γö£ 4928 xinit /etc/X11/xinit/xinitrc -- vt4 -auth /home/ts...
Γö£ 4929 /etc/X11/X :0 vt4 -auth /home/tst2000/.serverauth....
Γö£ 4932 /usr/bin/ck-xinit-session /bin/sh -c #!/bin/sh exe...
Γö£ 4960 /usr/bin/dbus-launch --exit-with-session --sh-synt...
Γö£ 4961 /usr/bin/dbus-daemon --fork --print-pid 5 --print-...
Γö£ 4995 /bin/sh /usr/bin/startkde
Γö£ 5064 /usr/lib/kde4/libexec/start_kdeinit +kcminit_start...
Γö£ 5065 kdeinit4: kdeinit4 Running...
Γö£ 5066 kdeinit4: klauncher [kdeinit] --fd=9
Γö£ 5068 kdeinit4: kded4 [kdeinit]
Γö£ 5070 /usr/lib/gam_server
Γö£ 5075 kdeinit4: kglobalaccel [kdeinit]
Γö£ 5113 kwrapper4 ksmserver
Γö£ 5117 kdeinit4: ksmserver [kdeinit]
Γö£ 5138 kwin -session 10d1376e6300013362339230000002043000...
Γö£ 5173 /usr/bin/kactivitymanagerd
Γö£ 5177 /usr/bin/knotify4
Γö£ 5179 kdeinit4: plasma-desktop [kdeinit]
Γö£ 5183 /usr/bin/kuiserver
Γö£ 5192 kdeinit4: kaccess [kdeinit]
Γö£ 5199 kdeinit4: krunner [kdeinit]
Γö£ 5206 kdeinit4: kmix [kdeinit] -session 10d1376e63000133...
Γö£ 5208 kdeinit4: konsole [kdeinit] -session 10d1376e63000...
Γö£ 5209 /usr/bin/pam-panel-icon
Γö£ 5215 /usr/lib/kde4/libexec/polkit-kde-authentication-ag...
Γö£ 5216 kdeinit4: klipper [kdeinit]
Γö£ 5218 /bin/bash
Γö£ 5220 /bin/bash
Γöö 5227 /sbin/pam_timestamp_check -d root
startx should print out warnings when things don't work however.
(KDE menu has no selection to configure computer. Without it there's no
way I know how to manage systemd like I could with sysvinit.)
I've no idea about this sorry. You should report it as a separate bug tho'.
This didn't happen on all three installs, so I don't think I can tell what it
takes to reproduce. All three use the same workspace exclusively, so
comparing them is awkward.
# mcc
bash: mcc: command not found
# chkconfig --list
...
alsa 0:off 1:off 2:off 3:off 4:off 5:off
6:off 7:off
...
numlock 0:off 1:off 2:on 3:on 4:on 5:on
6:off 7:on
partmon 0:off 1:off 2:off 3:off 4:off 5:off
6:off 7:off
resolvconf 0:off 1:off 2:off 3:off 4:off 5:off
6:off 7:off
...
sound 0:off 1:off 2:on 3:on 4:on 5:on
6:off 7:off
In this case, the alsa+sound sysvinit scripts are fully overriden by
systemd so the chkconfig output is not actually relevant (see below for
my comments about the Troubleshooting section's outdated advice)
# systemctl list-unit-files
alsa-restore.service static
alsa-store.service static
alsa.service masked
...
sound.service masked
...
sound.target static
...
What to do?
Yup that looks as expected.
Try running the commands above to debug user permissions. I suspect this
is where the problem lies but I could be wrong.
"pacmd ls" output from inside X should work fine as PA will have been
started by then and it won't need to be autospawned.
(Konsole)
$ pacmd ls
No PulseAudio daemon running, or not running as session daemon.
(Konsole)
# pacmd ls
No PulseAudio daemon running, or not running as session daemon.
# systemctl list-unit-files | grep aud
# systemctl list-unit-files | grep pul
# systemctl list-unit-files | grep als
alsa-restore.service static
alsa-store.service static
alsa.service masked
Was easier to figure out what is configured or misconfigured with sysvinit.
With systemd I have no idea how to figure out what's missing.
I have to believe here there's a sound system dep not marked as such and so
not installed when no-suggests is set in urpmi.cfg before adding X and KDE to
a minimal install. :-(
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
