I was using using my PS5 controller with F36. However recently it stopped paring. I thought it was the controller but then I realised my desktop cannot find any bluetooth devices (I tested with my phone, and the controller paired with my laptop, also Fedora, just fine). I have now upgraded to F37, but my problem has persisted. I’m not really sure how to debug this.
These are some of the things I have tried:
# lshw -short | grep -i blue
/0/100/2.1/0/0/5 communication AX200 Bluetooth
# lsusb | grep -i blue
Bus 001 Device 003: ID 8087:0029 Intel Corp. AX200 Bluetooth
# bluetoothctl show
No default controller available
# bluetoothctl devices
No default controller available
# bluetoothctl info
Missing device address argument
# lsmod | grep -e bt -e blue
btusb 65536 0
btrtl 28672 1 btusb
btbcm 24576 1 btusb
btintel 49152 1 btusb
btmtk 16384 1 btusb
bluetooth 880640 15 btrtl,btmtk,btintel,btbcm,bnep,btusb
rfkill 36864 9 iwlmvm,asus_wmi,bluetooth,cfg80211
Turning it on/off from the UI reflects correctly in the output of rfkill. Also I notice that there’s an error in the logs:
# journalctl --no-hostname -b -u bluetooth
Dec 11 22:32:54 systemd[1]: Starting bluetooth.service - Bluetooth service...
Dec 11 22:32:54 systemd[963]: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555)
Dec 11 22:32:54 bluetoothd[963]: Bluetooth daemon 5.66
Dec 11 22:32:54 bluetoothd[963]: Starting SDP server
Dec 11 22:32:54 bluetoothd[963]: profiles/audio/vcp.c:vcp_init() D-Bus experimental not enabled
Dec 11 22:32:54 bluetoothd[963]: src/plugin.c:plugin_init() Failed to init vcp plugin
Dec 11 22:32:54 bluetoothd[963]: profiles/audio/mcp.c:mcp_init() D-Bus experimental not enabled
Dec 11 22:32:54 bluetoothd[963]: src/plugin.c:plugin_init() Failed to init mcp plugin
Dec 11 22:32:54 bluetoothd[963]: profiles/audio/bap.c:bap_init() D-Bus experimental not enabled
Dec 11 22:32:54 bluetoothd[963]: src/plugin.c:plugin_init() Failed to init bap plugin
Dec 11 22:32:54 bluetoothd[963]: Bluetooth management interface 1.22 initialized
Dec 11 22:32:54 systemd[1]: Started bluetooth.service - Bluetooth service.
Not sure what to make of this, I have searched the errors but did not find anything. I also noticed bt-adapter coredumps:
That tells you the file or directory is not writable. 755 → rwxr-xr-x & 555 → r-xr-xr-x.
What is the output of rfkill
What is the difference if you run sudo restorecon -r / and wait for it to finish then try again (just in case it is a change in selinux policies)
On my system I see
[root@eagle /]# ls -ld /etc/bluetooth/
drwxr-xr-x. 2 root root 4096 Nov 17 07:11 /etc/bluetooth/
[root@eagle /]# ls -ld /etc/bluetooth/*
-rw-r--r--. 1 root root 11118 Nov 17 07:11 /etc/bluetooth/main.conf
I also searched for other directories named bluetooth and checked permissions with ls -ld $(find /usr -type d -name bluetooth 2>/dev/null )
and ls -ld $(find /etc -type d -name bluetooth 2>/dev/null )
Doing the same starting at / was an extended wait but seemed to give the same results when it finally completed. This one did add /var/lib/bluetooth and one under the selinux tree.
Note that bluetooth devices do not remain in active scanning mode. It shows that the modules are loaded, and the device is configured. The UI turns on the scan in prep for connection or pairing so I am not 100% certain I understand when you say that it never manages to detect a device.
Are you saying that it scans but does not connect to an already paired device? That it scans but never sees another device that is also in pairing mode? That it never scans?
What are you expecting?
What are you trying to do?
What is the current bluetooth config?
Do you have a paired device it cannot connect to? If this is the case I sometimes have had to unpair from both devices then re-pair them.
Do you have a device that is not paired and has never been paired but the system cannot see it when it is placed in pairing mode?
Do you have a device that has previously been paired but is now not recognized? If this is the case then again you may need to wipe out the pairing info on (and for) the device then re-pair it.
You can override the service temporarily to see if it’s contributing to the issue: systemctl edit bluetooth.service
### Anything between here and the comment below will become the new contents of the file
[Service]
ConfigurationDirectoryMode=0755
### Lines below this comment will be discarded
You can undo the override with systemctl revert bluetooth.service
This little bit seems to imply that something critical to bluetooth was corrupted during the upgrade and will need repaired. The error noted indicates the same since you found the permissions noted in that error seem to not exist.
You might need to first remove everything bluetooth related then reboot and do a new clean install of the same. At times that seems the only way to fix a ‘minor’ bit of corruption since even a reinstall does not do a checksum verify of the files.
Because of an unrelated matter, I had to reflash my BIOS. After setting up everything, all Bluetooth devices are detected again! I guess for whatever reason something got corrupted, although can’t see how. I haven’t fiddled with the BIOS ever since I initially setup the computer.
Bios updates are provided because the manufacturer finds it is necessary. It seems you got hit by software updates that were incompatible with the older bios and the updated bios fixed that.
Yeah could be. I reflashed my BIOS for something else entirely though . I upgraded my RAM to a higher frequency, but while choosing the new profile, I made a mistake and corrupted the BIOS. If I hadn’t messed up, never would have known.
I’m wondering what could I have done differently in my initial debugging that could indicate to the issue. Also, wouldn’t this still be a bug that needs to be fixed?
I have no clue how you would debug an issue related to bios other than trying a different identical machine with the updated bios and the same software. If the updated bios fixes the problem then the issue is bios related. If not then it would be OS related → probably kernel or drivers or firmware.
Is it still a bug if the updated bios fixed the issue? I would not consider it such. Instead I would consider that the bug was fixed because the bios update fixed the problem and the bug was thus related to out-of-date bios software.
. I upgraded my RAM to a higher frequency, but while choosing the new profile, I made a mistake and corrupted the BIOS. If I hadn’t messed up, never would have known.