Bluetooth Devices Not Pairing in Linux? Here’s How to Fix It

You click “Pair,” the spinner runs for ten seconds, and you get “Connection failed” or nothing at all. The same headphones work perfectly on your phone, which makes it more annoying.

Bluetooth devices not pairing in Linux is one of the most common desktop complaints, and it’s rarely random. It almost always comes down to one of six causes: a blocked radio, a stopped service, missing firmware, a stale pairing record, a confused pairing agent, or a dual-boot key mismatch.

This guide follows the order I’d check them on a real machine, from the fastest fixes to the deeper ones.

In a hurry? Run these three commands first:

sudo systemctl enable --now bluetooth
sudo rfkill unblock bluetooth
bluetoothctl remove AA:BB:CC:DD:EE:FF

Replace the MAC address with your device’s. Then pair again. If that doesn’t fix it, keep reading.

How Bluetooth Works on Linux (The 60-Second Version)

Knowing the layers tells you where to look.

• Kernel drivers (btusb, btintel, btrtl, btmtk, btbcm) talk to the adapter.
• Firmware from the linux-firmware package is loaded onto the chip at startup.
• BlueZ (bluetoothd) handles scanning, pairing and bonding.
• Your desktop (GNOME, KDE, Blueman) is a front end that talks to BlueZ over D-Bus.
• PipeWire with WirePlumber (or older PulseAudio) handles audio after a headset connects.

When pairing fails, the fault sits in exactly one of those layers.

Current Software Versions (Last Verified)

Version mismatches cause real pairing bugs, so check yours against these.

Component	Latest version I could verify	Source
Linux kernel (stable)	7.2.x (7.2.2 listed 28 Aug 2026)	kernel.org
Linux kernel (longterm)	6.18, 6.12, 6.6 branches	kernel.org
BlueZ	5.87 (July 2026 distro build)	GitHub repo

Distros often ship older BlueZ builds with backported patches, so run bluetoothctl --version and uname -r on your own system. A packaging note from OpenWrt describes a backported patch that fixed link-key loading on kernel 6.10 and newer. A very new kernel paired with a very old BlueZ (or the reverse) is a prime suspect.

Step 1: Check the Basics First

I’ve seen people spend an hour on firmware when the radio was simply soft-blocked. Start here.

Is the service running?

systemctl status bluetooth
sudo systemctl enable --now bluetooth

Is the adapter blocked?

rfkill list
sudo rfkill unblock bluetooth

“Soft blocked: yes” can be fixed in software. “Hard blocked: yes” means a physical switch or an Fn-key combo is off, so toggle the hardware key.

Does Linux see an adapter?

bluetoothctl list
lsusb | grep -i bluetooth

An empty bluetoothctl list means BlueZ has no controller to work with. Jump to Step 5.

[INSERT SCREENSHOT: your terminal showing rfkill list with a blocked and an unblocked state]

Step 2: Pair Manually with bluetoothctl

Graphical tools hide errors. The command-line client shows you exactly what BlueZ is complaining about.

bluetoothctl
power on
agent on
default-agent
scan on

Put your device in pairing mode. When its MAC address appears:

pair AA:BB:CC:DD:EE:FF
trust AA:BB:CC:DD:EE:FF
connect AA:BB:CC:DD:EE:FF

Don’t skip trust. Without it, many devices pair once and then refuse to reconnect after a reboot.

What the Error Messages Mean

Message	Usual cause
org.bluez.Error.AuthenticationFailed	Stale bond, wrong PIN, or no active agent
org.bluez.Error.AlreadyExists	Leftover record blocking a fresh pair
org.bluez.Error.ConnectionAttemptFailed	Device asleep, out of pairing mode, or tied to another host
org.bluez.Error.NotReady	Adapter off or blocked
Failed to set power on	Often rfkill, firmware or driver trouble
br-connection-profile-unavailable	Paired fine, but the audio or HID profile didn’t load

That last one is a classic. Pairing worked, but the audio stack didn’t pick up the profile. See Step 8.

[INSERT SCREENSHOT: a real bluetoothctl pairing attempt, successful or failed]

Step 3: Clear a Stale Pairing Record

If a device paired before and now won’t re-pair, the old bond is usually the culprit. Linux holds a key the device has forgotten, or the other way round.

bluetoothctl remove AA:BB:CC:DD:EE:FF

Then forget the device on its own end too. On most headphones that’s a long press or a reset button combo, and it differs by brand, so check the manual. Then pair fresh.

If the device still acts up, clear BlueZ’s cache for that adapter. This removes cached info, not your bonds:

sudo systemctl stop bluetooth
sudo rm -rf /var/lib/bluetooth/<adapter-MAC>/cache
sudo systemctl start bluetooth

Deleting the whole adapter folder wipes every paired device, so keep that for a true last resort.

Step 4: Read the Logs Instead of Guessing

journalctl -u bluetooth -b
sudo dmesg | grep -i bluetooth
sudo btmon

Run btmon in one terminal while you attempt pairing in another. It shows the raw traffic between BlueZ and the controller.

Log line	What it points to
Opcode 0x... failed: -110	Timeout, often firmware or USB power
Direct firmware load ... failed	Missing firmware file
command tx timeout	USB autosuspend or a hardware hiccup
“PIN or Key Missing” in btmon	Stale bond, so go back to Step 3

Step 5: Fix Driver and Firmware Problems

This step covers most “no adapter” and “won’t power on” cases.

Update the firmware package

Most modern chips load firmware at boot. A missing file leaves the chip dead or half-working.

# Debian / Ubuntu
sudo apt update && sudo apt install --reinstall linux-firmware

# Fedora
sudo dnf upgrade linux-firmware

# Arch
sudo pacman -Syu linux-firmware

Debian note: firmware for some chips lives in the non-free firmware component, so enable it in your APT sources if the package isn’t found.

Then do a cold power-off, not just a restart. Some chips keep their old state through a warm reboot.

Pick (or Diagnose) the Right Chipset

Chipset choice makes a big difference on Linux.

Adapter	Bluetooth version	Driver	Linux experience
Intel AX210	5.3	btusb + btintel	Very reliable, firmware in linux-firmware
Intel BE200	5.4	btusb + btintel	Solid on recent kernels, needs current firmware
MediaTek MT7922	5.2	btusb + btmtk	Works well, early kernels had quirks
Realtek RTL8761B dongles	5.0 to 5.1 (varies by dongle)	btusb + btrtl	Cheap and widely supported, build quality varies
Broadcom BCM20702	4.0	btusb + btbcm	Old but functional, may need extra firmware

Specs reflect the chipset vendors’ published figures. Always confirm the exact module on your own laptop with lsusb, because OEMs sometimes ship variants.

When buying a USB dongle, pick one that names its chipset. Unlabelled dongles are a gamble because you can’t check Linux support first.

Stop USB Autosuspend From Killing the Adapter

Laptop power saving can put the Bluetooth USB device to sleep mid-pairing.

echo 'options btusb enable_autosuspend=n' | sudo tee /etc/modprobe.d/btusb.conf
sudo modprobe -r btusb && sudo modprobe btusb

If pairing suddenly gets stable, you’ve found it.

Step 6: Dual-Boot Link Key Conflicts

If you share a machine between Windows and Linux, this is likely your problem.

A device stores only one key per host address. Pair it on Windows, then pair it on Linux, and Windows’ key is overwritten. Switch back, re-pair on Windows, and Linux loses access. Both systems think they hold the right key, but the device remembers only one.

Your two options:

1. Re-pair every time you switch. Simple but tedious.
2. Share the key. Pair on Windows, extract the key from the Windows registry with an offline tool such as chntpw, and write it into /var/lib/bluetooth/<adapter>/<device>/info under [LinkKey].

Stop the bluetooth service before editing, restart it afterwards, and back up the file first. Bluetooth Low Energy devices store keys differently, so this is trickier for them. For a keyboard and mouse you use daily, it’s worth doing once.

Step 7: Tweak /etc/bluetooth/main.conf

sudo nano /etc/bluetooth/main.conf
sudo systemctl restart bluetooth

Option	What it does	When to use it
AutoEnable=true	Powers the adapter on at boot	Bluetooth is off after every restart
JustWorksRepairing = always	Lets a device that lost its bond re-pair without manual removal	Personal machines only, since it’s slightly less strict
ControllerMode = bredr	Forces classic Bluetooth only	A dual-mode device keeps choosing the wrong transport
FastConnectable = true	Speeds up reconnects	You accept slightly higher power use

Change one setting at a time. If you change four and it works, you’ll never know which one fixed it. Option names and defaults can vary between BlueZ versions, so check the comments in your own main.conf.

Step 8: Paired, but No Sound?

Many “pairing” complaints are really audio problems. The headset shows as connected, yet nothing plays.

systemctl --user restart wireplumber pipewire pipewire-pulse

Then open pavucontrol or your desktop sound settings and make sure the headset is on A2DP (high-quality playback) rather than HSP/HFP (headset mode with lower quality and a mic).

Audio stack	Bluetooth handling	Notes
PipeWire + WirePlumber	Built in, supports A2DP, HFP and modern codecs	Default on current mainstream distros and the best-supported option
PulseAudio	Needs Bluetooth modules loaded	Still works but gets less attention for new features

If you’re on PulseAudio and fighting codec problems, moving to PipeWire is often the real fix. Follow your distro’s supported migration steps, as they differ.

Step 9: Device-Specific Gotchas

• Keyboards asking for a PIN: some show a six-digit code you must type on the keyboard itself. Make sure agent on and default-agent are set or the prompt never appears.
• Game controllers: they often need a special button combo for pairing mode. Always run trust, and if one connects then drops instantly, check that the uinput module is available.
• Earbuds paired to your phone: many reconnect to the last device and won’t enter pairing mode on their own. Switch Bluetooth off on the phone, or forget the device there, first.
• Wi-Fi interference: both share the 2.4 GHz band. If audio stutters only while Wi-Fi is busy, move your Wi-Fi to 5 GHz or 6 GHz.

Step 10: Distro Quick Reference

Distro family	Install BlueZ	Notes
Ubuntu / Debian	sudo apt install bluez	Usually preinstalled. Debian may need the non-free firmware component.
Fedora	sudo dnf install bluez	Preinstalled on most spins, with PipeWire by default.
Arch / Manjaro	sudo pacman -S bluez bluez-utils	You must run sudo systemctl enable --now bluetooth yourself.
openSUSE	sudo zypper install bluez	Check that the service is enabled after install.

The Arch Wiki Bluetooth page is one of the most thorough references and applies well beyond Arch. BlueZ’s official site and GitHub repository are the right places to report a genuine bug.

Step 11: Last-Resort Resets

1. Full power cycle. Shut down, unplug the laptop and hold the power button for 30 seconds before booting. This clears chip state.
2. Reset the controller. Run sudo btmgmt power off then sudo btmgmt power on.
3. Try another kernel. Boot an older or newer one from GRUB. If pairing works on one, you’ve found a regression worth reporting.
4. Test a USB dongle. A known-good adapter tells you quickly whether the built-in chip is at fault.
5. Boot a live USB. If a current live ISO pairs fine, your installed system has a configuration problem, not a hardware one.

Quick Troubleshooting Checklist

Symptom	First thing to try
No adapter found	Check rfkill, reinstall linux-firmware, cold boot
Adapter found, won’t power on	Read dmesg, check firmware, test USB autosuspend
Device missing from scan	Confirm pairing mode, move closer, forget it on other hosts
Auth error during pairing	Remove on both sides, then re-pair
Pairs but won’t reconnect	Run trust, check AutoEnable and bond records
Works on Windows, not Linux	Dual-boot key mismatch
Paired but silent	Restart PipeWire, switch to A2DP

A Quick Security Note

Pairing keys in /var/lib/bluetooth/ are sensitive, and anyone with root access to your disk can read them. Use full-disk encryption on laptops, and redact keys before pasting info files into forum posts or bug reports. Turn off discoverable mode once you finish pairing, especially in public places.

Final Thoughts

Bluetooth devices not pairing in Linux looks like one big mystery, but it breaks down into a short list of causes. Confirm the service and radio are alive, pair manually so you see the real error, clear stale bonds, verify firmware, and handle dual-boot keys if they apply. Work down this guide in order and you’ll usually find the culprit before reaching the reset section.

Still stuck? Collect the output of journalctl -u bluetooth -b, dmesg | grep -i bluetooth and lsusb, then share it with your distro and kernel version. That’s what makes a bug report useful and speeds up help from the community.

---

Frequently Asked Questions

---

Disclaimer: This guide is for general informational purposes. Commands that edit system files or delete data can affect your setup, so back up important files first and adapt steps to your distribution. Software versions change quickly, so check your distro’s documentation and the official BlueZ and kernel.org pages for the newest details.

---