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.

1] The devuan installer shouldn't include bluetooth as a default kernel
module. They can be loaded later, if ever required (My biases against
bluetooth by default are that its a security fright and a needless and
continual power drain).

2] For the default devuan desktop, the reason for bluetooth in my case
seems to have traced back to the 'gnome-orca' screen reader (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

3.2] rmmod -f for each of 'bluetooth', 'bnep', 'btusb', 'l2cap', sco'

3.3] create a file /etc/default/bluetooth
#+BEGIN_SRC
BLUETOOTH_ENABLED=0
#+END_SRC

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

3.5] update-initramfs -u -k $(uname -r) -v

4] What was sufficient (but hopefully unnecessary) to remove the
bluetooth patch message

4.1] manually delete the kernel modules folder
/lib/modules/3.16.0-4-amd64/kernel/drivers/bluetooth. I didn't REALLY
delete it, just moved it to /root/kernel-modules/drivers/.

4.2] lsmod still lists bluetooth

4.3] it was only at this point that it was possible to: modprobe
--first-time -v -r -f bluetooth

5] What was additionally sufficient (but again, hopefully unnecessary)
to permanently remove the modules:

5.1] manually delete (ie move to a backup location) the folders
/lib/modules/3.16.0-4-amd64/kernel/net/bluetooth
/lib/modules/3.16.0-4-amd64/kernel/net/ieee802154

5.2] update-initramfs -u -k $(uname -r) -v

6] This isn't a GOOD solution; it's a barbaric hack that probably won't
survive a system update of kernel modules, unless one 'chmod 000' the
three folders mentioned instead of moving them.

6.1] What I had been expecting to be able to do was simply to blacklist
the modules and update-initramfs. I don't understand why that no longer
works.

6.2] Part of my brain is yelling that this is related to some
requirement or expectation of systemd.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0