How to switch off the bluetooth when the system boots up?
 

Slackware 12.2. Thinkpad X200s.

I have recompiled the kernel 2.6.28.2 and all the bluetooth related drivers were turned off. Now the above messages do not appear in the dmesg. But the bluetooth still on, even if you turn it off from the Windows, once the system boots into linux, the bluetooth switch on. Looks like the slackware boot up scripts checked the hardware and "forgot" to switch it to what it was. Anyone knows what to do.

JR

Hi JR,

Use "chkconfig --list | grep bluetooth" to determine whether or not your system is starting bluetooth services in different runlevels. You want to see output like this:-Which indicates bluetooth isn't started in any of the runlevels.

If it is on, and you want to turn it off, do this:-Hope this helps :)

Slackware doesn't have chkconfig.

Is /etc/rc.d/rc.bluetooth executable?
Does 'sh /etc/rc.d/rc.bluetooth stop' turn it off?
What does dmesg say about bluetooth?

Before I recompiled the kernel, this what I had:

The /etc/rc.d/rc.bluetooth is already set non-executable. But when the system up, the following messages appear in dmesg:

Bluetooth: Core ver 2.13
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized

and then the bluetooth was initialized. I am wandering which start up script runs the "Bluetooth Core".

After the kernel was recompiled, the message disappears, but the bluetooth light still on. And you can check from Windows that the bluetooth was switched on. Even if you turn it off in Windows, once the system boot into Linux, the bluetooth is switched on again.

This is a kernel message: "Bluetooth: Core ver 2.13"
The kernel is activating the bluetooth drivers during initial execution of kernel code. This happens long before the initscripts are run, so the /etc/rc.d/rc.buetooth script has nothing to do with that.
You probably need to either disable bluetooth completely in your kernel or compile it as a module and then blacklist the module so that it does not get automatically loaded.

I was noticing the same thing on my thinkpad t42, and after a little googling, it turns out that as of the 2.6.27 kernel the bluetooth acpi interface has been superseded by the generic rfkill class (hence the inability to compile the thinkpad_acpi extras without rfkill enabled). unfortunately, this leads to bluetooth always being switched on when rfkill is loaded. I haven't found a way to fix it yet, but adding to rc.local will switch it off as the system is going multiuser. It's not ideal, but it'll do the trick until there's a better solution.

Thank you bl0tt0. It works! You know the bluetooth is a power consumer device and it bothered me for a while. Now the bluetooth light turns off.

JR

I got a little script to toogle bluetooth on/off on my t60 with Fn+F5.
I ripped out the bluetooth part from my acpi script here called /etc/acpi/thinkpad.sh thats why i got the case part.

And an event part
/etc/acpi/events/bluetooth

Completely disabling Bluetooth in Slackware.
 

(Even though this is a pretty old thread, I believe I still have something relevant to add to it, so here goes.)

TL;DR.

For those of you who aren’t interested in the detailed explanation below, I attached the bash script ‘disable-bluetooth’ that you can run under Slackware and that will:

• Deactivate Bluetooth on your running system;
• Blacklist the Bluetooth modules, to ensure that Bluetooth will remain deactivated whenever you reboot the system.

Just download the script, remove the ‘.txt’ extension, make it executable and run it as ‘root’ without any command-line parameters.

Introduction.

When you boot Slackware (BTW, I’m running Slackware 14.2), a message such as the following will appear on the boot console:
Furthermore, the kernel will spit out multiple messages relating to Bluetooth—e.g.:
Given that Bluetooth support is set up, the corresponding system class will have been created as well:
Finally, the Bluetooth kernel module will have been loaded, together with the other modules that make up the Bluetooth stack. The precise list of supporting modules will depend on the hardware configuration of the computer, but on my laptop, it looks like the following:
Note that the third column of this output line—i.e., the number “39”—represents the ‘use count’ of the Bluetooth module, and the fourth column lists the ‘referring modules’—i.e., the kernel modules that contribute (possibly multiple times) to the use count. It will not be possible to unload the Bluetooth module, since its use count is greater than zero:
All of the above—the boot console message, the kernel messages, the system class, and the loaded modules—will be gone once you completely disable Bluetooth.

1. Blacklisting the Bluetooth modules, to prevent them from loading at boot time.

If you want to prevent the Bluetooth modules from loading at boot time, then you will have to ‘blacklist’ them. Simply create a blacklist configuration file—e.g., ‘/etc/modprobe.d/blacklist-bluetooth.conf’—that lists the affected modules. To determine the list of the modules that will have to be blacklisted, you will have to look at the output of the ‘lsmod’ command, shown above:
Given this output, the following command will create the appropriate blacklist configuration:
From this point on, Bluetooth will effectively be disabled whenever you boot the system. The boot console message, informing you that the Bluetooth services are getting started, will no longer appear, the kernel messages relating to Bluetooth will be missing, and the Bluetooth system class will not be set up:
In addition, the Bluetooth module and its depencies will not get loaded:
Note, however, that the Bluetooth modules can still be loaded, and the Bluetooth service can subsequently be started, should you ever need it:
It should be noted that, even though the kernel will no longer automatically load the Bluetooth modules, it will still run the ‘/etc/rc.d/rc.bluetooth’ script to start the Bluetooth service. Under Slackware, however, this script will refuse to start the service if the Bluetooth system class, ‘/sys/class/bluetooth’ is missing. Since it is, then, rather pointless to run the script, you may want to make it non-executable:
Do keep in mind, though, that you will, then, no longer be able to run the script manually either. You will, consequently, be unable to start the Bluetooth services unless and until you make the script executable again.

If you want to make sure that the Bluetooth modules will not get loaded, ever, then, in addition to blacklisting them, you can ‘fake-install’ them—i.e., force execution of any arbitrary shell command whenever the kernel is instructed to load the modules. The ‘true’ command is an excellent choice here, since it will effectively perform no operation, and do so successfully.
Thus, to ‘fake-install’ the Bluetooth modules using the ‘true’ command, you can simply add the appropriate lines to the blacklist configuration file:
2. Turning Bluetooth off without rebooting.

To dynamically turn Bluetooth off—i.e., without rebooting—you will have to:

1. Stop the Bluetooth service;
2. Unload the Bluetooth kernel modules.

1. Stopping the Bluetooth Service.

Stopping the Bluetooth service is as simple as running the following command:
2. Unloading the Bluetooth Kernel Modules.

To unload the Bluetooth modules, you will first have to identify them, as follows:
Next, expand this output, to display the details of each of these modules on a separate line:
You can now unload those modules that show a use count of zero:
The ‘modprobe’ command will unload each of the listed modules in turn (provided that their use count is 0, of course), and subsequently unload any further modules for which the use count becomes 0. As a result, after you run the command, there should not be any remaining Bluetooth modules loaded:
Bluetooth will, at this point, effectively be turned off—which you can verify when you attempt to list the Bluetooth system class and find that it no longer exists:
Unless you blacklist the Bluetooth kernel modules, however, Bluetooth will be reactivated when you reboot the system.

Small patch to the 'disable-bluetooth' script
 

Here is a small patch to the ‘disable-bluetooth’ script that I attached to my earlier post.

The patch is needed to make the script work with later Bash versions, such as the one that comes with Slackware-Current. It makes just a one-character modification to the script, in that it replaces a single “@”-symbol with an “*”—which it should have been in the first place. In fact, that the initial, unpatched version of the script ever worked, is caused by a bug in the earlier Bash version under Slackware 14.2. (See the thread “Bash problem with local IFS variable being ignored under Slackware Current” for details.)

Reenabling Bluetooth after disabling it.
 

If you ran the ‘disable-bluetooth’ script to disable Bluetooth and later change your mind, you can easily reenable Bluetooth by running the following two commands (as ‘root’):
From then on, Bluetooth will be activated again whenever you reboot the system.