Score:0

Bluetooth does not work any longer

in flag

Bluetooth has worked on my Lenovo W530 equipped with Xubuntu 20.04. When it worked last, lsusb showed the adapter as

Bus 001 Device 005: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]

but now it is missing in the output of lsusb.

$ sudo systemctl status bluetooth
[sudo] Passwort für verwalter:
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

Nov 15 16:26:49 W530-SSD systemd[1]: Condition check resulted in Bluetooth service being skipped.
$

Looking at /var/log/syslog I found

Nov 15 16:26:49 W530-SSD dbus-daemon[1104]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.39' (uid=110 pid=1406 comm="/usr/bin/pulseaudio --daemonize=no --log-target=jo" label="unconfined")
Nov 15 16:26:49 W530-SSD systemd[1]: Condition check resulted in Bluetooth service being skipped.
Nov 15 16:26:49 W530-SSD pulseaudio[1406]: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.

Since there is something about pulseaudio in the line above the error message and there is another error message related to it below, they all might be in some relationship.

Where exactly can I find more information on which condition check failed such that Bluetooth was skipped and does not work any longer?

How can I remove the obsolete module-rescue-stream from my configuration?

Score:0
in flag

After googeling for this problem I came across similar problem

The most accepted answer there was

sudo apt-get update
sudo apt upgrade
sudo systemctl start bluetooth
rfkill unblock bluetooth

In my case the second statement first did not work on 2 consecutive trials, just telling "Abgebrochen" (stopped) after I had verified that I wanted to install the upgrade. I verified that free space is not an issue, only 14,3 kB had to be upgraded: libssl-dev, libssl1.1, openssl, python3-software-properties, software-properties-common, software-properties-gtk.

When I finally had succeeded with the upgrade, the other two commands went through without producing any output. Bluetooth did not work and lsusb did not show the Bluetooth-adapter.

After one more reboot, lsusb showed the Broadcom adapter:

Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]

The Bluetooth symbol was also present on the task bar again. I was able to transmit some pictures from a mobile phone to my computer.

My main problem is solved, but I do not understand why this fix worked.

However, in /var/log/syslog still appears is a line after the last boot process:

Nov 15 20:57:21 W530-SSD pulseaudio[1830]: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.

that proves that this message had nothing to do with the BT problem.

So I still ask for two explanations:

  1. Why did applying the recipe from the other website work in my case? What has gone probably wrong before?

  2. What do I have to do to fix the cause of the other error message about module-rescue-stream?

in flag
I tried it but it did not work. Even after a reboot, `sudo systemctl status bluetooth` told me `Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: inactive (dead)`. Further `rfkill list` told me about Bluetooth being Soft blocked and Hard blocked!
in flag
Today I found out that as a side effect of renaming `.cashe`, `lsusb` found the Broadcom bluetooth device again. I could also use my bluetooth headphone again after that. - Strange! What might have been an explication for this non-functioning before?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.