Fedora Crash back to login screen when using bluetooth headphones

One of my colleagues and myself are having issues using headphones in meeting rooms (slack/teams) when switching to the mic of the headphones Fedora instantly freezes and goes to the login screen. every application is then closed aswell.

This issue happens after updating fedora on January 23 2026.

Anyone have an idea how to fix this?

Regards

8 Likes

Can confirm. I’m having the exact same issue as well.

Anything we can do to help troubleshoot this?

Thanks in advance.

Can also confirm, I’m experiencing the same issue at the moment

It looks like this is a known issue when connecting a Bluetooth device that has a microphone. A fix was very recently merged in libgnome-volume-control, as well as some work in pipewire. I’m not sure when this fix will be released and make its way to a Fedora update.

There’s a workaround to bypass the issue for now on that libgnome-volume-control thread from pv:

Workarounds are wpctl settings bluetooth.autoswitch-to-headset-profile false or downgrading wireplumber back to 0.5.12.

This thread seems useful for downgrading wireplummer on Fedora if you want to go that route. (Similar thread for silverblue).

14 Likes

The workaround fixed my issue. Thank you very much!

Thank you for the summary. I chose disabling the autoswitch.
Can you please give me a hint where I can find information about the update that solves the issue in the future? I want to enable autoswitch again. So in which changelogs do I have to search it? Unfortunetly the changelog in the gnome software store is not available for most of the updates.

Hmm, could my issue be related?

I also use headphones that have a microphone. Though I have done my utmost to disable the damn thing, using wpctl settings --save bluetooth.autoswitch-to-headset-profile false but this doesn’t work.

Not necessarily obviously related, since the issue in this topic is apparently new in 0.5.13 and disappears on downgrading to 0.5.12; whereas you see your issue on 0.5.12.

1 Like

Hello, just to confirm that this issue is still happening on Fedora 43 for me. Hoping for a speedy release of the fix that was mentioned above :slight_smile:

Someone kindly linked the Fedora ticket at the bottom of the libgnome-volume-control thread. It looks like the fix is in testing, and if all goes well it should be pushed to stable in the near future. gnome-shell-49.3-2 and gnome-shell-common-49.3-2 are the packages with the fix. Once you have them, you should be able to turn autoswitching back on or update wireplumber.

5 Likes

I also got this issue and workaround fixed it, thanks

This patch has been officially released and I can confirm that it fixes the issue. Thanks for sharing!

I can also confirm gnome-shell-49.3-2/gnome-shell-common-49.3-2 fixed the issue for me, and that it’s available on stable :tada:

If you applied one of the workarounds, you can now safely undo them:

  • If you disabled autoswitching, after updating your system to the new gnome-shell you can run wpctl settings bluetooth.autoswitch-to-headset-profile --reset to reenable autoswitching. You can confirm this by running wpctl settings bluetooth.autoswitch-to-headset-profile afterwards to see that the value is true.
  • If you downgraded wireplumber, you can go to your /etc/dnf/dnf.conf and remove the exclude line for wireplumber, then upgrade your system. (You can do this before updating to the new gnome-shell, so that you get both the latest wireplumber and the fixed gnome-shell in one update.)
2 Likes

Since the fix is for gnome-shell-49.3-2, does this mean that this bug is just going to remain for fedora 42? :thinking:

Someone asked about Fedora 42 on the ticket and a maintainer replied saying it’s in progress. I went to https://packages.fedoraproject.org, searched up gnome-shell, and saw in the recent activity that gnome-shell-48.7-3 for Fedora 42 is being built with a fix for this bug. It’ll also need to go through the testing phase, so it’ll be a little bit, but it looks like it will be fixed. (Thank you to GNOME and the Fedora maintainers for patching and getting this fixed!)

2 Likes

Thanks for checking! I haven’t quite gotten the hang of the fedora build system and bug tracking framework yet, so I wasn’t sure where exactly to look. I’ve mostly just had this link bookmarked for checking what will be in the nightly silverblue 42 build. :+1:

Fixed with success on my Fedora 42 with:

sudo dnf upgrade gnome-shell --enablerepo=updates-testing --refresh
1 Like

Don’t forget to give the testing package karma! :wink: :+1: Making sure you're not a bot!