[ThinkPad T14 Gen 6 / AMD Strix Point] Boot failure with LUKS on kernels 7.0.7 and 7.0.8 – MT7925 WiFi/BT also broken on 7.0.8

Ask Fedora
, , , , ,
1

System specs

  • Machine: Lenovo ThinkPad T14 Gen 6 (21QJ0063DN)
  • CPU: AMD Ryzen AI 7 PRO 350 (Zen 5, Strix Point)
  • GPU: AMD Radeon 860M (Krackan, chip-ID: 1002:1114)
  • WiFi/BT: MediaTek MT7925 (mt7925e driver, chip-ID: 14c3:7925)
  • RAM: 28 GiB
  • Storage: Micron NVMe 1TB, LUKS2 (aes-xts-plain64, argon2id)
  • Filesystem: btrfs (subvol=@)
  • BIOS: Lenovo R2XET39W v1.19 (2026-03-19)
  • Fedora 44 Workstation, GNOME, X11/Xwayland
  • Secure Boot: enabled

Problem 1 – Kernel 7.0.7: LUKS passphrase rejected at boot

After upgrading to kernel 7.0.7-200.fc44.x86_64, the system fails to boot. The LUKS passphrase prompt appears, but the correct passphrase is rejected every time. The system eventually drops to emergency mode.

Relevant journal output from the failed boot:

systemd-cryptsetup: Failed to activate with specified passphrase. (Passphrase incorrect?)

systemd[1]: Dependency failed for local-fs.target

systemd[1]: Failed to mount boot-efi.mount - /boot/efi

The passphrase is correct – the same passphrase works fine on kernel 7.0.6. The initramfs for 7.0.7 contains correct keymap (KEYMAP=no, XKBLAYOUT=no) and the LUKS header is intact (cryptsetup luksDump shows a single valid keyslot). The issue is reproducible 100% of the time on 7.0.7.

Problem 2 – Kernel 7.0.8: LUKS boots but WiFi and Bluetooth are broken

Kernel 7.0.8-200.fc44.x86_64 successfully unlocks LUKS (passphrase accepted), but after boot the WiFi adapter is non-functional:

ip link shows enp185s0f6: <NO-CARRIER,BROADCAST,MULTICAST,UP>

dmesg shows only two ACPI lines for the WLAN port – no firmware load, no driver init

NetworkManager is running and healthy, but the MT7925 adapter does not initialize. Bluetooth is similarly broken. Both work correctly on kernel 7.0.6.

I applied the workaround amdgpu.dcdebugmask=0x800 (recommended for Strix Point GPU stability) via grubby, but this did not help with the MT7925 issue.

Additional context: offline update mechanism

Both failures may be related to Fedora’s offline update mechanism. In my case, the kernel was installed via dnf5 offline, and the post-transaction dracut regeneration did not run correctly. On kernel 7.0.8, the vmlinuz file was not placed in /boot at all – I had to copy it manually from /lib/modules/7.0.8-200.fc44.x86_64/vmlinuz. The BLS entry in /boot/loader/entries/ was also missing and had to be created manually.

After manually placing all files and regenerating initramfs, 7.0.8 boots – but the MT7925 issue remains.

Current workaround

Locked to kernel 7.0.6-200.fc44.x86_64 via dnf versionlock. System is stable on 7.0.6.

Questions

  • Is the LUKS passphrase rejection on 7.0.7 a known regression on Strix Point / Zen 5 hardware?
  • Is the MT7925 (mt7925e) driver broken on 7.0.8? Other ThinkPad T14 Gen 6 users seeing the same?
  • Is the missing vmlinuz in /boot after offline kernel install a known issue with dnf5 offline on Fedora 44?

Hardware for reference

inxi -Fxxx (abbreviated):

CPU: AMD Ryzen AI 7 PRO 350 (Zen 5, 8c/16t) @ 5.09 GHz

GPU: AMD Radeon 860M (Krackan) – driver: amdgpu

WiFi: MediaTek MT7925 (mt7925e) – pcie: 5 GT/s, chip-ID: 14c3:7925

BT: MediaTek Wireless_Device (btusb) – USB, chip-ID: 0e8d:e025

Kernel: 7.0.6-200.fc44.x86_64 (working)

BIOS: Lenovo R2XET39W 1.19 (2026-03-19)

4

I think one should solve that first, and that using offline update is unrelated.

Can you execute as root:

/bin/kernel-install --verbose \
  add 7.0.8-200.fc44.x86_64 /lib/modules/7.0.8-200.fc44.x86_64/vmlinuz \
  &> /var/tmp/kernel-install-01.log

This is the %posttrans main part of the kernel-core RPM but in verbose mode.
Then paste here this log if not too big, or execute:

  • fpaste /var/tmp/kernel-install-01.log and post the obtained URL.
5

Update: it would be better to call fisrt kernel-install remove.
Thus for example:

entry_type=""
 
/bin/kernel-install --help|grep -q -- '--entry-type=' &&
    entry_type="--entry-type type1" 

/bin/kernel-install --verbose remove 7.0.8-200.fc44.x86_64 $entry_type \
  &> /var/tmp/kernel-install-remove-01.log

/bin/kernel-install --verbose \
  add 7.0.8-200.fc44.x86_64 /lib/modules/7.0.8-200.fc44.x86_64/vmlinuz \
  &> /var/tmp/kernel-install-add-01.log
6

I have the same computer, updated to 7.0.8 this morning and I have no problem with wifi, only difference is I’m on Fedora Silverblue and also I went from 7.0.6 to 7.0.8 skipping 7.0.7.

7

Are you dual booting with Windows? WiFi may get different firmware, including some minimal support at boot time. Try disabling WiFi in Windows just before shutting down. Depending on how you use Fedora, you may prefer running Fedora in WSL.

8

Same here, but still with Fedora 43 (tempted to go to 44 since it WAS my old marshal badge number…044).
Originally had problem updating 7.0.8 while on 7.0.6 (locked-up, corruption, boot failure, etc.) but removed 7.0.8 and 7.0.6, while using 6.19.11 then re-updated 7.0.8 and seems nice and stable.

9

No dual-boot.

10

my system is a triple boot: Ubuntu 24.04lts, Windows 7, and Fedora 43 using ubuntu’s grub bootloader maintained by ubuntu’s Grub-ustomizer.

11

✓ RESOLVED on 7.0.8 – root cause identified

Update: I’ve identified the root causes and kernel 7.0.8 now boots and works correctly on both affected machines.

Machines tested

  • Lenovo ThinkPad T14 Gen 6 (21QJ0063DN) – AMD Ryzen AI 7 PRO 350 (Strix Point), MT7925 WiFi/BT, LUKS2, btrfs
  • HP EliteBook 8 G1i 14 – Intel Core Ultra 7 265U (Meteor Lake), Intel AX WiFi/BT, LUKS2, btrfs

Root cause 1 – Wrong btrfs subvolume name in BLS entry

On both machines, the BLS entry generated for kernel 7.0.8 contained rootflags=subvol=root instead of rootflags=subvol=@. The root subvolume on both systems is named @, so the kernel could not find the root filesystem and dropped to emergency mode.

Fix:

sudo sed -i ‘s/subvol=root/subvol=@/’ /boot/loader/entries/-7.0.8-200.fc44.x86_64.conf

This appears to be a bug in how dnf5 generates BLS entries for btrfs systems where the root subvolume is named @.

Root cause 2 – Missing vmlinuz and initramfs in /boot (Strix Point machine only)

On the AMD/Strix Point machine, the post-transaction scripts did not run correctly after the dnf5 offline kernel install. vmlinuz was not copied to /boot, initramfs was not generated, and the BLS entry was not created at all. This appears specific to LUKS2 systems where the post-transaction environment has limited access.

Fix:

sudo cp /lib/modules/7.0.8-200.fc44.x86_64/vmlinuz /boot/vmlinuz-7.0.8-200.fc44.x86_64

sudo dracut --force --kver 7.0.8-200.fc44.x86_64

MT7925 WiFi and Bluetooth on 7.0.8

After applying the fixes above, both WiFi (mt7925e) and Bluetooth (btusb, 0e8d:e025) work correctly on kernel 7.0.8 on the Strix Point machine. The broken WiFi/BT reported in the original post was a consequence of the boot failure, not a driver regression in 7.0.8.

Regarding kernel 7.0.7

The LUKS passphrase rejection on 7.0.7 remains unexplained. That kernel has been removed and was not retested. It may have been the same subvol bug causing early boot failure before the passphrase prompt, or a separate regression. If anyone has seen this on 7.0.7, I’d be interested to know.

Workaround script

I’ve written a small bash script that automatically checks and repairs vmlinuz, initramfs, and BLS entries for all installed kernels after a dnf update. It also installs as a systemd service that runs at boot. Happy to share if useful.

12

Thought there was finally a kernel 7 stable enough for my triple boot Gateway 475M laptop with Ubuntu 24.04 (sda5), Win7 (sda2), and Fedora 43 (sda7) using ubuntu grub bootloader maintained via ubuntu’s grub-customizer on ext4, not btrfs, partitions for linux and NTFS for WIN7.

BUT, so far the short line of 7.0.X kernels have all failed (bizarre stuff!) - I keep having to go back to my tried-and-true 6.19.11 kernel which is very stable… trying out the newer ones as thay come along.

Example: yestrday after only one day use, using the 7.0.8 kernel trying to run the Fedora VLC (but videos had no video, only sound) when it suddenly froze momentarily, logged me out, so logged back in, relaunched VLC and then a complete lockup a few minutes later requiring holding down the power button and back to booting with 6.19.11 :woozy_face:

BTW: Uninstalled Fedora’s VLC and installed FlatPAK’s VLC and got videos to play ~ nice!