Boruch Baum <boruch_baum@???> writes:
> Though my hardware does include bluetooth capability, I had never
> explicitly asked for any form of bluetooth to be installed on my system,
> and was surprised (puzzled, alarmed, annoyed) to see among my scrolling
> boot messages, a warning that a bluetooth patch was failing to load.
> Looking at 'dmesg' output further showed that the kernel was
> initializing bluetooth components.

[...]

> (the process
> of removing bluetooth was much more involved than I expected, so I
> hadn't been taking notes at that early point).
>
> 3] It was insufficient (but possibly necessary?):
>
> 3.1] create a file /etc/modprobe.d/bluetooth.conf
> #+BEGIN_SRC
> blacklist bluetooth
> blacklist bnep
> blacklist btusb
> #+END_SRC

According to the modprobe.d documentation,

    the blacklist keyword indicates that all of that particular
    module's internal aliases are to be ignored.

This means blacklisting doesn't prevent the module from being loaded, it
should prevents it from being automatically loaded for any feature it
claims to implement. Eg, bluetooth.ko has an internal alias

net-pf-31

and blacklisting it would mean it won't be loaded to provide net-pf-31
just because of the internal alias alone. But if would be loaded if
someone defined an alias

alias net-pf-31 bluetooth

in some other file.

It should be possible to use something like

install bluetooth /bin/true

in a modprobe conf file instead. This should execute the replacement
command (/bin/true) whenever something wanted to load bluetooth without
using -i on the modprobe command line.

[...]

> 3.4] Modify file /etc/default/grub so that the DEFAULT_CMD_LINE includes
> "bluetooth.blacklist=yes". Then run 'update-grub'.

According to modprobe(8), the correct syntax for command-line
blacklisting is

modprobe.blacklist=<module>

ie

modprobe.blacklist=bluetooth

for this case. bluetooth.blacklist=yes would pass a parameter
blacklist=yes to the bluetooth module upon load --- likely not what was
intended.