Includes significant AI-generated content. I personally experienced this issue. The troubleshooting and solutions below successfully resolved my problem.
Summary
On a Lenovo ThinkPad X1 Aura Edition running Fedora, Bluetooth would immediately toggle back off in GNOME Settings. bluetooth.service was running and rfkill showed Bluetooth was not blocked, but bluetoothctl returned:
No default controller available
The issue was not the mouse or BlueZ service. The Intel Bluetooth controller existed at the kernel/PCI layer but was not exposed as a usable Bluetooth controller until the relevant Intel firmware files were decompressed and the PCIe Bluetooth device was rescanned.
Environment
Fedora release 43Kernel: 6.19.14-200.fc43.x86_64Laptop: Lenovo ThinkPad X1 Aura EditionBluetooth device:00:14.7 Bluetooth [0d11]: Intel Corporation Device [8086:a876] (rev 10)Driver path: btintel_pcie
The key symptom was that the device existed under /sys/class/bluetooth/hci0, but btmgmt info showed zero usable controllers:
bluetoothctl show# No default controller availablesudo btmgmt info# Index list with 0 items
The kernel logs showed repeated Intel PCIe Bluetooth power-state failures:
Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entrybtintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend [btintel_pcie] returns -16btintel_pcie 0000:00:14.7: PM: failed to suspend async: error -16
The affected machine showed Intel Bluetooth PCI device 8086:a876 and repeated btintel_pcie D2/suspend failures.
Diagnosis Commands
bluetoothctl showrfkill list allsystemctl status bluetooth --no-pagerls -la /sys/class/bluetoothsudo btmgmt infosudo lspci -nn -s 00:14.7lsmod | grep -Ei 'bluetooth|btintel|btintel_pcie|btusb'sudo dmesg -T | grep -Ei 'bluetooth|btintel|btintel_pcie|hci|firmware|rfkill' | tail -150
Important distinction: this machine used btintel_pcie, not btusb. A typical btusb reload fix did not apply.
Fix
First, decompress the relevant Intel Bluetooth firmware files:
cd /usr/lib/firmware/intelsudo xz -dk ibt-0190-0291-pci.sfi.xz 2>/dev/null || truesudo xz -dk ibt-0190-0291-pci.ddc.xz 2>/dev/null || truesudo xz -dk ibt-0190-0291.sfi.xz 2>/dev/null || truesudo xz -dk ibt-0190-0291.ddc.xz 2>/dev/null || truesudo xz -dk ibt-0190-0291-iml.sfi.xz 2>/dev/null || truels -l ibt-0190-0291*
Then remove and rescan the PCIe Bluetooth device:
sudo systemctl stop bluetoothecho 1 | sudo tee /sys/bus/pci/devices/0000:00:14.7/removesleep 3echo 1 | sudo tee /sys/bus/pci/rescansleep 3sudo systemctl start bluetoothbluetoothctl showsudo btmgmt info
After this, Bluetooth appeared correctly:
Controller 84:D1:C1:09:4D:3A (public) Powered: yes Pairable: yesIndex list with 1 itemhci0: Primary controller
Reusable Repair Script
Adjust 0000:00:14.7 if your Bluetooth PCI address is different.
sudo tee /usr/local/sbin/fix-intel-bluetooth-x1-aura.sh >/dev/null <<'EOF'#!/usr/bin/env bashset -euo pipefailcd /usr/lib/firmware/intelxz -dk ibt-0190-0291-pci.sfi.xz 2>/dev/null || truexz -dk ibt-0190-0291-pci.ddc.xz 2>/dev/null || truexz -dk ibt-0190-0291.sfi.xz 2>/dev/null || truexz -dk ibt-0190-0291.ddc.xz 2>/dev/null || truexz -dk ibt-0190-0291-iml.sfi.xz 2>/dev/null || truesystemctl stop bluetoothecho 1 > /sys/bus/pci/devices/0000:00:14.7/removesleep 3echo 1 > /sys/bus/pci/rescansleep 3systemctl start bluetoothbluetoothctl showbtmgmt infoEOFsudo chmod +x /usr/local/sbin/fix-intel-bluetooth-x1-aura.sh
Run later with:
sudo /usr/local/sbin/fix-intel-bluetooth-x1-aura.sh
Notes
This appears to be an Intel PCIe Bluetooth firmware/driver issue, not a generic BlueZ issue. The key indicators were:
bluetooth.servicewas active.rfkillshowed no soft or hard block./sys/class/bluetooth/hci0existed.btmgmt infostill showed no usable controllers.dmesgshowed repeatedbtintel_pcieD2 power-state failures.
Future linux-firmware package updates may remove the decompressed firmware files, so the repair script may need to be rerun after system updates.
HDP Capital 