Often with a Linux kernel update, or even after a first install of Linux in place of Windows, Bluetooth stops working and the advice is usually to just power off your computer, wait a bit, and then turn it on again. Bluetooth then miraculously works again.
I mean the issue could also come from other things (not starting the right kernel module etc…), but very often it’s just this simple trick that makes it work again.
So what is changing in the Bluetooth device when you do this power off/wait a bit/power on trick?
You’re just trying to get the device into a known good state.
The truth is that it’s rarely worth trying to find the root cause of an issue unless it’s a frequent problem.
Something somewhere went wrong. We don’t know if it’s a hardware or software issue, so we’ll try a solution that covers both.
Powering the device off stops the flow of electricity, and waiting a few seconds makes sure that any capacitors (think of very tiny, very fast batteries) bleed off the power they’ve stored. Then turning it back on makes it go through the full startup process which is likely to result in a working state.
What the asteroid said is 100% true.
I just like to add that when you change system drivers you’re adding a lot of unknown state into the equation, which you don’t have on day-to-day operation. So it’s even less worthwhile to debug what happened. You’re not likely to update drivers everyday.
To be fair, this is a recurring experience on Linux, Mac, and Windows of varying generations of equipment. As an educated guess it seems to be hardware states that cant be reset from software for whatever reason.
Could also be that the Bluetooth kernel module is a loadable one, and if you’ve updated the kernel (which will usually take place pretty soon after a first install) then you won’t have the matching folder of modules to load up until you restart. Arch is a bugger for this - I’ve an external mouse that works fine if you keep it plugged in during a kernel update, but it won’t be recognised after an update until you restart again. Not a big deal - you can choose when to update.
I believe Arch has an optional pacman hook to prevent this.
Not saying this is the answer to your question, but generally, it’s the hardware/software unaccounted-for states that can’t easily be recovered from. So, rebooting would hopefully get it in a known “clean” state, and hopefully, not falling into that unaccounted-for state again.
Shitty, but works with some other things too. Angry, frustrated, hopeless? Sleep it off, maybe (not guaranteed) it will be better tomorrow.
Can’t confirm, but I would assume that there is a capacitor in a few bluetooth modules that keeps some of the components charged, and that they only try to comminicate with the kernel after a power cycle.
