the lts kernel, unfortunately, did nothing
thanks! will try to cold-boot and see if this gives me anything
currently i know this for sure
- liveusb with endeavouros image ā bluetooth functions as intended
- this is not a hardware issue (after running the checks that were suggested by @kagetora13 i can be absolutely sure of this)
- booting with either the rt or lts kernel does not resolve issue in any way
- most likely i disabled something manually//broke a config
I have exactly the same issue that appeared after an update yesterday if it makes you feel any better. I have gone thru this thread and followed everything, and get the same results as you, even bluetoothctl showing no default controller. My current plan is to update often over the next few days and see if it is fixed. I had this one time several months ago and only after a complete new install of EOS did it work again.
So if it is a pebcak, at least youāre not aloneā¦
EDIT: I say āafter an updateā like I know for sure thatās what caused it - I donāt. I only know an update and bluetooth issues correlate, but not sure about causationā¦
1 Like
good to know that iām not the only one! (i also suspect that an update may have caused this, but i donāt connect new bluetooth devices often enough to know for sure)
in my case bluetoothctl recognizes the default device again (which is not really that useful, since it doesnāt do anything else)
i really want to evade reinstalling over an annoying bluetooth malfunction, especially as iāve fixed an issue similar to this one a month or so ago with just a couple config checks and forum hunts
Ok - problem solved for me - just now! I unplugged the power to my PC for a few minutes and plugged it back in, and now bluetooth works. Credit to @seeji - I thought to try that after reading their comments.
And it somewhat makes sense for me, because something else that correlated yesterday was a very brief power hit due to a storm. I donāt know why it only affected bluetooth, butā¦welcome to the journey I guessā¦
Anyway thanks to the knowledge here, that did it for me. I hope something similar works for you @intc
2 Likes
Oldie but possibility;
On gentoo forums there was mention of this kind of problem. The culprit was connmanctl instead of kernel.
Arch forums have quite a long thread about the same intel chipset. A quick read seems to point towards the same cold boot & new firmware as a fix.
On my Asus, power had to be off with the charger unplugged for 5min+ for it to work.
Even when bluez and bluez-utils are up to date Iād do remove & reinstall on 'em just to be sure and weed out any possible altered configurations as a culprit.
3 Likes
thanks again; will reboot and check back in a few!
this feels like my computer played some sort of elaborate practical joke on me, but, yeah, for future web searchers
- try switching the kernel (i am currently back on rt)
1.1 uninstall bluez, bluez-utils, blueman - unplug your machine, shut it down, let cool for about 5-10 minutes
2.1 on boot, reinstall bluez, bluez-utils and blueman - via maÅino propra funkcias!
note for dock users
if you are using a dock, unplug it and press the power button to discharge it a few times. do not place your machine on the dock immediately after everything works again ā let both cool for a bit. otherwise the problem will repeat
thanks @seeji for this unlikely solution, and thanks all!
happy endeavouros day!
2 Likes
I want to add some regarding mac hardware since this solution doesnāt apply for me.
I have 2 imacās running arch and debian both with broadcom chipset. āNo default controller availableā is coming up now and then on the machine that is dualbooting Arch/Debian. Bluetooth is not properly reseted when rebooting/dualbooting for some reason. The machine running only Arch does not have this problem. Booting fine with bluetooth mouse and keyboard (not apple) and works fine with latest kernel.
That said clearing nvram on imac fixes this issue. No need to switch kernel, reinstalling different things etc . You can fix this on macos easy but I donāt have that installed.
Shut down your mac (cold restart) then push on button and hold all together command+option+p+r for 20 sec (WIN-ALT-P-R) on windows keyboard. Let it flash and release when you see bootmanager. That fixes this thing for me. Bluetooth works as normal again.
NOTE: Nvram is then reset to default settings. But the chime volume is set to 70% and on a imac you donāt want that 
Arch wiki 6.5 explains how to mute the chime.
1 Like
Glad you made progress. These kind of issues get my goat. My mind was drifting to the logic of āHow does the Bluetooth Radio know what devices are registeredā. But then it looks like you did the āDid you try turning it off and on againā.
Iām on a thinkpad dock too (99 percent of the time). My dock is not the USB C one.
āprogressā seems to be the best way to define it, because iām back to having the issue again
the āremove bluez, bluez-utils, blueman>shutdown>rest a bit>start back up>reinstall>rebootā process still works out, but not if iām plugged into an outlet, either thru the dock or thru the power outlet, so it is really a fantastic fix, but not the root of the problem
āaannd weāre back!
currently, i can get bluetooth to work through the method described by @seeji, however, it only functions in a session that immediately succeeds the cold boot. if the computer hibernates (whether it is plugged in or not), everything falls back to the issue outlined before.
this is a problem specifically with discovery; i am again able to connect to devices that i have previously found
i am beginning to think that it is somehow unique to my setup (as others facing a similar issue were able to resolve by cold booting)
I had exactly same behaviour on my Asus laptop, sadly.
Cold booting fixed it for that moment, but problem appeares again later.
Sadly I have no idea what fixed it completely. I tried different kernels and also firmware. Tried another distros also and problem replicated itself. Went for gentoo for a while where my self compiled kernel actually worked.
Later switched back to EOS and problem never appeared again.
Im leaning towards it being some weird regression bug which was fixed eventually eith software updates.
Only difference I can think of on gentoo was compiling bt etc into the kernel instead of as a module.
You can find my old topic about this same issue from here Eos forums through my profile.
Try checking firmware updates and maybe even test different kernel versions other than newest and lts via downgrading.
1 Like
Just a thought,
If liveusb works on every bootup without using cold boot between sessions I would consider it to be known working configuration.
Maybe compare its configs and package versions to your system and try replicating them?
Or if yout setup was working earlier and problem appeared with update downgrade to versions before.
2 Likes
So what is the commonality between what Seeji and Intc have with theier setups:
- Same Bluetooth Radio
- Same Desktop
- Same Bluez version
- cold boot works 100% of the time
This bluetooth issue seems to be stuck in my head.
1 Like
BT chipset is different on my other laptop, which exhibited the same behavior. The commonality is that my laptops (AzureWave AW-CB295NF) and @intc 's Intel chipset are combined wifi/bt chips. Problematic behavior seems to be the same.
My problem appeared on kernel 5.16. I havenāt used that laptop for a while, so Iām unsure if this bug has reappeared with the newest software. I may give it a go if I find time for it. Gotta say that seeing this problem again has piqued my curiosity, especially as I donāt have a definite solution which year ago fixed my problem with BT.
My only theory at the moment is that cold booting either resets the bt/wifi chip or mucks about with other parameters associated with it.
@intc When I had this same problem, I also noted the following factors;
These are from a year ago. Iām interested if your system is showing the same behavior.
Ā§ bluetoothctl
[bluetooth]# power on
No default controller available
and
Ā§ systemctl restart bluetooth
systemd[1]: Bluetooth service was skipped because of a failed condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
Also lsmod didnāt find bt anymore even when it was loaded before
Ā§ lsmod | grep bt
Running modprobe loaded modules back but didnāt fix the problem.
I still think this is more related to kernel behavior than bluez.
1 Like
it seems that this could in fact be a kernel issue, however, i have a slightly different situation.
sudo systemctl restart bluetoothworks without a hitchlsmodgives me
[intc@intc-navi ~]$ lsmod | grep bt
btusb 69632 0
btrtl 28672 1 btusb
btbcm 24576 1 btusb
btintel 45056 1 btusb
btmtk 16384 1 btusb
bluetooth 937984 42 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
so i feel that there is some common issue which differs slightly from model to model (could be either bluez or kernel; every time reinstall bluez and cold boot the issue is temporarily fixed). ācuriousā is really the best way to phrase it, which is why i find myself trying to apply different fixes instead of reinstalling the os altogether
iām happy to report that the issue was resolved by a kernel update. so far, everything seems to be functioning as intended, letā's see how the system works after a night in hibernation, but so far so good
6.3.2 bluetoothctl: No default controller available
There is a bug with some motherboard bluetooth controllers. To see if this might be the issue, run journalctl | grep hci. If there are entries like ācommand tx timeoutā or āReading Intel version command failedā, then power off your pc and physically unplug the power cable for a few seconds. This forces the controller to reload the firmware (while a standard reboot will not). See bug report here.
Make sure the device is not being blocked by rfkill.
It might also happen with some intel cards (such as the 8260) to not be picked up correctly by the Bluetooth service. In some cases, using the deprecated bluez-utils-compatAUR in lieu of bluez-utils have reportedly fixed the issue.
This might also be caused by power saving measures, in which case adding the kernel parameter btusb.enable_autosuspend=n is a potential solution. See also Red Hat Bugzilla ā Bug 1573562.
Sometimes unloading and loading btusb without options helps to get the controller back:
# modprobe -r btusb
# modprobe btusb
The above is taken from Arch wiki Bluetooth
If the bluetooth module is loaded correctly there should be folders there. Like mine:
Ī» /sys/class/bluetooth/ ls
hci0 hci0:12
hci0 =controller and hci0:12 = connected device
If firmware is not loaded properly then this folder is empty and bluetooth.service fails. This has to do with the bug described above. One solution might be to shut down/reset bluetooth by a udev rule on hibernation/reboot so it will load the firmware properly when rebooting/resuming. Maybe make a script removing btusb on reboot/hibernation so firmware can load ācleanā when rebooting/resuming. Cold restart will force reloading the firmware. On laptops this will also include removing battery wich is too much work.
You are right. This is an issue with some motherboard bluetooth controllers. Not all. So it seems that there no common solution to this. Some solutions work and some donāt for different systems. For me on a single arch linux system clearing nvram works on a imac. Dualbooting does not work (2 linux systems on my second imac) . It works on first boot but then rebooting into second system and back it doesnāt work. Doesnāt matter wich kernel is running.
UPDATE: Since I posted the above I made a little script unloading btusb module on session ending.
I edited lightdm.conf in /etc/lightdm/ like this:
Under [Seat:*] uncomment this line and add
session-cleanup-script=/PATH/TO/SCRIPT
The script contains only 1 command:
#!/bin/bash
modprobe -r btusb
exit 0
It will be run as root so no sudo.
Same script is executed on the other system on this computer ending session.
I rebooted approx 10 times into both systems and both systems are loading bluetooth correctly and automaticly connects my headset on both systems when turned on. This seems to work for me and my system.
I do not know how to make this work on gdm and sddm.
1 Like
i finally have some time on my hands, will try to test this out tonight and post what happens