Turn on Bluetooth at system boot

General Discussion
1

For some reason (I am guessing security?), CL does not turn on Bluetooth upon reboot, hence one has to turn Bluetooth on by hand everytime one reboots. Ideally I’d like to make sure that Bluetooth status and connections are restored after reboot: how can that be done please?

I tried sudo systemctl enable bluetooth, but that doesn’t seem to have any effect.

2

Are you trying to use a bluetooth keyboard at boot?

One thought is instead of using systemd is to invoke the kernel driver…

Example:

# Set bluetooth power up
ACTION=="add", KERNEL=="hci0", RUN+="/bin/bluetoothctl --agent menu power on"

This is not a Clear Linux specific example, but a standard linux one.

3

I use a Bluetooth speaker, and I’d like to make sure it re-connects automatically after each reboot. The way things stand right now, I need to manually perform a couple of actions upon each reboot: turn on Bluetooth + connect speaker.

4

@Edwaleni In the example you have given, what configuration file does this go into? In some kind of boot configuration file? Some kind of gnome-session configuration file?

5

I believe I might have found the URL source or related URL source for invoking the Bluetooth start up
linux - Turn on bluetooth on login screen - Unix & Linux Stack Exchange

In this post you modify the /etc/ directory by adding a configuration directory for start up customization.
I have used for setting up network routing on my Clear Linux server.

1 Like
6

The solution given by @Edwaleni is a udev rule. The following snippet creates the directory under /etc if missing. Then, adds a udev configuration file. I verified that /bin/bluetoothctl exists on CL.

sudo mkdir -p /etc/udev/rules.d
sudo tee "/etc/udev/rules.d/bluetooth.conf" >/dev/null <<'EOF'
# Set bluetooth power up
ACTION=="add", KERNEL=="hci0", RUN+="/bin/bluetoothctl --agent menu power on"
EOF
1 Like
7

Though see BlueZ » Blog Archive » Release of BlueZ 5.35. That seems to be favoring the /etc/bluetooth/main.conf method as opposed to “unreliable hciconfig hci0 up commands.”

8

I can attest that the /etc/bluetooth/main.conf method works perfectly.

1 Like
9

AutoEnable is already the default
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/plugins/policy.c#n898

commit 180cf09933b2d8eb03972c8638063429fe5fece5
Author: Luiz Augusto von Dentz <****.***.*****@intel.com>
Date:   Wed Apr 13 15:21:00 2022 -0700

    policy: Change AutoEnable default to true

    This changes the default of AutoEnable to true so controllers are power
    up by default.

    Fixes: https://github.com/bluez/bluez/issues/328

diff --git a/plugins/policy.c b/plugins/policy.c
index 48f5db7d3a6c..0bbdbfc882d8 100644
--- a/plugins/policy.c
+++ b/plugins/policy.c
@@ -892,7 +892,11 @@ static int policy_init(void)
        }

        auto_enable = g_key_file_get_boolean(conf, "Policy", "AutoEnable",
-                                                                       NULL);
+                                                               &gerr);
+       if (gerr) {
+               g_clear_error(&gerr);
+               auto_enable = true;
+       }

        resume_delay = g_key_file_get_integer(
                        conf, "Policy", "ResumeDelay", &gerr);
diff --git a/src/main.conf b/src/main.conf
index 401796235e72..91b98b8c4226 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -276,8 +276,8 @@

 # AutoEnable defines option to enable all controllers when they are found.
 # This includes adapters present on start as well as adapters that are plugged
-# in later on. Defaults to 'false'.
-#AutoEnable=false
+# in later on. Defaults to 'true'.
+#AutoEnable=true

 # Audio devices that were disconnected due to suspend will be reconnected on
 # resume. ResumeDelay determines the delay between when the controller
10

AutoEnable is already the default

Thanks. This is a recent development. That used to not be the case until very recently.

11

@btwarden: Just as an FYI: installed CL 41430 fresh the other day, and AutoEnable is definitely not(!) set by default. /etc/bluetooth/main.conf still needed, as recommended by this.

12

I’m not trying to start a semantics argument, but the literal code path tries to read the config value, and if it can’t read it, explicitly sets it to true. So setting it to true yourself is exactly the same as not setting it. We don’t change that behavior at all.

        auto_enable = g_key_file_get_boolean(conf, "Policy", "AutoEnable",
                                                                &gerr);
        if (gerr) {
                g_clear_error(&gerr);
                auto_enable = true;
        }

If that doesn’t work right, however, there could certainly be some upstream bug, but the code suggests it would be in g_key_file_get_boolean(): Key-value file parser: GLib Reference Manual

13

Thanks. Again, my post was to be understood as an FYI, nothing more. You guys may want to look into it, or you may want to let the GNOME people know that it’s not working. I will attempt to post a bug report in the GNOME forums, though they will very likely reply by asking me to take it up with my distro developer. :nerd_face: