On returning to Windows 11 I have also found that my Bluetooth device is non-existent. The situation is the same. I can see the WiFi device of the same MediaTek MT7925 in Windows. But there is no Bluetooth device at all. And the Bluetooth button in the control centre is no longer present.

I would still be looking to the Jun 14 2025 update in Fedora as triggering the issue, as I'm not aware of any other change, but I don't understand enough to say whether this may have triggered a broader issue spanning outside of Fedora.

I don't believe there have been any UEFI changes since the initial Fedora install to change the boot order so that Fedora was and then wasn't the default. But the Bluetooth device worked both sides of any changes. 

Bluetooth is enabled in UEFI.

Driver date for "MediaTek Wi-Fi 7 MT7952 Wireless LAN Card" shows Driver Date: Tue 18/3/24, Driver Version: 5.5.0.3548. It has auto-update enablded in MyASUS, so it would not have been out of date and only recently updated, so no obvious change Windows-side.

I performed a device firmware reset (shutdown and then hold Power for 40 seconds for Asus Zenbook S 16) and then on boot the Bluetooth device is once again recognised in both Windows 11 and Fedora. I will perform mtxxx-firmware update in Software Center again to see if that breaks the Bluetooth device again.

Installed mt7xxx-firmware (installe via Software Center auto-updated). Following restart to update, update automatically installed, restart and boot, Bluetooth remains functional in Fedora.

Seems to be a strong correlation to the MT7xxx-firmware package update now. I was using Windows 11 for some time with no issue. Then decided to boot back to Fedora 42, and on Bluetooth was present. Keyboard did not pair. So restarted and booted back to Windows 11, and again no Bluetooth AT ALL (the entire control centre Bluetooth button is gone, as well as no Bluetooth device in Device Manager, now present in Windows 11). So there seems to be a major issue with MT7xxx-firmware that only presents after 1) update; 2)restart/install, and; 3) restart/boot again. And it's not just impacting Fed 42. Impacting the entire device for all host OS.

This seems irrelevant to the firmware update. This problem has troubled me for a long time, even on old firmware. The Bluetooth interface (via USB) of MT7925 becomes completely unresponsive when running into the problem, and you'll see something like "usb X-Y: device descriptor read/64, error -110" in dmesg. See also https://github.com/openwrt/mt76/issues/548#issuecomment-2767645673

You probably encountered the problem because the power of MT7925 had been kept on for too long (i.e., no cold boot in between). I usually encounter the problem when I keep my laptop on for more than 3 days.

Disclaimer: I don't use Fedora, CentOS, or RHEL.

I have the same experience on RHEL10.1

I found some mistakes in the lspci output. Maybe it's helpful:
root@gergo:/home/gergo# lspci -n -v -s c3:00.0
c3:00.0 0380: 1002:150e (rev c6)
	DeviceName: Mediatek Wi-Fi 7 MT7925 + BT
	Subsystem: 103c:8cdd
	Flags: bus master, fast devsel, latency 0, IRQ 110, IOMMU group 17
	Memory at 5000000000 (64-bit, prefetchable) [size=256M]
	Memory at b4000000 (64-bit, prefetchable) [size=2M]
	I/O ports at 1000 [size=256]
	Memory at b4500000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Legacy Endpoint, IntMsgNum 0
	Capabilities: [a0] MSI: Enable- Count=1/4 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable+ Count=4 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express
	Capabilities: [2a0] Access Control Services
	Capabilities: [2b0] Address Translation Service (ATS)
	Capabilities: [2c0] Page Request Interface (PRI)
	Capabilities: [2d0] Process Address Space ID (PASID)
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [450] Lane Margining at the Receiver
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

root@gergo:/home/gergo# lspci -n -v -s c2:00.0
c2:00.0 0280: 14c3:7925 (rev 01)
	Subsystem: 103c:8c38
	Flags: bus master, fast devsel, latency 0, IRQ 133, IOMMU group 16
	Memory at b4600000 (64-bit, non-prefetchable) [size=2M]
	Memory at b4800000 (64-bit, non-prefetchable) [size=32K]
	Capabilities: [80] Express Endpoint, IntMsgNum 0
	Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+
	Capabilities: [f8] Power Management version 3
	Capabilities: [100] Vendor Specific Information: ID=1556 Rev=1 Len=008 <?>
	Capabilities: [108] Latency Tolerance Reporting
	Capabilities: [110] L1 PM Substates
	Capabilities: [200] Advanced Error Reporting
	Kernel driver in use: mt7925e
	Kernel modules: mt7925e

Additionally, I tried to apply this script (manually): https://github.com/LuanAdemi/mediatek7925e-bluetooth-fix/blob/main/mediatek_fix.sh
But nothing changed. There is my investigation:
root@gergo:/home/gergo# grep -ri 14c3 /usr/lib/udev/hwdb.d/
/usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb:usb:v12D1p14C3*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:0014C3*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:14C35E*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:14C3C2*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001710*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001711*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001713*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000608*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000616*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000717*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00004D75*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007603*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007612*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007615*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007630*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007650*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007662*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007663*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007915*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007916*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007922*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007922sv00001A3Bsd00005300*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007961*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007988*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007990*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007991*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00008650*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v00009005d0000028Fsv00009005sd000014C3*
root@gergo:/home/gergo# grep -ri 7925 /usr/lib/udev/hwdb.d/
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb: ID_MODEL_FROM_DATABASE=MT7925 (RZ717) Wi-Fi 7 160MHz
root@gergo:/home/gergo# vim /usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb
root@gergo:/home/gergo# grep -ri 14C3 /usr/lib/udev/hwdb.d/
/usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb:usb:v12D1p14C3*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:0014C3*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:14C35E*
/usr/lib/udev/hwdb.d/20-OUI.hwdb:OUI:14C3C2*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001710*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001711*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000013F6d00008788sv000014C3sd00001713*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000608*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000616*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00000717*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00004D75*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007603*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007612*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007615*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007630*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007650*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007662*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007663*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007915*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007916*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007922*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007922sv00001A3Bsd00005300*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007961*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007988*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007990*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00007991*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v000014C3d00008650*
/usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:pci:v00009005d0000028Fsv00009005sd000014C3*

I believe this issue is caused by improper USB autosuspend handling. Adding usbcore.autosuspend=-1 to the cmdline seems to be a valid workaround for my device.

https://lore.kernel.org/linux-bluetooth/20250319231235.812700-1-sean.wang@kernel.org/ might fix this. However, the patch is abandoned. I am planning to pick it up and try upstreaming it again. If you are willing to test it and the patch works fine for you, I will include a Tested-by: when I upstream this.

Hint: The original patch has merge conflicts on Linux 6.17+. You may instead try this:

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index a8c520dc09e1..851c2336ae0f 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -620,17 +620,14 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
 
 	if (err < 0) {
 		clear_bit(BTMTK_TX_WAIT_VND_EVT, &data->flags);
-		usb_autopm_put_interface(data->intf);
-		goto err_free_wc;
+		goto err_pm_put;
 	}
 
 	/* Submit control IN URB on demand to process the WMT event */
 	err = btmtk_usb_submit_wmt_recv_urb(hdev);
 
-	usb_autopm_put_interface(data->intf);
-
 	if (err < 0)
-		goto err_free_wc;
+		goto err_pm_put;
 
 	/* The vendor specific WMT commands are all answered by a vendor
 	 * specific event and will have the Command Status or Command
@@ -648,11 +645,11 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
 		bt_dev_err(hdev, "Execution of wmt command timed out");
 		clear_bit(BTMTK_TX_WAIT_VND_EVT, &data->flags);
 		err = -ETIMEDOUT;
-		goto err_free_wc;
+		goto err_pm_put;
 	}
 
 	if (data->evt_skb == NULL)
-		goto err_free_wc;
+		goto err_pm_put;
 
 	/* Parse and handle the return WMT event */
 	wmt_evt = (struct btmtk_hci_wmt_evt *)data->evt_skb->data;
@@ -695,6 +692,8 @@ static int btmtk_usb_hci_wmt_sync(struct hci_dev *hdev,
 err_free_skb:
 	kfree_skb(data->evt_skb);
 	data->evt_skb = NULL;
+err_pm_put:
+	usb_autopm_put_interface(data->intf);
 err_free_wc:
 	kfree(wc);
 	return err;

I'm not tech literate enough to test the patch, but the usbcore.autosuspend=-1 parameter worked for me. Bluetooth and wifi functioning as normal, even with multiple bluetooth devices connected. ASUS Zenbook S16.

Similar issue with MediaTek MT7925 Bluetooth on HP OMEN, but with a key difference:                                                     

  **Environment:**
  - Fedora 43 (KDE Plasma Desktop Edition)
  - MediaTek MT7925 (USB ID: 0e8d:8c38)
  - Firmware: mt7xxx-firmware-20260110-1.fc43

  **Regression confirmed:**
  - Kernel 6.18.9-200.fc43: Bluetooth works ✓
  - Kernel 6.18.10-200.fc43: Bluetooth fails ✗

  **Error:**


  Bluetooth: hci0: Execution of wmt command timed out
  Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
  Bluetooth: hci0: Failed to set up firmware (-110)


  **Key difference from other reports:**
  The workaround `usbcore.autosuspend=-1` does NOT resolve this issue. The firmware loading timeout persists even with USB autosuspend
  completely disabled.

  This suggests there may be a separate regression in kernel 6.18.10 affecting MediaTek MT7925 firmware loading, beyond the autosuspend
  issue described in this bug.

  **Current workaround:** Boot with kernel 6.18.9

Can you verify the firmware versions you are using under each kernel. If the firmware is in the initramfs, it doesn't actually care what is installed on the system. It grabs the one that was installed when the kernel was installed to put in the initramfs created and will use it forever. One kernel can be using a different firmware version than the other.

(In reply to Justin M. Forbes from comment #10)
> Can you verify the firmware versions you are using under each kernel. If the
> firmware is in the initramfs, it doesn't actually care what is installed on
> the system. It grabs the one that was installed when the kernel was
> installed to put in the initramfs created and will use it forever. One
> kernel can be using a different firmware version than the other.

Thank you for you reply.
 **UPDATE:** Problem confirmed to be a kernel regression, not firmware.

  Testing results:
  - Kernel 6.18.9 + firmware 20251021: Bluetooth works ✓
  - Kernel 6.18.9 + firmware 20260110: Bluetooth works ✓
  - Kernel 6.18.10 + firmware 20251021: Bluetooth fails ✗
  - Kernel 6.18.10 + firmware 20260110: Bluetooth fails ✗

**UPDATE - Problem Resolved**                                                                                                           

  Initial report indicated a kernel regression between 6.18.9 and 6.18.10, but further investigation revealed the actual cause was
  different.

  **Environment:**
  - HP OMEN Desktop PC
  - MediaTek MT7925 PCIe (USB ID when enumerated: 0e8d:8c38)
  - Fedora 43 (KDE Plasma Desktop Edition)

  **Root Cause Identified:**
  The Bluetooth failure was caused by:
  1. Downgrading mt7xxx-firmware from 20260110 to 20251021
  2. This caused USB enumeration failure of the internal Bluetooth interface
  3. Device stuck in corrupted state across reboots

  **Symptoms:**
  - WiFi (PCIe interface) continued working normally
  - Bluetooth USB interface failed to enumerate with errors:
    usb 1-12: device descriptor read/64, error -110
    usb 1-12: device not accepting address, error -71
  - No hci0 controller detected
  - Issue persisted even after recreating initramfs

  **Solution that worked:**
  1. Upgraded back to mt7xxx-firmware-20260110
  2. Recreated initramfs for both kernels:
     sudo dracut --force /boot/initramfs-6.18.9-200.fc43.x86_64.img 6.18.9-200.fc43.x86_64
     sudo dracut --force /boot/initramfs-6.18.10-200.fc43.x86_64.img 6.18.10-200.fc43.x86_64
  3. Booted into Windows to allow MediaTek drivers to reinitialize the device
  4. **Complete power cycle: unplugged PC power for extended period**
  5. Rebooted into Fedora

  **Result:**
  Bluetooth now works perfectly on kernel 6.18.10 with firmware 20260110. This was NOT a kernel regression - both kernel versions work
  correctly with the proper firmware version.

  **Key takeaway:**
  For MediaTek MT7925 devices, downgrading mt7xxx-firmware can break Bluetooth USB enumeration and leave the device in a corrupted state.
  Recovery requires:
  - Restoring the correct firmware version
  - Complete hardware reset (power disconnection)
  - Device reinitialization (via Windows drivers or potentially BIOS reset)

  **Workaround note:**
  The `usbcore.autosuspend=-1` parameter mentioned in other comments did not resolve this particular issue, as the problem was at the USB
  enumeration level, not power management.

I found a workaround that reset the bluetooth device. I don't know yet that is temporary or permanent, but it works.

sudo bluetoothctl power off
sudo bluetoothctl power on

Have a nice day!

Please stop posting LLM slop... It's neither correct nor helpful.

(In reply to paddaone from comment #12)
>   **Key takeaway:**
>   For MediaTek MT7925 devices, downgrading mt7xxx-firmware can break
> Bluetooth USB enumeration and leave the device in a corrupted state.

FW downgradation has nothing to do with the issue.

>   Recovery requires:
>   - Restoring the correct firmware version
>   - Complete hardware reset (power disconnection)
>   - Device reinitialization (via Windows drivers or potentially BIOS reset)

Windows/BIOS has zero contribution in the recovery.

The only thing you need is a power cycle.

>   **Workaround note:**
>   The `usbcore.autosuspend=-1` parameter mentioned in other comments did not
> resolve this particular issue, as the problem was at the USB
>   enumeration level, not power management.

Failure in USB enumeration is just the symptom of the issue. The direct cause is MT7925's BTUSB interface being completely unresponsive somehow. In this case, the USB (root) hub can recognize the presence of the USB device but cannot communicate with it at all. The issue really has nothing to do with USB enumeration since it's obvious no one can enumerate an unresponsive device.

Adding `usbcore.autosuspend=-1' without a power cycle won't make it recover. You'll need to make it recover *before* applying the workaround. The workaround aims to prevent it from running into the unresponsive state.

Note that the patch I posted before cannot work around the bug completely -- it just fixes one of the failing points. Disabling USB autosuspend is still required according to my tests.

To correctly reproduce this bug, all conditions below must be met:

1. Keep USB autosuspend enabled, i.e., do not add `usbcore.autosuspend=-1' to cmdline and do not touch `power/autosuspend` via sysfs
2. Keep Bluetooth enabled, i.e., do not disable it via bluetoothctl/rfkill or your fancy DE (otherwise, USB autosuspend remote wakeup will be disabled)
3. Do not connect to any Bluetooth device (otherwise, USB autosuspend won't take effect)
4. Place the laptop in a very noisy environment with a lot of Bluetooth devices (e.g., office, cafe), so that USB autosuspend remote wakeup happens very frequently 
5. Keep the laptop on for a period of time, i.e., disable auto sleep or hibernation 

With all these conditions met, I can reproduce the bug reliably, usually within about 10 hours.

If dynamic debug is enabled (`echo file drivers/usb/core/hub.c +p | sudo tee /proc/dynamic_debug/control'), you should notice this pattern:

[61921.624061] usb 3-5: usb auto-suspend, wakeup 1
[61928.472057] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020
[61928.488322] usb 3-5: usb wakeup-resume
[61928.504100] usb 3-5: Waited 0ms for CONNECT
[61928.504674] usb 3-5: finish resume
[61933.608395] usb 3-5: retry with reset-resume
[61933.728049] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
[61939.104058] usb 3-5: device descriptor read/64, error -110
[....snip....]
[62061.304316] usb usb3-port5: unable to enumerate USB device

Please also note the log line "retry with reset-resume". This meant that the USB core driver could not communicate with MT7925 while handling the remote wakeup irq from the USB (root) hub. Hence, MT7925 was already broken right after emitting the remote wakeup.

The best presumption I can make based on my knowledge and experience is that MT7925 has a broken Bluetooth firmware handling USB autosuspend remote wakeup poorly, and it accidentally breaks the internal HW/FW state machine. AFAICT, all firmware versions have the bug. If you upgraded/downgraded to a specific version and somehow found it "fixes" the issue, it is probably just a coincidence. Sometimes I need to keep the laptop on for a few days until the BTUSB interface becomes unresponsive. So yes, there is some randomness.

(In reply to Gergely Lonyai from comment #13)
> I found a workaround that reset the bluetooth device. I don't know yet that
> is temporary or permanent, but it works.
> 
> sudo bluetoothctl power off
> sudo bluetoothctl power on
> 
> Have a nice day!

For the archive: It has no effect most of the time and doesn't solve the issue. My bluetooth interface periodically and rarely works, but it's independent of my trying and expectation.

Hi,

I wanted to follow up with the result on my side.

I was running CachyOS with kernel 6.19.9-1-cachyos. What worked was doing a full power-cycle
reset and booting with usbcore.autosuspend=-1.

In my case, I had to physically unplug the computer from the power cable. Simply shutting it
down and turning it back on without unplugging was not enough.

Thanks everyone.

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.