Bluetooth failed to turn on since yesterday

My Bluetooth won’t turn on. It worked since I installed fedora35 fresh. (No upgrade).
It didn’t start since yesterday (3/11/2022). The switch won’t turn blue.

Fedora 35

🕙 14:56:22 ❯ systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-03-12 14:20:18 PST; 43min ago
       Docs: man:bluetoothd(8)
   Main PID: 1262 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 77032)
     Memory: 1.9M
        CPU: 30ms
     CGroup: /system.slice/bluetooth.service
             └─1262 /usr/libexec/bluetooth/bluetoothd

Mar 12 14:20:18 fedora systemd[1]: Starting Bluetooth service...
Mar 12 14:20:18 fedora bluetoothd[1262]: Bluetooth daemon 5.63
Mar 12 14:20:18 fedora bluetoothd[1262]: Starting SDP server
Mar 12 14:20:18 fedora systemd[1]: Started Bluetooth service.
Mar 12 14:20:18 fedora bluetoothd[1262]: Bluetooth management interface 1.21 initialized

🕙 15:03:21 ❯ rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

🕙 15:09:46 ❯ uname -a
Linux fedora 5.16.12-200.fc35.x86_64 #1 SMP PREEMPT Wed Mar 2 19:06:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

What could be the problem? I ran sudo dnf update everyday.

It worked before the update yesterday, so it seems reasonable that something that was installed/updated yesterday caused the issue.
Try sudo dnf history --reverse to see the list of recorded transactions then use sudo dnf history info <transaction ID> to see what was done within that transaction.

Once you know what was done it should be possible to reverse that change to see if it will fix the problem.
This is from the info about dnf as shown with the info dnf command.

dnf history rollback <transaction-spec>|<package-file-spec>
              Undo all transactions performed after the specified transaction. Uses the last transaction (with the  highest  ID)
              if  more than one transaction for given <package-file-spec> is found.  If it is not possible to undo some transac‐
              tions due to the current state of RPMDB, it will not undo any transaction.

It looks like pipewire was updated recently. I remember having the headset connect/disconnect often.

    Upgrade  pipewire-0.3.48-1.fc35.x86_64                           @updates
    Upgraded pipewire-0.3.47-1.fc35.x86_64                           @@System
    Upgrade  pipewire-alsa-0.3.48-1.fc35.x86_64                      @updates
    Upgraded pipewire-alsa-0.3.47-1.fc35.x86_64                      @@System
    Upgrade  pipewire-gstreamer-0.3.48-1.fc35.x86_64                 @updates
    Upgraded pipewire-gstreamer-0.3.47-1.fc35.x86_64                 @@System
    Upgrade  pipewire-jack-audio-connection-kit-0.3.48-1.fc35.x86_64 @updates
    Upgraded pipewire-jack-audio-connection-kit-0.3.47-1.fc35.x86_64 @@System
    Upgrade  pipewire-libs-0.3.48-1.fc35.x86_64                      @updates
    Upgraded pipewire-libs-0.3.47-1.fc35.x86_64                      @@System
    Upgrade  pipewire-pulseaudio-0.3.48-1.fc35.x86_64                @updates
    Upgraded pipewire-pulseaudio-0.3.47-1.fc35.x86_64                @@System
    Upgrade  pipewire-utils-0.3.48-1.fc35.x86_64                     @updates
    Upgraded pipewire-utils-0.3.47-1.fc35.x86_64                     @@System

I tried to rollback to the previous transaction, but dnf couldn’t do it.

I reboot and I thought to recover a previous version. I changed my mind, and it went to normal boot. The computer made a huge fan noise (not normal because I have be silent wings cool fans) and showed the screen “Do not turn your computer, Fedora is updating”.

I logon and I see the Bluetooth is working again. :dizzy_face:

The update you saw was the “offline” update that they are pushing on us which updates during reboot. It probably did something more with bluetooth as well.
Note that it says the rollback is for everything “after” the selected transaction, so you would have needed to select the previous transaction for the rollback command. It seems to do a rollback ‘to’ the state where that transaction ended.