Hi, been running a fresh install of f34 on my laptop for about a week or so with no sound issues and this morning after booting (previous state was shut down) I discovered there's no sound in gnome. Worked perfectly fine last week. Where do I start with the debugging? rpm -qa kernel-* | sort kernel-core-5.13.16-200.fc34.x86_64 kernel-core-5.13.19-200.fc34.x86_64 kernel-core-5.14.9-200.fc34.x86_64 rpm -qa *pipewire* pipewire-libs-0.3.38-1.fc34.x86_64 pipewire-alsa-0.3.38-1.fc34.x86_64 pipewire-gstreamer-0.3.38-1.fc34.x86_64 pipewire-jack-audio-connection-kit-0.3.38-1.fc34.x86_64 pipewire-utils-0.3.38-1.fc34.x86_64 pipewire0.2-libs-0.2.7-5.fc34.x86_64 pipewire-0.3.38-1.fc34.x86_64 pipewire-pulseaudio-0.3.38-1.fc34.x86_64 I've also tried the workaround from https://fedoraproject.org/wiki/Common_F34_bugs#Audio_may_not_work_after_upgr... without success. journalctl --user -b --unit pipewire-media-session.service -- Journal begins at Sat 2021-09-25 12:39:32 AEST, ends at Mon 2021-10-04 10:39:04 AEDT. -- -- No entries -- journalctl --user -b --unit pipewire.service -- Journal begins at Sat 2021-09-25 12:39:32 AEST, ends at Mon 2021-10-04 10:39:04 AEDT. -- -- No entries --
I'm very confused at this point :)
On Sun, 03 Oct 2021 23:44:44 -0000 Adi Pircalabu wrote:
I'm very confused at this point :)
Check the dumb stuff first! I have forgotten I left mute on before :-). I've also had linux forget which sound device I told it to use. There's always booting off a live image and seeing if sound works there, if not, might be hardware decided to break.
On Sun, 03 Oct 2021 23:44:44 -0000 Adi Pircalabu wrote:
Check the dumb stuff first! I have forgotten I left mute on before :-). I've also had linux forget which sound device I told it to use. There's always booting off a live image and seeing if sound works there, if not, might be hardware decided to break.
Thanks Tom. Made some progress. After checking this thread here: https://www.reddit.com/r/Fedora/comments/ne4gty/workaround_for_pipewire_not_... went and ran pipewire manually in a terminal: $ pipewire No luck. Then executed: $ pipewire-pulse And voila, now I have sound! Issues with the systemd unit(s)?
$ systemctl --user status pipewire Failed to get properties: Process org.freedesktop.systemd1 exited with status 1 $ systemctl --user status pipewire-pulse.socket Failed to get properties: Process org.freedesktop.systemd1 exited with status 1 $ systemctl --user status pipewire-pulse.service Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
How do I get these fellows to cooperate? :)
On 04/10/2021 08:08, Adi Pircalabu wrote:
$ systemctl --user status pipewire Failed to get properties: Process org.freedesktop.systemd1 exited with status 1 $ systemctl --user status pipewire-pulse.socket Failed to get properties: Process org.freedesktop.systemd1 exited with status 1 $ systemctl --user status pipewire-pulse.service Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
How do I get these fellows to cooperate? :)
Is there still an issue if you logout/login?
-- Nothing to see here
If I stop pipewire I lose sound, so if I run it in the foreground it ll be closed if I close the terminal window before logout. It appears to be related to selinux. If I boot the laptop with selinux=0 kernel argument sound works fine. If I remove selinux=0 arg and reboot I lose sound again. It appears selinux prevents the pipewire and pipewire-pulse services to start, is this a possibility?
ausearch -m AVC,USER_AVC [...] ---- time->Sat Oct 2 13:35:30 2021 type=PROCTITLE msg=audit(1633145730.776:6604): proctitle="(systemd)" type=SOCKADDR msg=audit(1633145730.776:6604): saddr=100000000000000000000000 type=SYSCALL msg=audit(1633145730.776:6604): arch=c000003e syscall=46 success=yes exit=16 a0=b a1=7ffc4f481b70 a2=0 a3=558ad876d380 items=0 ppid=1 pid=224888 auid=42 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=10 comm="(systemd)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1633145730.776:6604): avc: denied { audit_control } for pid=224888 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 ---- time->Mon Oct 4 08:45:43 2021 type=AVC msg=audit(1633297543.851:260): avc: denied { audit_control } for pid=1733 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 ---- time->Mon Oct 4 08:46:13 2021 type=AVC msg=audit(1633297573.837:340): avc: denied { audit_control } for pid=2267 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 ---- time->Mon Oct 4 09:10:41 2021 type=AVC msg=audit(1633299041.788:248): avc: denied { audit_control } for pid=1739 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 ---- time->Mon Oct 4 09:11:32 2021 type=AVC msg=audit(1633299092.256:339): avc: denied { audit_control } for pid=2302 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
On 04/10/2021 08:56, Adi Pircalabu wrote:
ausearch -m AVC,USER_AVC [...]
time->Sat Oct 2 13:35:30 2021 type=PROCTITLE msg=audit(1633145730.776:6604): proctitle="(systemd)" type=SOCKADDR msg=audit(1633145730.776:6604): saddr=100000000000000000000000 type=SYSCALL msg=audit(1633145730.776:6604): arch=c000003e syscall=46 success=yes exit=16 a0=b a1=7ffc4f481b70 a2=0 a3=558ad876d380 items=0 ppid=1 pid=224888 auid=42 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=10 comm="(systemd)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1633145730.776:6604): avc: denied { audit_control } for pid=224888 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
time->Mon Oct 4 08:45:43 2021 type=AVC msg=audit(1633297543.851:260): avc: denied { audit_control } for pid=1733 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
time->Mon Oct 4 08:46:13 2021 type=AVC msg=audit(1633297573.837:340): avc: denied { audit_control } for pid=2267 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
time->Mon Oct 4 09:10:41 2021 type=AVC msg=audit(1633299041.788:248): avc: denied { audit_control } for pid=1739 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
time->Mon Oct 4 09:11:32 2021 type=AVC msg=audit(1633299092.256:339): avc: denied { audit_control } for pid=2302 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0
If you run "sealert -b" what does it have for "troubleshooting"?
I'm running KDE/F34 and not seeing any issues.
-- Nothing to see here
On 04/10/2021 08:56, Adi Pircalabu wrote:
If you run "sealert -b" what does it have for "troubleshooting"?
I'm running KDE/F34 and not seeing any issues.
Didn't have setroubleshoot-server, so I went and installed it. "sealert -b" does nothing, or I don't know how to use it yet. Then I went and analyzed the audit log with "sealert -a /var/log/audit/audit.log" and here's the important bit:
type=AVC msg=audit(1633309984.892:327): avc: denied { audit_control } for pid=2387 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=1
$ ps auxww | egrep 2387 adi 2387 0.0 0.0 24080 16084 ? Ss 12:13 0:00 /usr/lib/systemd/systemd --user
So, looks like selinux prevents systemd to run as user adi. Now I need to figure out why all of a sudden.
Didn't have setroubleshoot-server, so I went and installed it. "sealert -b" does nothing, or I don't know how to use it yet. Then I went and analyzed the audit log with "sealert -a /var/log/audit/audit.log" and here's the important bit:
type=AVC msg=audit(1633309984.892:327): avc: denied { audit_control } for pid=2387 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=1
$ ps auxww | egrep 2387 adi 2387 0.0 0.0 24080 16084 ? Ss 12:13 0:00 /usr/lib/systemd/systemd --user
So, looks like selinux prevents systemd to run as user adi. Now I need to figure out why all of a sudden.
Manged to get my sound back in enforcing mode by running: setsebool -P init_audit_control 1 After reboot I now have: # audit2allow -w -a | tail
Possible mismatch between current in-memory boolean settings vs. permanent ones.
type=AVC msg=audit(1633309984.892:327): avc: denied { audit_control } for pid=2387 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=1 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.
$ ps auxww | egrep pipewire adi 2655 0.2 0.0 349932 17768 ? S<sl 12:36 0:00 /usr/bin/pipewire adi 2656 0.3 0.0 273220 25120 ? S<Lsl 12:36 0:01 /usr/bin/pipewire-pulse adi 2670 0.0 0.0 252976 12312 ? S<l 12:36 0:00 /usr/bin/pipewire-media-session adi 6401 0.0 0.0 221528 792 pts/1 S+ 12:42 0:00 grep -E --color=auto pipewire
Still don't know what caused the change in behaviour yet.
On 04/10/2021 09:43, Adi Pircalabu wrote:
Didn't have setroubleshoot-server, so I went and installed it. "sealert -b" does nothing, or I don't know how to use it yet. Then I went and analyzed the audit log with "sealert -a /var/log/audit/audit.log" and here's the important bit:
type=AVC msg=audit(1633309984.892:327): avc: denied { audit_control } for pid=2387 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=1
$ ps auxww | egrep 2387 adi 2387 0.0 0.0 24080 16084 ? Ss 12:13 0:00 /usr/lib/systemd/systemd --user
So, looks like selinux prevents systemd to run as user adi. Now I need to figure out why all of a sudden.
Manged to get my sound back in enforcing mode by running: setsebool -P init_audit_control 1 After reboot I now have: # audit2allow -w -a | tail
Possible mismatch between current in-memory boolean settings vs. permanent ones.type=AVC msg=audit(1633309984.892:327): avc: denied { audit_control } for pid=2387 comm="(systemd)" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=1 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated.
Possible mismatch between current in-memory boolean settings vs. permanent ones.$ ps auxww | egrep pipewire adi 2655 0.2 0.0 349932 17768 ? S<sl 12:36 0:00 /usr/bin/pipewire adi 2656 0.3 0.0 273220 25120 ? S<Lsl 12:36 0:01 /usr/bin/pipewire-pulse adi 2670 0.0 0.0 252976 12312 ? S<l 12:36 0:00 /usr/bin/pipewire-media-session adi 6401 0.0 0.0 221528 792 pts/1 S+ 12:42 0:00 grep -E --color=auto pipewire
Still don't know what caused the change in behaviour yet.
On my F34 Gnome VM, I have sound after a full update.
[root@f34g ~]# getsebool init_audit_control init_audit_control --> off
So, I don't know why you'd have to set it to "on".
I'm starting to think you may need to relabel your filesystem.
-- Nothing to see here
On 04/10/2021 09:43, Adi Pircalabu wrote:
$ ps auxww | egrep pipewire adi 2655 0.2 0.0 349932 17768 ? S<sl 12:36 0:00 /usr/bin/pipewire adi 2656 0.3 0.0 273220 25120 ? S<Lsl 12:36 0:01 /usr/bin/pipewire-pulse adi 2670 0.0 0.0 252976 12312 ? S<l 12:36 0:00 /usr/bin/pipewire-media-session adi 6401 0.0 0.0 221528 792 pts/1 S+ 12:42 0:00 grep -E --color=auto pipewire
Still don't know what caused the change in behaviour yet.
Could you also post the output of "ps -Z" for each of the pipewire processes as well as checking to see if these match?
[egreshko@meimei ~]$ ls -Z /usr/bin/pipewire* system_u:object_r:bin_t:s0 /usr/bin/pipewire system_u:object_r:bin_t:s0 /usr/bin/pipewire-media-session system_u:object_r:bin_t:s0 /usr/bin/pipewire-pulse
-- Nothing to see here
On 04/10/2021 09:43, Adi Pircalabu wrote:
Could you also post the output of "ps -Z" for each of the pipewire processes as well as checking to see if these match?
[egreshko@meimei ~]$ ls -Z /usr/bin/pipewire* system_u:object_r:bin_t:s0 /usr/bin/pipewire system_u:object_r:bin_t:s0 /usr/bin/pipewire-media-session system_u:object_r:bin_t:s0 /usr/bin/pipewire-pulse
Sure, here it is, thanks:
ls -Z /usr/bin/pipewire* system_u:object_r:bin_t:s0 /usr/bin/pipewire system_u:object_r:bin_t:s0 /usr/bin/pipewire-media-session system_u:object_r:bin_t:s0 /usr/bin/pipewire-pulse
ps -auxwwZ | egrep pipewire unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2655 0.0 0.0 347604 24820 ? S<sl Oct04 0:21 /usr/bin/pipewire unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2656 0.0 0.0 268404 29248 ? S<sl Oct04 0:27 /usr/bin/pipewire-pulse unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2670 0.0 0.0 253576 13200 ? S<l Oct04 0:00 /usr/bin/pipewire-media-session
On 05/10/2021 06:51, Adi Pircalabu wrote:
On 04/10/2021 09:43, Adi Pircalabu wrote:
Could you also post the output of "ps -Z" for each of the pipewire processes as well as checking to see if these match?
[egreshko@meimei ~]$ ls -Z /usr/bin/pipewire* system_u:object_r:bin_t:s0 /usr/bin/pipewire system_u:object_r:bin_t:s0 /usr/bin/pipewire-media-session system_u:object_r:bin_t:s0 /usr/bin/pipewire-pulse
Sure, here it is, thanks:
ls -Z /usr/bin/pipewire* system_u:object_r:bin_t:s0 /usr/bin/pipewire system_u:object_r:bin_t:s0 /usr/bin/pipewire-media-session system_u:object_r:bin_t:s0 /usr/bin/pipewire-pulse
ps -auxwwZ | egrep pipewire unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2655 0.0 0.0 347604 24820 ? S<sl Oct04 0:21 /usr/bin/pipewire unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2656 0.0 0.0 268404 29248 ? S<sl Oct04 0:27 /usr/bin/pipewire-pulse unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 adi 2670 0.0 0.0 253576 13200 ? S<l Oct04 0:00 /usr/bin/pipewire-media-session
That all looks correct.
There was a recent update to selinux-policy. Have you rebooted since then? If you reboot and set init_audit_control --> off does the issue return?
If the problem persists, I think I'd post to the fedora-selinux list for much better support.
-- Nothing to see here
-
Adi Pircalabu -
Ed Greshko -
Tom Horsley