Bug 2016253

I encountered this issue after upgrading a F34 KDE system to F35. This is also been hit by a other users as reported on the devel mailing list [1].

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NQTDWZXV7TFLDT5TG442S3UM5LU6XXSW/

Proposed as a Freeze Exception for 35-final by Fedora user ngompa using the blocker tracking app because:

 We definitely don't want sound randomly not working for people when they upgrade from F34 to F35.

What appears to be happening here is that we have an ordering problem between fedora-release and wireplumber, where the preset call may fire *before* fedora-release was upgraded, which means the preset wasn't set (since wireplumber wasn't set in F34, only F35+).

Adding another scriptlet to fire when fedora-release is upgraded to 35+ *should* fix this.

FEDORA-2021-3c4c454c98 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3c4c454c98

FEDORA-2021-3c4c454c98 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3c4c454c98

This feels...suspicious, to me, somehow. Like this should not be required. As described this is a generic problem which would happen any time we decide to enable something which wasn't previously enabled. Why don't we have this problem more often? Are we missing something? Is there a trigger somewhere for newly-default-enabled system services which has not been implemented for newly-default-enabled user services?

(BTW, would a lighter alternative be to Requires(post): fedora-release >= 35 or whatever?)

Met the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=2015862 (probably can be closed as duplicate)

*** Bug 2015862 has been marked as a duplicate of this bug. ***

Sounds like a blocker, not a freeze exception. Proposing.

I believe that we have been seeing this around Beta when wireplumber replaced pipewire-media-session, but then people stopped seeing this. It is suspicious. I am going to run some attempts to reproduce this.

(In reply to Adam Williamson from comment #6)
> This feels...suspicious, to me, somehow. Like this should not be required.
> As described this is a generic problem which would happen any time we decide
> to enable something which wasn't previously enabled. Why don't we have this
> problem more often? Are we missing something? Is there a trigger somewhere
> for newly-default-enabled system services which has not been implemented for
> newly-default-enabled user services?
> 
> (BTW, would a lighter alternative be to Requires(post): fedora-release >= 35
> or whatever?)

Maybe? I'm trying to avoid a hard(ish) dependency on fedora-release because that makes swapping branding impossible.

I have tried to reproduce this problem doing:

1. Install Fedora Workstation 34
2. Use `dnf update --refresh` to fully update it.
3. Use `dnf system-upgrade download --releasever=35` to get the packages.
4. Use `dnf system-upgrade reboot` to do the offline system upgrade.

After the system has been upgraded to F35, wireplumber is running and the sound is working correctly. I am not seeing the described behaviour on a cleanly installed system!

For another attempt, I have installed fresh Fedora 34 and upgraded it to F35 without even upgrading the system first. Still, I have not been able to reproduce it and after the system upgrade, the wireplumber is running and the sound is working normally.

"Maybe? I'm trying to avoid a hard(ish) dependency on fedora-release because that makes swapping branding impossible."

Ah, yeah. We do have the system-release provide for that case, but it's annoyingly not versioned - there's a "system-release(35)" provide, but you can't really do Requires: system-release(>=35). So, bummer. I don't know why we don't version that provide, that seems dumb.

Lukas: if the bug is as Neal thinks, it'll be subject to package ordering in the upgrade transaction, which is going to be highly sensitive to the currently-installed package set. I doubt this happens with a stock Workstation package set as we already tested that earlier in the cycle.

It would probably help if those who encountered this bug could attach the log of the upgrade transaction from dnf history - that'd tell us what packages they had installed on upgrade, and exactly what the ordering was.

Created attachment 1836927 [details]
Log of F34->F35 upgrade

I've uploaded the log of my KDE F34->F35 upgrade that resulted in wireplumber not being enabled. I ran "dnf history info <ID>" to generate the output.

dang, looks like dnf history just gives the list of packages in alphabetical order, not transaction order. I *think* /var/log/dnf.rpm.log may give us the actual transaction order.

I did have a look through the scriptlets and presets in systemd and fedora-release and it does look like there isn't anything designed to capture this case, so it does seem plausible for the bug to happen as Neal describes. It does seem like a systemic oversight we should fix vs. something to handle package-by-package, though maybe we should do that in Rawhide and take the one-time fix for F35.

Discussed during the 2021-10-25 blocker review meeting: [0]

The decision to classify this bug as both an "Accepted0Day (Final)" and an "AcceptedFreezeException (Final)" was made as a violation of the following blocker criterion:

"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade...The upgraded system must meet all release criteria"

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-10-25/f35-blocker-review.2021-10-25-16.02.txt

> As described this is a generic problem which would happen any time we decide to enable something which wasn't previously enabled. Why don't we have this problem more often?

I think we just have a timing issue here, caused by the release freeze. Usually you'd update both packages and if you did trigger the bug, you'd run a dnf update again after maybe a day. If there was an updated package (highly likely for new packages since they churn a bit), updating will now fix the bug. But since packages are frozen for the release we are more exposed now, once GA hits and new wireplumber packages become available, any update should fix this ordering issue. At least that's my interpretation of it.

The situation we're specifically concerned with is the upgrade from F34. We enable the service by default in F35, but not in F34. It is supposed to get enabled on upgrade, but does not if the package that contains the service (wireplumber, in this case) is updated *before* the package that contains the new preset default (fedora-release-common).

I don't think the freeze has anything much to do with that.

yes, I understand that, I'm just saying that if F35 were released already, we'd see a lot of these cases as "wireplumber doesn't work! oh, I ran dnf update and now it works". So I'm not disagreeing there's a bug, just providing a theory why we're not seeing this more often.

I don't think so? Initial upgrades typically include the updates repository. So the bug would only immediately go away again if *another* wireplumber (or whatever other affected package) update showed up soon after the user upgraded, or one was in updates-testing and they turned that on.

All six of the systems that I encountered this bug on were upgraded from many previous versions of Fedora before 34, so this is a slim possibility that the bug is only triggered from multiple generations of Fedora upgrade.

(In reply to Adam Williamson from comment #22)
> So the bug would only immediately go away again if *another* wireplumber (or
> whatever other affected package) update showed up soon after the user
> upgraded, or one was in updates-testing and they turned that on.

In that case, pure `dnf reinstall wireplumber` should help. But on the system, where I still did not fixed this issue, this does not help. 

I agree with Nick hypothesis Both systems where I experienced this bug were updated from Fedora $SOME_LOW_NUMBER and upgraded every 6 months to the new version.

Whether 'dnf reinstall wireplumber' works would, I think, depend on whether rpm considers that an 'initial install' or not. If it does, yeah, you'd think it should fix the problem.

So, you have a system that's still in the broken state? That might be helpful. Uh, presumably fedora-release-common is installed, and lists wireplumber.service in /usr/lib/systemd/user-preset/90-default-user.preset ? Everything else is as Nick described...wireplumber is installed but not enabled?

Created attachment 1837827 [details]
/var/log/dnf.rpm.log with before and after upgrade removed

I removed updates on Fedora 34 that preceded the upgrade from /var/log/dnf.rpm.log.1, and appended the remainder of the upgrade from /var/log/dnf.rpm.log.  I have five others if required.

FEDORA-2021-3c4c454c98 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

I'm re-opening this to allow us to investigate the potential "it's still broken on long-upgraded systems" case further, but removing blocker/FE metadata as that case would not be release blocking, and we signed off the release so it can't be an FE any more.

(In reply to Peter Hutterer from comment #19)
> > As described this is a generic problem which would happen any time we decide to enable something which wasn't previously enabled. Why don't we have this problem more often?
> 
> I think we just have a timing issue here, caused by the release freeze.
> Usually you'd update both packages and if you did trigger the bug, you'd run
> a dnf update again after maybe a day. If there was an updated package
> (highly likely for new packages since they churn a bit), updating will now
> fix the bug. But since packages are frozen for the release we are more
> exposed now, once GA hits and new wireplumber packages become available, any
> update should fix this ordering issue. At least that's my interpretation of
> it.

As far as I can see, the program /usr/lib/systemd/systemd-update-helper was not available in systemd as provided in release 34 and earlier.

I added https://fedoraproject.org/wiki/Common_F35_bugs#No_sound_after_upgrade -- someone should double-check what I wrote. :)

*** Bug 2018681 has been marked as a duplicate of this bug. ***

FWIW I have two computers that started as fresh Fedora 33 installs. Other than one using GNOME and the other using KDE, they are mostly otherwise identically and minimally set up. Upgrading the KDE machine from 34 to 35 resulted in this issue (upgrading the GNOME machine did not).

I did the `dnf system-upgrade` yesterday (Oct 31). I also did a `dnf update` an hour ago and the issue persisted. The instructions on the Common_F35_bugs wiki page have now got things working.

I also had the problem see here: https://ask.fedoraproject.org/t/early-upgrade-of-fedora-34-to-35-mate-compiz-spin-audio-devices-no-longer-detected/16919/7

Might be that the spins still have the default config files in /etc/pipewire in general ?! 
A bug we had in fedora 34 https://fedoraproject.org/wiki/Common_F34_bugs#Audio_may_not_work_after_upgrade_to_Fedora_34_if_pipewire_was_previously_installed

I hope this information helps to narrow down the problem!

(In reply to Villy Kruse from comment #29)
> (In reply to Peter Hutterer from comment #19)
> > > As described this is a generic problem which would happen any time we decide to enable something which wasn't previously enabled. Why don't we have this problem more often?
> > 
> > I think we just have a timing issue here, caused by the release freeze.
> > Usually you'd update both packages and if you did trigger the bug, you'd run
> > a dnf update again after maybe a day. If there was an updated package
> > (highly likely for new packages since they churn a bit), updating will now
> > fix the bug. But since packages are frozen for the release we are more
> > exposed now, once GA hits and new wireplumber packages become available, any
> > update should fix this ordering issue. At least that's my interpretation of
> > it.
> 
> As far as I can see, the program /usr/lib/systemd/systemd-update-helper was
> not available in systemd as provided in release 34 and earlier.

[vek@mybox ~]$ rpm -q --scripts wireplumber
postinstall scriptlet (using /bin/sh):

 
if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then 
    # Initial installation 
    /usr/lib/systemd/systemd-update-helper install-user-units wireplumber.service || : 
fi
preuninstall scriptlet (using /bin/sh):

 
if [ $1 -eq 0 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then 
    # Package removal, not upgrade 
    /usr/lib/systemd/systemd-update-helper remove-user-units wireplumber.service || : 
fi


This means that this package depends on systemd version 249.4 or later.  But only during initial installation.

Villy: that could well be the issue, in fact, because wireplumber is going to be installed for the first time during upgrade to F35 for most people. Also, the scriptlet Neal added to (try and) fix this bug does the same thing:

%triggerun -- fedora-release < 35
# When upgrading to Fedora Linux 35, transition to WirePlumber by default
if [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
    # Initial installation
    /usr/lib/systemd/systemd-update-helper install-user-units %{name}.service || :
fi

Indeed F33's and F34's systemd do not have /usr/lib/systemd/systemd-update-helper . So none of these scripts will work if systemd has not yet been upgraded to an F35 version when they run.

So...solutions? We could make these %posttrans and %triggerpostun - is there actually a reason they need to happen during the transaction? Or we could backport the systemd-update-helper script to F33 and F34...

Neal, Zbigniew, thoughts?

Nick's log does seem to support this theory, BTW - it looks like first fedora-release-common was updated, then wireplumber was installed (so the problem was not what we first thought), but systemd was upgraded *last*:

2021-10-19T21:24:48+1100 SUBDEBUG Upgrade: fedora-release-common-35-33.noarch
2021-10-19T21:27:40+1100 SUBDEBUG Installed: wireplumber-0.4.3-3.fc35.x86_64
2021-10-19T21:27:44+1100 SUBDEBUG Upgrade: systemd-249.4-2.fc35.x86_64

(In reply to Adam Williamson from comment #35)
> Villy: that could well be the issue, in fact, because wireplumber is going
> to be installed for the first time during upgrade to F35 for most people.
> Also, the scriptlet Neal added to (try and) fix this bug does the same thing:
> 
> %triggerun -- fedora-release < 35
> # When upgrading to Fedora Linux 35, transition to WirePlumber by default
> if [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
>     # Initial installation
>     /usr/lib/systemd/systemd-update-helper install-user-units
> %{name}.service || :
> fi
> 
> Indeed F33's and F34's systemd do not have
> /usr/lib/systemd/systemd-update-helper . So none of these scripts will work
> if systemd has not yet been upgraded to an F35 version when they run.
> 
> So...solutions? We could make these %posttrans and %triggerpostun - is there
> actually a reason they need to happen during the transaction? Or we could
> backport the systemd-update-helper script to F33 and F34...
> 
> Neal, Zbigniew, thoughts?

Change it to "/bin/systemctl enable --user %{name}.service" and that would fix it.

Another way to fix it is to add "OrderWithRequires: systemd >= 249.5" to the WirePlumber spec.

This is starting to hit on the reason why I suggested we require people to use at least %systemd_ordering macro in spec files...

(In reply to Adam Williamson from comment #35)
> Villy: that could well be the issue, in fact, because wireplumber is going
> to be installed for the first time during upgrade to F35 for most people.
> Also, the scriptlet Neal added to (try and) fix this bug does the same thing:
> 

Probably only half of the issue; the preset list being the other half.

> %triggerun -- fedora-release < 35
> # When upgrading to Fedora Linux 35, transition to WirePlumber by default
> if [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
>     # Initial installation
>     /usr/lib/systemd/systemd-update-helper install-user-units
> %{name}.service || :
> fi
> 
> Indeed F33's and F34's systemd do not have
> /usr/lib/systemd/systemd-update-helper . So none of these scripts will work
> if systemd has not yet been upgraded to an F35 version when they run.
> 
> So...solutions? We could make these %posttrans and %triggerpostun - is there
> actually a reason they need to happen during the transaction? Or we could
> backport the systemd-update-helper script to F33 and F34...
> 
> Neal, Zbigniew, thoughts?

Seems to me to be the right thing to do.

The rpm description could mention that the service daemon is needed for pipewire to work, unless that service is provided by pipewire-media-session.

(In reply to Neal Gompa from comment #39)
> This is starting to hit on the reason why I suggested we require people to
> use at least %systemd_ordering macro in spec files...

It might make sense to have a dependency generator that always adds "OrderWithRequires: systemd" and "OrderWithRequires: system-release" whenever any systemd units are in a package, so that upgrades always push those packages to the earliest part of the transaction?

same here - upgraded from F34->F35 and found audio was not working.

FEDORA-2021-4d8b11e08a has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4d8b11e08a

I've encountered this on a *clean* install of Fedora 35.

No sound from my primary output device (Creative SoundBlaster AE-7) at all, even after running the systemctl command.

If I switch to a Displayport output, sound works through there.

No issues with Fedora 34.

If running the command didn't fix it, but you *do* get sound from a different device, it's a different bug. It's not this bug. Are you running KDE? If so, it could possibly be https://fedoraproject.org/wiki/Common_F35_bugs#hdmi-audio-profile .

Running Fedora 35 GNOME this end. Doesn't seem to be that issue.

FEDORA-2021-4d8b11e08a has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-4d8b11e08a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4d8b11e08a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I had this problem this morning after upgrading to fedora 35 from a recent clean install of Fedora 34.   It may be significant that I installed the KDE spin of F34, thus not so much Gnome.  In order to get sound working, I had to run "dnf install --allowerasing pulseaudio-module-gsettings" to provoke dnf to actually switch from pipewire-media-session to wireplumber.  That fixed my issue.

(In reply to rickw from comment #48)
> I had this problem this morning after upgrading to fedora 35 from a recent
> clean install of Fedora 34.   It may be significant that I installed the KDE
> spin of F34, thus not so much Gnome.  In order to get sound working, I had
> to run "dnf install --allowerasing pulseaudio-module-gsettings" to provoke
> dnf to actually switch from pipewire-media-session to wireplumber.  That
> fixed my issue.

Doesn't that just switch back to using pulseaudio?

A functional pipewire sound system has these packages installed:


# rpm -qa pipewire\* pulseaudio\* wireplumber
pulseaudio-libs-15.0-2.fc35.x86_64
pulseaudio-libs-glib2-15.0-2.fc35.x86_64
pulseaudio-utils-15.0-2.fc35.x86_64
wireplumber-0.4.4-2.fc35.x86_64
pipewire-libs-0.3.39-1.fc35.x86_64
pipewire-0.3.39-1.fc35.x86_64
pipewire-gstreamer-0.3.39-1.fc35.x86_64
pipewire-pulseaudio-0.3.39-1.fc35.x86_64
pipewire-utils-0.3.39-1.fc35.x86_64

To switch from pipewire-media-session to wireplumber run

  dnf swap pipewire-media-session wireplumber

This may leave the broken symbolic link  /etc/systemd/user/pipewire-session-manager.service which you need to remove before enabling wireplumber.

Hi, hmm, my desktop computer since today with Fedora 35 belongs to those whose audio system does not anymore work. Well, running "  dnf swap pipewire-media-session wireplumber" and removing "  dnf swap pipewire-media-session wireplumber" does not lead to working sound. What to do? File a different bug? But for what?

I hit this too. Some combination of systemctl --user enable --now wireplumber and sudo dnf reinstall wireplumber and rebooting fixed it for me. It for sure was not enabled post upgrade.

I managed to resolve my issue - turns out for some reason Fedora isn't shipping with the alsa-firmware package, meaning a lot of audio devices won't work by default.

Try running
sudo dnf install alsa-firmware

ingli: what does 'systemctl --user status pipewire.service' say (run as regular user, not root)?

gene: sounds like you hit exactly the case this bug currently covers (service not enabled on upgrade). We're hoping the update submitted yesterday will resolve it in future.

Robot Ross: indeed we don't install alsa-firmware by default. We *do* install alsa-sof-firmware by default, though, which AIUI was supposed to cover most 'normal' devices. What's your hardware that needs alsa-firmware to work? It may be worth filing a separate bug for that.

Thanks!

I've got a Creative SoundBlaster AE-7 ( ca0132 ), which relies on ctefx.bin in /lib/firmware

I did file a bug, although it being my first time I'm not sure I did it right:
https://bugzilla.redhat.com/show_bug.cgi?id=2019855

(In reply to Adam Williamson from comment #53)
> ingli: what does 'systemctl --user status pipewire.service' say (run as
> regular user, not root)?

systemctl --user status pipewire.service
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor p>
    Drop-In: /usr/lib/systemd/user/pipewire.service.d
             └─00-uresourced.conf
     Active: active (running) since Wed 2021-11-03 20:38:38 CET; 6min ago
TriggeredBy: ● pipewire.socket
   Main PID: 6607 (pipewire)
      Tasks: 2 (limit: 77011)
     Memory: 5.1M
        CPU: 32ms
     CGroup: /user.slice/user-1003.slice/user/session.slice/pipewi>
             └─6607 /usr/bin/pipewire

Nov 03 20:38:38 idesktop systemd[5074]: Started PipeWire Multimedia Service.
lines 1-14/14 (END)

(In reply to rickw from comment #48)
> I had this problem this morning after upgrading to fedora 35 from a recent
> clean install of Fedora 34.   It may be significant that I installed the KDE
> spin of F34, thus not so much Gnome.  In order to get sound working, I had
> to run "dnf install --allowerasing pulseaudio-module-gsettings" to provoke
> dnf to actually switch from pipewire-media-session to wireplumber.  That
> fixed my issue.

I am not sure what precisely did the job, but my last action before rebooting was running

 "dnf install --allowerasing pulseaudio-module-gsettings" 

and after the reboot sound worked.

Well, (In reply to ingli from comment #56)

> I am not sure what precisely did the job, but my last action before
> rebooting was running
> 
>  "dnf install --allowerasing pulseaudio-module-gsettings" 
> 
> and after the reboot sound worked.

Well, I must disagree with myself. Sound is very unstable and unreliable. I have to turn on & off my external sound card plug/unplug etc the USB repeatedly, occasionally run "systemctl --user enable --now wireplumber" to get sound. Sound sometimes disappears when I switch applications, or when I switch output devices. In between I feel I have to reboot the system, when I cannot get the sound to work again. This was not the case before on f34.

So, sorry, normally I would offer to run a series of more precise tests, but as I relied on Fedora to work, I upgraded on my production computer - and I need that for lots of work these days...

I tried upgrading to wireplumber 0.4.4-3, but the wireplumber service remains disabled. I also fail to understand how it could have fixed anything. It has a trigger on uninstalling the old fedora-release that no longer depends on systemd-update-helper, but that removal that was already done when the system was upgraded to F35.

(It might help to fix it F34→F35 upgrades in the future, though.)

FEDORA-2021-4d8b11e08a has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

(In reply to Göran Uddeborg from comment #58)
> I tried upgrading to wireplumber 0.4.4-3, but the wireplumber service
> remains disabled. I also fail to understand how it could have fixed
> anything. It has a trigger on uninstalling the old fedora-release that no
> longer depends on systemd-update-helper, but that removal that was already
> done when the system was upgraded to F35.
> 
> (It might help to fix it F34→F35 upgrades in the future, though.)

That is exactly the issue that is being worked on.


Once upgraded you would need to run

   systemctl --global enable wireplumber

unless it is already done during the upgrade from f34 to f35.

Hey everyone. 

Upgraded from Fedora 34 to 35, got no sound problem.
Nothing from this or similar topics worked out.
Wireplumber was running, but there was no sound (though audio devices were detected correctly).
I have E-Mu 0404 usb and Yeti Stereo Microphone.

I had to revert to pipewire, as i need my audio-devices for work.
If anyone's on the same boat that should do it: "sudo dnf swap wireplumber pipewire-media-session".

Does anyone have any insights on what can i fiddle with to make wireplumber work in the future?
Or should i just relax and wait for a major update?

(In reply to Boris Kuznetsov from comment #61)
> Hey everyone. 
> 
> Upgraded from Fedora 34 to 35, got no sound problem.

Wow, i reread that, and it is compelely unclear! I have "no sound" problem!
Sorry, it's not my native language.

The version of fedora is: 5.14.14-300.fc35.x86_64

Hi, have run "systemctl --global enable wireplumber" and updated to 

wireplumber.x86_64                       0.4.4-3.fc35                   @updates
wireplumber-libs.x86_64                  0.4.4-3.fc35                   @updates

and problem persists. no sound after reboot on 5.14.15-300.fc35.x86_64.

Dear sound strategists, a question and a proposal:
- what information can I help with?
- is there an easy way to circumvent the wireplumber infrastructure and get a f34-like sound infrastructure working again? (if there is an easy way to switch back and forth between a well-working sound and the current wireplumber-non-working, then I could happily use my system whilst occasionally testing for whether wireplumber/automatic system config eventually works).


More Info
Running "systemctl --user enable --now wireplumber" does not seem to help.

But unplugging the usb-powered sound card and plugging it back in seems to slightly help.

(In reply to ingli from comment #63)
> Hi, have run "systemctl --global enable wireplumber" and updated to 
> 
> wireplumber.x86_64                       0.4.4-3.fc35                  
> @updates
> wireplumber-libs.x86_64                  0.4.4-3.fc35                  
> @updates
> 
> and problem persists. no sound after reboot on 5.14.15-300.fc35.x86_64.
> 
> Dear sound strategists, a question and a proposal:
> - what information can I help with?
> - is there an easy way to circumvent the wireplumber infrastructure and get
> a f34-like sound infrastructure working again? (if there is an easy way to
> switch back and forth between a well-working sound and the current
> wireplumber-non-working, then I could happily use my system whilst
> occasionally testing for whether wireplumber/automatic system config
> eventually works).
> 
> 
> More Info
> Running "systemctl --user enable --now wireplumber" does not seem to help.
> 
> But unplugging the usb-powered sound card and plugging it back in seems to
> slightly help.

As i mentioned above, i had no luck with wireplumber as well.
"sudo dnf swap wireplumber pipewire-media-session" will revert to pipewire, 
no need to restart or anything, for me it just worked.

(In reply to ingli from comment #63)
> Hi, have run "systemctl --global enable wireplumber" and updated to 
> 
> wireplumber.x86_64                       0.4.4-3.fc35                  
> @updates
> wireplumber-libs.x86_64                  0.4.4-3.fc35                  
> @updates
> 
> and problem persists. no sound after reboot on 5.14.15-300.fc35.x86_64.
> 
> Dear sound strategists, a question and a proposal:
> - what information can I help with?
> - is there an easy way to circumvent the wireplumber infrastructure and get
> a f34-like sound infrastructure working again? (if there is an easy way to
> switch back and forth between a well-working sound and the current
> wireplumber-non-working, then I could happily use my system whilst
> occasionally testing for whether wireplumber/automatic system config
> eventually works).
> 
> 
> More Info
> Running "systemctl --user enable --now wireplumber" does not seem to help.
> 
> But unplugging the usb-powered sound card and plugging it back in seems to
> slightly help.

If you have all three processes as listed below running, then you problem is not related to the current issue.

[vek@mybox ~]$ systemctl --user status session.slice
● session.slice - User Core Session Slice
     Loaded: loaded (/usr/lib/systemd/user/session.slice; static)
     Active: active since Thu 2021-11-04 05:38:52 CET; 6h ago
       Docs: man:systemd.special(7)
      Tasks: 8
     Memory: 40.4M
        CPU: 3.928s
     CGroup: /user.slice/user-1000.slice/user/session.slice
             ├─pipewire-pulse.service
             │ └─878 /usr/bin/pipewire-pulse
             ├─pipewire.service
             │ └─876 /usr/bin/pipewire
             └─wireplumber.service
               └─877 /usr/bin/wireplumber

/usr/bin/pipewire-media-session and /usr/bin/wireplumber are alternative programs for providing pipewire-session-manager service and either one should work -- for now.

Right, just to try and ease some confusion, these are the moving parts and alternatives:

1. Sound server: Pipewire OR Pulseaudio
2. Session manager for Pipewire: wireplumber OR pipewire-media-session

the intended default configuration for F35 is Pipewire as the sound server and wireplumber as the session manager. Villy explained in comment #65 how to check if you are in this state. If you are, but sound is still not working, this is not your bug. You have a different problem.

Boris: you seem to have a bug in wireplumber. It would be best to file it separately, and maybe file it upstream instead/as well: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues

Ingli: first check everything is as Villy showed. if you have pipewire and wireplumber running but still no sound, first try switching to pipewire-session-manager with `sudo dnf swap wireplumber pipewire-media-session` (then check `systemctl --user status session.slice` shows pipewire-media-session.service); if that doesn't work, you can try switching to pulseaudio instead of pipewire, I think `sudo dnf swap pipewire-pulseaudio pulseaudio` should do that (but not 100% sure). The closest configuration to F34 is pipewire+pipewire-media-session; that's what F34 had, but at the time pipewire-media-session was started differently, it was not a user session service, and of course the versions were older.

Sorry for the trouble, everyone.

Goran: indeed, if you hit this bug (wireplumber not getting enabled) on upgrade, the new update won't help you, as you guessed, it is meant to help *other* people upgrading in future. It's tricky for us to fix this automagically for anyone who hit the bug already, because anything we do to make that happen is likely to do unwanted things for people who are intentionally running non-default configs like pipewire-media-session instead of wireplumber. So unfortunately we have to ask you to fix it up manually in that case with the `systemctl --user enable --now wireplumber` command. Sorry again for the trouble.

(In reply to Adam Williamson from comment #67)
> So unfortunately we have to ask you to fix it up
> manually

No problem at all! I intentionally kept one machine "broken" to help in testing fixes. But if it is not in scope to fix already done upgrades (which I realise is pretty tricky), I can easily take care of my own systems.

Just to add an anecdotal data point, after checking state (comment #65), I discovered that on my system (upgraded back from Fedora 28) pulseaudio *and* pipewire were both running, causing various issues. Running "sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio" fixed that.

(In reply to Thomas Moschny from comment #69)
> Just to add an anecdotal data point, after checking state (comment #65), I
> discovered that on my system (upgraded back from Fedora 28) pulseaudio *and*
> pipewire were both running, causing various issues. Running "sudo dnf swap
> --allowerasing pulseaudio pipewire-pulseaudio" fixed that.

I also discovered this after reading Thomas's comment. I have an $old Fedora system that has been regularly upgraded. None of the systemd-related fixes worked for me here. But "sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio" removed some old Pulseaudio packages and fixed my problem.

after "systemctl --user enable --now wireplumber":

             ├─pipewire.service
             │ └─4071 /usr/bin/pipewire
             ├─pulseaudio.service
             │ ├─12324 /usr/bin/pulseaudio --daemonize=no --log-target=journal
             │ └─12391 /usr/libexec/pulse/gsettings-helper
             └─wireplumber.service
               └─4072 /usr/bin/wireplumber

There were still no sound.

After "sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio" and rebooting:

             ├─pipewire-pulse.service
             │ └─2332 /usr/bin/pipewire-pulse
             ├─pipewire.service
             │ └─2328 /usr/bin/pipewire
             └─wireplumber.service
               └─2331 /usr/bin/wireplumber

The last action fixed my sound issues as well.

*** Bug 2018958 has been marked as a duplicate of this bug. ***

OK, so it's kind of looking like in a 'long upgrade' scenario, you can get into a situation where pipewire, pulseaudio, and wireplumber are all installed/enabled, and that breaks stuff. I wonder if wireplumber doesn't handle this situation very well, and that's the problem? As it sort of sounds likely that the affected systems in F34 had both pipewire and pulseaudio enabled, but that was *working*...

I want to raise one thing here. I am on F35 and I found this bug via https://fedoraproject.org/wiki/Common_F35_bugs#No_sound_after_upgrade_.28pulseaudio_still_in_use.29 which links here.

tl;dr - after performing that "swap" command to go back to pulseaudio from pipewire and restarting, all my audio devices work fine and as you'll see below, ONLY pulseaudio is running.

However, it seems that something is launching pipewire again after boot. I don't think it "just happens automatically". For example, I did a test where I booted, confirmed that pulseaudio was running and pipewire was not, then went to Firefox and started a new meeting. I also had the gnome "Settings" box open in the "Sound" pane to monitor. The meeting audio was fine and everything worked. However, when I 

However, after that meeting, I went back to test the speakers using the "Test" button on my default audio (which usually outputs from my laptop's builtin speakers), and nothing came out. I then toggled the audio output in Settings/Sound to the dock's audio and back, and immediately I ran commands as show below which confirmed that suddenly, pipewire was started again. It's not clear to me why this occurred exactly, but I believe it is causing my "audio issues" - output and input device failures which have been persistent and intermittent since I've upgraded to F35 a couple months ago. I originally switched back to pulseaudio because audio did not work at all with pipewire prior.

Frankly, I have not read all the above 73 comments. I have not had the time yet, and the only reason I've had the time to start working on this is that it's been completely blocking me from attending work meetings lately. My point being, apologies if some of this is redundant, but I will get to reading them soon. I will also continue to troubleshoot (I plan to try switching back to pipewire without pulse and then completely remove pipewire if that doesn't work) and post results.

*IF THERE IS A BETTER BZ FOR THIS ISSUE I AM DESCRIBING, please let me know. I am only here as that is what was linked in the "Common F35 bugs" wiki.

See below:


~ $ systemctl --user status wireplumber.service
○ wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
~ $ systemctl --user status session.slice | rg pipewire
~ $ systemctl --user status session.slice | rg pulseaudio
             └─pulseaudio.service
               └─3041 /usr/bin/pulseaudio --daemonize=no --log-target=journal
~ $ systemctl --user status session.slice | rg pulse
             └─pulseaudio.service
               └─3041 /usr/bin/pulseaudio --daemonize=no --log-target=journal
~ $ systemctl --user status session.slice | rg wire
~ $ systemctl --user status wireplumber.service
○ wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
~ $ systemctl --user status wireplumber.service
○ wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
~ $ systemctl --user status session.slice | rg wire
~ $ systemctl --user status session.slice | rg pulse
             └─pulseaudio.service
               └─3041 /usr/bin/pulseaudio --daemonize=no --log-target=journal
~ $ systemctl --user status wireplumber.service
○ wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
~ $ systemctl --user status session.slice | rg wire
~ $ systemctl --user status session.slice | rg pulse
             └─pulseaudio.service
               └─3041 /usr/bin/pulseaudio --daemonize=no --log-target=journal
~ $ systemctl --user status session.slice | rg pulse
             ├─pulseaudio.service
             │ └─3041 /usr/bin/pulseaudio --daemonize=no --log-target=journal
~ $ systemctl --user status session.slice | rg wire
             ├─pipewire.service
             │ └─5878 /usr/bin/pipewire
             ├─wireplumber.service
             │ └─5879 /usr/bin/wireplumber
~ $ systemctl --user status wireplumber.service
● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-03-03 16:47:53 PST; 3min 7s ago
   Main PID: 5879 (wireplumber)
      Tasks: 4 (limit: 38158)
     Memory: 8.9M
        CPU: 296ms
     CGroup: /user.slice/user-1000.slice/user/session.slice/wireplumber.service
             └─5879 /usr/bin/wireplumber

Mar 03 16:47:53 localhost.localdomain systemd[2705]: Started Multimedia Service Session Manager.
Mar 03 16:47:54 localhost.localdomain wireplumber[5879]: Failed to set scheduler settings: Operation not permitted

(In reply to Todd Cullum from comment #74)
> I want to raise one thing here. I am on F35 and I found this bug via
> https://fedoraproject.org/wiki/Common_F35_bugs#No_sound_after_upgrade_.
> 28pulseaudio_still_in_use.29 which links here.
> 
> tl;dr - after performing that "swap" command to go back to pulseaudio from
> pipewire and restarting, all my audio devices work fine and as you'll see
> below, ONLY pulseaudio is running.
> 

If you want to get rid of pipewire it would make sense to remove all of the pipewire packages.

Also, when piping into the "rg"  (whatever "rg" does) command you may leave out important information from the listing.

I *think* the most promising way to handle this on F35+ is to remove pulseaudio, reboot and then use wireplumber and pipewire only, see comment 69.

So in my case, Running "sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio" did NOT fix that. The only way I was able to fix this is to destroy the symlink to wireplumber in /etc/systemd/user/pipewire.service.wants because even systctl --user --now disable wireplumber.service was doing this:

~ $ systemctl --user is-enabled wireplumber.service
enabled
~ $ systemctl --user --now disable wireplumber.service
~ $ systemctl --user is-enabled wireplumber.service
enabled

I *was* able to disable pipewire.service successfully, but it was restarted again on reboot anyway - likely due to gnome or something.

Why did I resort to this? Because when I tried to remove either pipewire OR pulseaudio, gnome-shell depends on both and would be removed; which I did not want.

I believe the issue that I was having was caused specifically by wireplumber.service running simultaneously with pulseaudio. Will update if I find any other useful info out.

(In reply to Todd Cullum from comment #77)
> So in my case, Running "sudo dnf swap --allowerasing pulseaudio
> pipewire-pulseaudio" did NOT fix that. The only way I was able to fix this
> is to destroy the symlink to wireplumber in
> /etc/systemd/user/pipewire.service.wants because even systctl --user --now
> disable wireplumber.service was doing this:
> 
> ~ $ systemctl --user is-enabled wireplumber.service
> enabled
> ~ $ systemctl --user --now disable wireplumber.service
> ~ $ systemctl --user is-enabled wireplumber.service
> enabled
> 
> I *was* able to disable pipewire.service successfully, but it was restarted
> again on reboot anyway - likely due to gnome or something.
> 

wireplumber is normally socket activatet, so you will need to disable pipewire.socket.

Also, you should specify --global instead of --user as these services are globally enabled.