Bug 2269516 - bluetooth.service becomes unresponsive when disabling the interface while a device is still connected since bluez 5.73
Summary: bluetooth.service becomes unresponsive when disabling the interface while a d...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gopal krishna tiwari
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
: 2277199 (view as bug list)
Depends On:
Blocks: F40FinalBlocker F40FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2024-03-14 11:01 UTC by Fabio Valentini
Modified: 2024-04-25 18:15 UTC (History)
15 users (show)

Fixed In Version: bluez-5.73-2.fc40 bluez-5.73-2.fc38 bluez-5.73-3.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-04-05 23:11:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Fabio Valentini 2024-03-14 11:01:22 UTC
After installing this update on Fedora 39:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-86a6245c69

I have issues with enabling and disabling the bluetooth interface, and with connecting and disconnecting bluetooth devices.

Version-Release number of selected component (if applicable):
works with v20240220
broken with v20240312

I have attempted to verify that the linux-firmware update is the cause of this issue. Downgrading only the firmware packages consistently fixes the issue, and upgrading to the latest version in updates-testing consistently breaks them (I tried three times).

How reproducible:
Always.

Steps to Reproduce:
1. enable bluetooth interface
2. connect device
3. disconnect device or disable bluetooth interface

Actual results:
Things get stuck and the interface can't be re-enabled, devices can't be re-connected.

Expected results:
Interface can be re-enabled and devices can be reconnected.

Additional info:
Intel Corp. AX200 Bluetooth
Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340

Comment 1 Peter Robinson 2024-03-14 11:09:52 UTC
Please actually file some useful details like kernel version, output of relevant HW details (lsusb|grep -i blue) and make/model and things like what devices you are using that have stopped working.

There were no changes to this HW in the release, no Intel bluetooth updates at all, and only iwl9xxx series wifi:

commit 195e420f34c5c029d27ee57c57e3b3a8a164f8c4 (origin/robot/pr-0-1710075315)
Author: Miri Korenblit <miriam.rachel.korenblit>
Date:   Sun Mar 10 14:24:41 2024 +0200

    iwlwifi: update 9000-family firmwares to core85-89
    
    Build number: Core_manual_signed_core85-89
    Revision: 7e3e4b69 (9000, 9260)
    
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit>

diff --git a/WHENCE b/WHENCE
index 1601d798..724117fd 100644
--- a/WHENCE
+++ b/WHENCE
@@ -824,7 +824,7 @@ File: iwlwifi-9000-pu-b0-jf-b0-38.ucode
 Version: 38.755cfdd8.0
 
 File: iwlwifi-9000-pu-b0-jf-b0-46.ucode
-Version: 46.ff18e32a.0
+Version: 46.7e3e4b69.0
 
 File: iwlwifi-9260-th-b0-jf-b0-34.ucode
 Version: 34.ba501b11.0
@@ -833,7 +833,7 @@ File: iwlwifi-9260-th-b0-jf-b0-38.ucode
 Version: 38.755cfdd8.0
 
 File: iwlwifi-9260-th-b0-jf-b0-46.ucode
-Version: 46.ff18e32a.0
+Version: 46.7e3e4b69.0
 
 File: iwlwifi-cc-a0-50.ucode
 Version: 50.3e391d3e.0
diff --git a/iwlwifi-9000-pu-b0-jf-b0-46.ucode b/iwlwifi-9000-pu-b0-jf-b0-46.ucode
index 9af424f1..c9a75fcc 100644
Binary files a/iwlwifi-9000-pu-b0-jf-b0-46.ucode and b/iwlwifi-9000-pu-b0-jf-b0-46.ucode differ
diff --git a/iwlwifi-9260-th-b0-jf-b0-46.ucode b/iwlwifi-9260-th-b0-jf-b0-46.ucode
index 4c2b25e5..dac525a2 100644
Binary files a/iwlwifi-9260-th-b0-jf-b0-46.ucode and b/iwlwifi-9260-th-b0-jf-b0-46.ucode differ



So I am at an absolute loss as to why this could possibly have regressed (and it's working on my AX200 series devices so we need actual details rather than a single line else the report will just be closed.

Comment 2 Peter Robinson 2024-03-14 12:29:09 UTC
Can you also provide output of:

bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# Agent registered
[bluetooth]# list
[bluetooth]# show
[bluetooth]# devices

Comment 3 Peter Robinson 2024-03-14 12:33:00 UTC
Also hardware make/model inc GPU (there's known problems where some GPUs now interfere with some radio frequencies (yes really!)).

Comment 4 Fabio Valentini 2024-03-14 13:11:09 UTC
Sorry - I initially only included steps to reproduce and the packages that were involved in triggering "broken" and "working" behaviour. The requested details should all be included below.

But TL;DR: After trying a dozen more times, I was also able to reprodice the issue with the older linux-firmware (which I was not able to after trying a few times yesterday). I'm not sure why the issue appears to manifest more frequently with newer linux-firmware, but it appears to not be *caused* by the linux-firmware update.

Running "systemctl restart bluetooth.service" hangs for about a minute, but then seems to get things into a working state again. So, this indeed looks like an issue with bluez.

I'm moving this to the bluez component then, and will give +1 karma to the linux-firmware update. Thank you for your help!

================================================================================

My hardware is a WiFi 6 / Bluetooth combo on my motherboard (ROG Strix X570-E Gaming). This includes an external antenna, so I really hope interference from the GPU should not be an issue. At any rate, I use an AMD Radeon RX 6600 XT GPU.

I don't even need to connect devices to trigger the broken behaviour - just enabling and disabling the bluetooth interface (rfkill?) causes things to get stuck in a weird state. But the device I was using to test things were Pixel Buds Pro bluetooth earbuds, and they were also the reason I noticed stings stopped working.

================================================================================

"Working" state:

$ uname -r 
6.7.9-200.fc39.x86_64

$ lsusb | grep -i blue 
Bus 001 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth

$ bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# hci0 new_settings: bondable ssp br/edr le secure-conn 
[bluetooth]# Agent registered
[bluetooth]# [CHG] Controller B0:A4:60:60:13:2C Pairable: yes
[bluetooth]# list
Controller B0:A4:60:60:13:2C neptune [default]
[bluetooth]# show 
Controller B0:A4:60:60:13:2C (public)
	Manufacturer: 0x0002 (2)
	Version: 0x0b (11)
	Name: neptune
	Alias: neptune
	Class: 0x00000000 (0)
	Powered: no
	PowerState: off-blocked
	Discoverable: no
	DiscoverableTimeout: 0x000000b4 (180)
	Pairable: yes
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0549
	Discovering: no
	Roles: central
	Roles: peripheral
Advertising Features:
	ActiveInstances: 0x00 (0)
	SupportedInstances: 0x0c (12)
	SupportedIncludes: tx-power
	SupportedIncludes: appearance
	SupportedIncludes: local-name
	SupportedSecondaryChannels: 1M
	SupportedSecondaryChannels: 2M
[bluetooth]# devices 
Device 74:74:46:1B:B5:6F Pixel Buds Pro

================================================================================

"Broken" state: I can't reactivate the bluetooth interface (either via UI or "rfkill unblock bluetooth").

$ uname -r 
6.7.9-200.fc39.x86_64

$ lsusb | grep -i blue 
Bus 001 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth

$ bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# list 
[bluetooth]# show 
No default controller available
[bluetooth]# devices 
No default controller available

quit

This hangs for a while after "Waiting to connect to bluetoothd" and then exits.

The only way to get bluetooth.service out of this unresponsive state seems to be "systemctl restart bluetooth.service".

Comment 5 Peter Robinson 2024-03-14 13:57:02 UTC
> I'm moving this to the bluez component then, and will give +1 karma to the
> linux-firmware update. Thank you for your help!

"rpm -q bluez" too please :)

> My hardware is a WiFi 6 / Bluetooth combo on my motherboard (ROG Strix
> X570-E Gaming). This includes an external antenna, so I really hope
> interference from the GPU should not be an issue. At any rate, I use an AMD
> Radeon RX 6600 XT GPU.

These days and with some of the issues I see I no longer rule anything out with the Linux bluetooth stack (you're standing on one foor while testing right? ;-)

> I don't even need to connect devices to trigger the broken behaviour - just
> enabling and disabling the bluetooth interface (rfkill?) causes things to
> get stuck in a weird state. But the device I was using to test things were
> Pixel Buds Pro bluetooth earbuds, and they were also the reason I noticed
> stings stopped working.

OK, this is starting to make some level of sense, the latest bluez update does have a bunch of work around LE Audio which I think, but aren't certain. Will wait to hear which version of bluez.

> $ bluetoothctl 
> Waiting to connect to bluetoothd...[bluetooth]# list 
> [bluetooth]# show 
> No default controller available
> [bluetooth]# devices 
> No default controller available

Is there anything notable in dmesg?

Comment 6 Fabio Valentini 2024-03-14 14:08:28 UTC
> "rpm -q bluez" too please :)

I had this update installed:
bluez-5.73-1.fc39.x86_64

And now I downgraded to:
bluez-5.72-1.fc39.x86_64

Since I need bluetooth audio to work reliably today.

> Is there anything notable in dmesg?

Not as far as I can tell ... looking at "journalctl -x -b -k" (and "-b -1", "-b -2", "-b -3", for the last four boots) there don't seem to be any kernel messages related to Bluetooth after successful boot and device initialization, except for connection events like these:

kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31

Comment 7 Peter Robinson 2024-03-14 14:20:10 UTC
> And now I downgraded to:
> bluez-5.72-1.fc39.x86_64
> 
> Since I need bluetooth audio to work reliably today.

And it works with 5.72?

> kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
> kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31

hmm, we have issues with a subset of mice with 5.73 so I wonder whether there's some general regression around some form of input over bluetooth.

Comment 8 Fabio Valentini 2024-03-14 14:36:29 UTC
I cannot reproduce the "bluetooth.service becomes unresponsive" issue with 5.72.

I tried turning on bluetooth, connecting headphones, disconnecting headphones, turning off bluetooth, over half a dozen times, and I cannot get into the "broken" state.

The only kernel messages are:

kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input32
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input33
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input34
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input35

Each line happened a second or two after the earbuds got connected successfully.

I'm not sure why they get assigned to a new input device every time, but this doesn't seem new (happens both with bluez 5.73 and 5.72).

Comment 9 Fedora Update System 2024-03-18 19:55:03 UTC
FEDORA-2024-426ecf1fd0 (bluez-5.73-2.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-426ecf1fd0

Comment 10 Fedora Update System 2024-03-18 19:55:05 UTC
FEDORA-2024-1ad45eaec7 (bluez-5.73-2.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ad45eaec7

Comment 11 Fedora Update System 2024-03-19 01:55:04 UTC
FEDORA-2024-f219b6c25c has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f219b6c25c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f219b6c25c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2024-03-19 02:06:02 UTC
FEDORA-2024-426ecf1fd0 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-426ecf1fd0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-426ecf1fd0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2024-03-19 03:15:24 UTC
FEDORA-2024-1ad45eaec7 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1ad45eaec7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ad45eaec7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Dimitris 2024-03-22 22:28:27 UTC
I just realized I can reproduce part of this - the "bluetoothd stuck when disabling BT from GNOME menu" part - with any device I could quickly get my hands on and connect.

Upstream bug with what appears a revert of a single commit that fixes this: https://github.com/bluez/bluez/issues/785 but I'm not aware of the ramifications of that revert.

My adapter is and AMD-branded Mediatek RZ616 on a Framework 13 AMD laptop:

Bus 001 Device 004: ID 0e8d:e616 MediaTek Inc. Wireless_Device

Workstation/GNOME/Wayland on 6.7.10-200.fc39.x86_64.

Comment 15 Fedora Update System 2024-03-23 00:41:02 UTC
FEDORA-2024-f219b6c25c (bluez-5.73-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fabio Valentini 2024-04-01 07:07:14 UTC
Issue was not fixed by this update. Upstream ticket https://github.com/bluez/bluez/issues/785 contains more info why the "fix" was not sufficient.

Comment 17 Fedora Blocker Bugs Application 2024-04-01 16:36:45 UTC
Proposed as a Blocker and Freeze Exception for 40-final by Fedora user decathorpe using the blocker tracking app because:

 The update to bluez introduced an issue where all interactions with bluetooth hardware (including all GUI related to bluetooth  in GNOME Settings and GNOME Shell) becomes unusable in a common circumstance - disabling the bluetooth interface while there is still a device connected.

Since bluez 5.73, disabling the bluetooth interface (either via GUI or via "rfkill block bluetooth") causes bluetooth.service to enter a busy loop, consuming 100% CPU, and becoming unresponsive. Only restarting bluetooth.service or rebooting recovers the bluetooth interface.

The linked bugzilla contains more information (and links to the upstream bug report). The bluez 5.73-2 build in Fedora includes a path that was supposed to fix this issue, but it did not. The bug is also still not fixed upstream, though there seem to be proposed "complete" fixes in the GitHub issue (either applying more fixes or reverting a problematic commit that was introduced between bluez 5.72 and 5.73).

I don't see a dedicated release criterion for Bluetooth functionality, but I think this bug still qualifies (if not, I will propose it as a FESCo blocker). It causes a default service to lock up in a very common scenario, causing issues with the "rfkill" command and all GNOME GUI for bluetooth settings (including gnome-shell and gnome-settings - which become basically unusable as soon as all actions related to bluetooth start to time out). Currently the only known "fix" to restore bluetooth functionality once bluetooth.service enters this infinite loop is to restart the service on the terminal or to reboot.

The update to bluez 5.73 is only stable in Rawhide and Fedora 40, but is still in "testing" in Fedora 39 and 38 due to -1 or insufficient +1 karma votes.

Comment 18 Bojan Smojver 2024-04-03 00:59:03 UTC
Any chance of getting a -3 build with the patch from https://github.com/bluez/bluez/issues/785#issuecomment-2023805345 included, to see whether that fixes the problem for good?

Comment 19 Peter Robinson 2024-04-03 01:03:41 UTC
(In reply to Bojan Smojver from comment #18)
> Any chance of getting a -3 build with the patch from
> https://github.com/bluez/bluez/issues/785#issuecomment-2023805345 included,
> to see whether that fixes the problem for good?

When it's upstream as a commit that's been accepted sure.

Comment 20 Fedora Update System 2024-04-03 01:38:08 UTC
FEDORA-2024-1ad45eaec7 (bluez-5.73-2.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 21 Dimitris 2024-04-03 05:36:01 UTC
I've created a PR upstream (https://github.com/bluez/bluez/pull/802).  I'll be the first to admit that this is a bit of a blind revert of a single commit, but I have run this for days of active BT use (mouse, headset) and it has completely resolved this issue for me.

Comment 22 Dimitris 2024-04-03 17:07:41 UTC
Looks like github PRs are not accepted, I'll have to send patches on the bluez list instead.  It'll be a little while until I have time to do this (set up email account for this - no way I'm storing "real" email credentials in plaintext on disk for git send-email, etc).  Given F40's timelines, if maintainers are already set up and have time to shepherd this to the list, feel free to do so.

Comment 23 Fabio Valentini 2024-04-03 17:17:35 UTC
(not fixed by the f38 update, still present in Fedora [38..=41])

Comment 25 Dimitris 2024-04-03 21:06:13 UTC
Fedora-specific: I've tested this locally under two package builds, both of which address the issue and don't appear to cause any other problems for me:

- upstream master/HEAD as of today plus the patch above.
- 5.73 with *only* the patch above, ie. I removed device-fix-device_is_connected-checking-for-services.patch from the spec.

Comment 26 Dimitris 2024-04-03 21:09:05 UTC
Apologies about the spam:  device-fix-device_is_connected-checking-for-services.patch was removed from the package build in *both* cases I described just now.

Comment 27 Adam Williamson 2024-04-04 06:44:14 UTC
well, upstream master contains 8060d1208673826665b7297c27aa75003521b52a , which is the same as device-fix-device_is_connected-checking-for-services.patch . so...did something else on upstream master since then fix your case?

did you test 5.73 + device-fix-device_is_connected-checking-for-services.patch + your patch?

thanks!

Comment 28 Dimitris 2024-04-04 06:51:28 UTC
IIRC I had conflicts combining device-fix-device_is_connected-checking-for-services.patch with my original fix (which was the revert).  So I had tested 5.73 plus just my revert, and also master plus just my revert.  Both worked for me.

I have since gone with a narrower change which doesn't revert all of the changes of 44d3f67277f83983e1e9697eda7b9aeb40ca231d.  Instead, I refactored what used to be the previous "is it connected" logic and use that only in adapter_remove_connection:

https://github.com/bluez/bluez/issues/785#issuecomment-2036076545

I've so far tested this on top of master and it works for me too.  Haven't tested it backported on 5.73 yet.

Comment 29 Dimitris 2024-04-04 19:10:46 UTC
Upstream has accepted the patch in master.  I've built the package both at master and also at 5.73 with the commit (036583f9bbec8540fbd85b980674aad4916d3093) applied as a patch, and it resolves the issue for me in both instances.

Comment 30 Adam Williamson 2024-04-04 19:26:28 UTC
https://koji.fedoraproject.org/koji/taskinfo?taskID=115887481 is a scratch build with Dimitris' patch applied (thanks!); Fabio, can you try it and report back? I'll also see if it happens to fix the Logitech mouse bluetooth slow-scrolling bug, as that one affects me...

Comment 31 Dimitris 2024-04-04 19:34:00 UTC
Re: slow scrolling, I worked around it before noticing the 100% CPU issue (so no code changes) by blacklisting logitech-hidpp-device:

https://github.com/bluez/bluez/issues/778#issuecomment-2013226643

Crude and avoiding the root cause nodoubt.  Not able to reboot atm to test, but ISTR that the blacklist was still needed even with the CPU patch to restore scrolling sanity.

Comment 32 Adam Williamson 2024-04-04 19:43:00 UTC
yeah, I saw that workaround but it'd be nice if this actually *fixes* it. If not I'll use the blocklist :/

Comment 33 Fabio Valentini 2024-04-04 20:49:05 UTC
Sorry, I can't test this. After upgrading to Fedora 40, my bluetooth hardware stopped working entirely :(

Comment 34 Fabio Valentini 2024-04-04 21:01:26 UTC
Ah, downgrading to a 6.7 kernel fixed bluetooth stuff. So the 6.8 kernel borks my bluetooth hardware. Yay ...

But from some quick testing after booting the last 6.7 kernel I have, it looks like the linked bluez scratch build fixes the issue.

Comment 35 Adam Williamson 2024-04-04 21:38:20 UTC
that other bug is probably https://bugzilla.redhat.com/show_bug.cgi?id=2271784 . kernel 6.8.3 (in testing now) or 6.8.4 (pending) should fix it.

Comment 36 Fedora Update System 2024-04-04 22:09:41 UTC
FEDORA-2024-665e28c0f4 (bluez-5.73-3.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-665e28c0f4

Comment 37 Fedora Update System 2024-04-04 22:09:44 UTC
FEDORA-2024-8d9c6f3fae (bluez-5.73-3.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

Comment 38 Fedora Update System 2024-04-05 01:41:17 UTC
FEDORA-2024-8d9c6f3fae has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8d9c6f3fae`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 39 Fedora Update System 2024-04-05 02:04:03 UTC
FEDORA-2024-665e28c0f4 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-665e28c0f4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-665e28c0f4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 40 Adam Williamson 2024-04-05 19:16:06 UTC
+3 FE in https://pagure.io/fedora-qa/blocker-review/issue/1547 , marking accepted.

Comment 41 Fedora Update System 2024-04-05 23:11:42 UTC
FEDORA-2024-8d9c6f3fae (bluez-5.73-3.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 42 Fedora Update System 2024-04-06 01:42:12 UTC
FEDORA-2024-665e28c0f4 (bluez-5.73-3.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 43 Peter Robinson 2024-04-25 18:15:35 UTC
*** Bug 2277199 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.