I’m having an issue where I cannot enable Bluetooth on my Fedora 44 system. When I go to GNOME Settings and click the Bluetooth toggle, it turns on for a split second and immediately turns itself back off.
I am dual-booting with Windows 11. Bluetooth works perfectly fine in Windows, but fails in Fedora.
Here is my system information and the relevant logs:
System Environment:
Hardware Model: ThinkBook 14 G8+ AHP
OS: Fedora 44 (Dual boot with Windows 11)
Kernel: 7.0.4-200.fc44.x86_64
Desktop Environment: GNOME Shell 50.1
Power Management: tuned-ppd
Bluetooth Hardware: Realtek Semiconductor Corp. Bluetooth Radio (ID 0bda:b853 - RTL8852BU)
Logs & Command Outputs:
lsusb | grep -i blue
Bus 001 Device 004: ID 0bda:b853 Realtek Semiconductor Corp. Bluetooth Radio
systemctl status bluetooth shows the service is actively running without errors:
● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Wed 2026-05-13 15:47:58 CST
Status: "Running"
However, sudo dmesg | grep Bluetooth reveals an opcode failure (Error -16, which I suspect means -EBUSY):
systemctl status systemd-rfkill.service shows it is inactive (dead) and deactivated successfully.
What I have tried so far (without success):
Reloading the kernel module: I ran sudo modprobe -r btusb && sudo modprobe btusb. The module unloads and reloads successfully, but the hardware remains stuck in a busy state (producing the same error).
Firmware: Checked linux-firmware packages, and they are already fully up to date.
Turned off “Fast Startup” in Windows and rebooted into fedora, but still didn’t work.
Has anyone encountered this Opcode 0xfcf0 failed: -16 error with Realtek RTL8852BU adapters? Any help or pointers on how to fix this would be greatly appreciated!
Additional information: I even tried disabling the Bluetooth driver in Windows and then rebooting into fedora, yet I still cannot use Bluetooth in fedora.
As I understand it from a some quick internet research, Windows has a separate “USB Selective Suspend” setting that can leave USB devices in a suspended state even across reboots and that can confuse the btusb driver in Linux.
In your Windows install, you might be able to fix that by opening Device Manager, expanding “Universal Serial Bus controllers,” finding your Realtek Bluetooth device (or any USB root hub/host controller, really), and unchecking “Allow the computer to turn off this device to save power” in “Power Management” in Properties. Device Manager > Universal Serial Bus controllers > the Realtek device > Properties > Power Management > uncheck "Allow the computer to turn off this device to save power"
Then, change the advanced power settings for USB selective suspend in Power Options to “Disabled.” Power Options > Change plan settings > Change advanced power settings > USB settings > USB selective suspend setting > set to "Disabled"
Complete a full shutdown from Windows, not just a restart, and boot into Fedora. The benefit here seems to be that you don’t even need to mess around with your Linux install.
I’m sure that I followed your steps: disabled “USB Selective Suspend”, unchecked “Allow the computer to turn off this device” in Device Manager, and performed a full shutdown. But it still didn’t work.
But the output of demsg didn’t come up with
Opcode 0xfcf0 failed: -16
Instead, it finally said
Bluetooth: BNEP socket layer initialized
Does it solve the problem to some extent? May I ask if there is a way to further investigate the issue? Could there be other possible causes for this problem?
Happy to try and help… I’ve dealt with far too many bluetooth issues myself, so I know how frustrating it can be!
The good news is that the changes in Windows do seem to have helped the bluetooth loading along in Fedora and there are a few things to look at in Fedora.
Can you post the results from a couple commands?
sudo journalctl -u bluetooth.service -n 100 --no-pager
rfkill list all
sudo dmesg | grep -iE 'bluetooth|btusb|hci0|rfkill' | tail -40
Sure!
The output of sudo journalctl -u bluetooth.service -n 100 --no-pager was so long that I decided to take a portion of the output, but I assure you that the other parts of the output are the same as this part, just at different times.
I think the output of this command shows that my Bluetooth service looks normal, right?
rfkill list all
0: ideapad_wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
1: ideapad_bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
6: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Thanks for your advice! I successfully executed the command you gave.
However, a very telling symptom occurred: after running sudo journalctl -u bluetooth.service -f, the log output completely stopped and froze right after initializing the hostname plugin at first (as shown below).
And no matter how many times I clicked the Bluetooth toggle in the settings GUI, absolutely zero new logs were generated in the terminal:
Those outputs confirm the firmware initialized the USB interface, but it failed to load. The root cause seems likely to be an incomplete firmware initialization and there’s a really good chance this is a driver conflict.
To test that hypothesis, you’ll have to unload the wifi driver stack completely, which will (obviously) drop your internet connection with:
Re-running hciconfig -a and bluetoothctl list should give you a real MAC address and the latter command should show you the adapter.
If that all works, the permanent fix would be to make sure btusb is brought fully up before rtw89 claims the shared interface. You can accomplish that with a new modprobe “rule:”
sudo tee /etc/modprobe.d/rtl8852bu-load-order.conf << 'EOF'
# RTL8852BU: load Bluetooth before WiFi to avoid coex register conflict
softdep rtw89_8852be pre: btusb
EOF
sudo dracut --force
sudo reboot
Problems with bluetooth in Linux are all too common. If bluetooth is “mission critical” for your use of Linux, it is well worth the small cost of a USB dongle to use while investigating the issue with onboard devices.
had also bluetooth issues and fixed it. (I use Fedora 44 Silverblue with Kernel 7)
I added sudo rpm-ostree kargs --append=usbcore.autosuspend=-1 and now it works. Maybe this helps
Okay, one of the few things we seem to know is the wifi driver isn’t the cause; rather, it looks like the chip itself is ignoring the config. Let’s verify which firmware files are being used:
Thanks for sharing the detailed workflow and the link.
Unfortunately, after trying the steps you mentioned in your blog, the Bluetooth adapter still initializes with the same all-zero MAC address and -16 error in Fedora.
That being said, I’m glad my stubborn troubleshooting case could serve as a useful real-world example for your freelance tech support article. Thanks again for the effort and the write-up.
