[RESOLVED] Keep Bluetooth disabled (rfkill-ed) after hibernate

Which Linux distro are you using?
Arch

Which kernel are you using?
6.11.3-zen1-1-zen

Which BIOS version are you using?
3.05

Which Framework Laptop 13 model are you using? AMD Ryzen™ 7040 Series


I have enabled rfkill-block@bluetooth.service to block Bluetooth automatically on boot. But I also have suspend-then-hibernate enabled, so I am frequently using hibernate. When I resume from hibernate, Bluetooth is enabled again. I saw Bluetooth disabled state not restored when resuming from disk · Issue #3026 · systemd/systemd · GitHub, which links a kernel bug report that seems to suggest it is a BIOS implementation issue, and that bluetooth should stay disabled even after resuming from disk if rfkilled.

Does anyone else have any experience with keeping Bluetooth disabled, especially while using hibernate? Is there a lower level fix for this instead of just making a script that does rfkill block bluetooth both on boot and on resume?

Also, is this the wrong category? It wouldn’t let me choose the “Framework Laptop 13 Linux” category because it kept saying I needed to choose two tags, but I couldn’t choose any second tag or anything after picking “arch” as the first one.

mhh ill test it with bluetooth till tomorrow. at least with wifi it works for me…
i didn’t even setup a service… ill just used the command rfkill block wifi and it even stays this way after full reboots.

Category is good. Are you using Gnome? If so, the way I’ve found to keep Bluetooth off is that at the greeter when signing in, you have to turn off bluetooth there and then. If you do, then it will be remembered and when you reboot or resume from hibernation it will still be off.

Hmm maybe the original cause I thought was wrong. I’m using Hyprland, not a DE like GNOME. It seems like there’s a service (systemd-rfkill) that’s supposed to activate after resume to restore the rfkill state which seems to work now, even from hibernate. I’m not sure what I changed but it works now, and if I look at /var/lib/systemd/rfkill/* it seems to have the right state stored. That answers the question that it is intended behavior for the rfkill state to be restored at boot.

As I’m writing this, I just realized that what happened may have been that I only disabled Bluetooth via blueman, but never rfkill’ed it.
Edit: disabling bluetooth in blueman does rfkill it. Not sure what happened the first time (which made me make this thread). I’ll update later if it happens again and Bluetooth gets enabled.

2 Likes