Regression: Instant reboot on Core Ultra 7 155U (T14s Gen 5) with microcode 20260811

[galibozek]

Updating intel-ucode to release 20260811 (which bumps revision from 0x28 to 0x2a for file 06-aa-04) causes an immediate hardware reboot during early boot right after selecting the kernel entry in systemd-boot.

No dmesg or kernel crash logs are saved due to the reboot occurring in the early microcode loading phase.

System Info

• Device: Lenovo ThinkPad T14s Gen 5
• BIOS Version: N46ET26W (1.16) (Date: 04/29/2026)
• Embedded Controller (EC): N46HT18W
• CPU: Intel Core Ultra 7 155U (Family 6, Model 170 / 0xAA, Stepping 4)
• Affected Microcode File: intel-ucode/06-aa-04
• Kernel / OS: Arch Linux, kernel 7.1.8-arch1-3
• Bootloader: systemd-boot
• Working Revision: 0x28 (release 20260512)
• Failing Revision: 0x2a (release 20260811)

Steps to Reproduce & Workaround

1. Update intel-ucode to release 20260811.
2. Boot system with initrd /intel-ucode.img configured in systemd-boot.
3. Select kernel entry — system instantly triggers a hardware reboot.
4. Workaround: Downgrading intel-ucode to release 20260512 (revision 0x28) restores normal boot behavior.

Update / Root Cause

Lenovo released BIOS version 1.17 (N46UR12W) on 11 Aug 2026. The changelog explicitly mentions:

- (New) Updated the CPU Microcode to version 0x2a (CPUID: 0xA06A4)

Findings:

1. On BIOS 1.16 (N46UR11W): Early loading microcode 0x2a via initrd causes an instant hardware reset during early kernel initialization.
2. Workaround via dis_ucode_ldr: Adding dis_ucode_ldr to the kernel command line allows the system to boot successfully on BIOS 1.16 even with intel-ucode.img present in initrd, confirming the crash occurs strictly within the OS early microcode loader.
3. On BIOS 1.17 (N46UR12W): System boots normally without issues because microcode 0x2a is already baked into the system firmware.

Updating to vendor BIOS 1.17 works as a permanent fix, but applying early microcode updates via OS initrd on recent prior BIOS releases (like 1.16) should ideally not result in early-boot hardware crashes.

[mrwiora]

Hi!

thanks for writing, as I was - and most probably many others will be affected too.

Device: HP 830 G11
BIOS Version: 01.09.02 Rev.A - no newer version available currently
CPU: Intel(R) Core(TM) Ultra 5 135U
Kernel / OS: 7.1.8-arch1-3
Bootloader: systemd-boot

Problem occured after upgraded intel-ucode (20260512-1 -> 20260811-1)
Microcode version available in BIOS: 0x28

Note for maybe not so experienced users: remove microcode from the /etc/mkinitcpio.conf HOOKS line and rebuild your setup with mkinitcpio -P.

[miegl]

Intel 155H also affected.

[OIRNOIR]

I'm experiencing the same regression on my Novacustom V54TU (which has a Core Ultra 7 155H) with firmware v1.0.1, using systemd-boot. This is the latest firmware available for my device, so no new bios version includes the new ucode.

[alivehamster]

Having the same issue with the intel 185h

[whatdidfoxsay]

same regression here:

Device: Framework Laptop 13
BIOS Version: 03.07 (no update available)
CPU: Intel(R) Core(TM) Ultra 7 165H
Kernel / OS: 7.1.8-arch1-3
Bootloader: GRUB 2.14

Version 20260512-1 is the last stable version for me, upgrading to the latest put me in a series of endless reboots.

[12458]

Same regression on HP Spectre x360 16-aa0xxx with Core Ultra 7 155H (06-aa-04 / 0x000a06a4).

BIOS	HP F.15 (firmware microcode starts at 0x24)
Working OS ucode	20260512 → early load to 0x28
Failing OS ucode	20260811 → early load to 0x2a
OS	CachyOS, linux-cachyos 7.1.8
Bootloader	Limine (mkinitcpio microcode hook / early CPIO)
Disk	LUKS + Btrfs

Symptoms: Selecting the normal kernel entry fails immediately in early boot (no journal/dmesg). Booting a pre-upgrade Snapper snapshot (old initramfs with 0x28) works. Holding/downgrading intel-ucode to 20260512-1 restores main boot.

Matches this issue: OS early-load of 0x2a on firmware that has not yet baked in 0x2a (here BIOS still at 0x24). Same pattern as the Lenovo 1.16 vs 1.17 finding — no newer HP BIOS available here yet that includes 0x2a.

Workaround: IgnorePkg = intel-ucode and stay on 20260512-1 until an OEM BIOS/ME update ships 0x2a.

[zquestz]

Also affected. Here are some specs in case it is helpful.

OS: Arch Linux x86_64
Host: Framework Laptop 13 (Intel Core Ultra Series 1) (A6)
Kernel: Linux 7.1.8-zen1-3-zen
CPU: Intel(R) Core(TM) Ultra 7 165H (12+8+2) @ 5.00 GHz
GPU: Intel Arc Graphics @ 2.30 GHz [Integrated]
Bios: 03.07

[ankavko]

The same crash on: ThinkPad T14 Gen 5
CPU: Intel(R) Core(TM) Ultra 7 155H (12+8+2) @ 4.80 GHz
OS: Arch Linux x86_64
BIOS: N47ET29W (1.18 )

Workaround: downgraded to intel-ucode-20260512-1

[greyltc]

The same crash on: ThinkPad T14 Gen 5
CPU: Intel(R) Core(TM) Ultra 7 155H (12+8+2) @ 4.80 GHz
OS: Arch Linux x86_64
BIOS: N47ET29W (1.18 )

Workaround: downgraded to intel-ucode-20260512-1

Same here. This is the latest available firmware here too.

Strangely though, switching from Arch's official intel-ucode package to intel-ucode-git in the aur solved the issue, even though they both appear to pull what I thought should be the same ucode version.

[slipke]

Same problem

Device: Lenovo ThinkPad P16s Gen 3
BIOS Version: R2DET41W (1.26) (Date: 12/29/2025)
CPU: Intel Core Ultra 9 185H
Kernel / OS: Arch Linux, kernel 7.1.8-arch1-3
Bootloader: grub
Working Revision: 0x28 (release 20260512)
Failing Revision: 0x2a (release 20260811)

Downgrading to intel-ucode 20260512-1 solved it for me.

[Xalphor]

Same here

Device: Lenovo ThinkPad X1
BIOS Version: N3YET83W (1.48 ) (02/04/2026)
CPU: Intel Core Ultra 5 125U
Kernel / OS: Arch Linux, kernel 7.1.7-arch1-1
Bootloader: grub
Working Revision: 0x28 (release 20260512)

Downgrading to intel-ucode 20260512-1 solved it for me too.

[mrwiora]

OK - new users: maybe try to attach to one of the existing findings, so we do not blow up this thread.
I reported the issue to the intel forum too, as there most probably someone from intel will read this: https://community.intel.com/t5/Mobile-and-Desktop-Processors/latest-ucode-update-triggers-hard-reset/m-p/1756394#M89373

Meanwhile I also contacted the maintainer of the package at Arch and he told me that he will monitor that thread here. However as always these intel microcode updates are a blackbox and therefore such things can happen..