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.
As a non-technical person, someone on Reddit once explained in a way that makes sense to me as an analogy. Say you are on vacation for a week. Over the course of the week you get pretty good at going from point A to point B, and can even take small side trips along the way. But one day you get a little turned around, and you find you can’t get back to where you need to go. But if someone could pick you up and return you to your starting point, you could do just fine going about your business.
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.
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.
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.
You rang?
So… this is Linux… You could try restarting the specific service. If that works. The advice was dumb and it was a software problem.
If it doesn’t, it was some type of weird hardware problem.
In my experience, though simply toggling the antenna (using the gui widget next to the clock, or gui settings-> Bluetooth off) works
You can restart services in Windows too but directing someone who is bad with tech would take too long, so it’s common to tell them to just restart.
Eh, as long as you know the service in question, you can restart it. Windows…. Doesn’t trust the user that much.
This includes the kernel…. No… thst doesn’t end well…
No, you’d tell them to restart a specific service (like print spooler) for whatever issue they’re having and provide a little tutorial with pictures. No guarantee they won’t still fuck up of course.
I once had rsync going and didn’t want to stop it. my xorg somehow died, managed to restart that from ssh keeping the rsync running. had to use something to move the rsyncs to a screen first. kinda cool how you can almost always just restart parts of Linux instead of the whole thing
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.
