Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64498 - [intel-ucode] regression causes lockup on reboot

Attached to Project: Arch Linux
Opened by Andrew J. Hesford (ahesford) - Thursday, 14 November 2019, 16:32 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 09 June 2020, 20:14 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Christian Hesse (eworm)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



intel-ucode 20191113-1 causes a lockup when rebooting a Dell Precision 5820 workstation with an Intel Xeon W-2145 CPU. The system cold boots fine, but once the system is running, a reboot will cause a lockup when the kernel is reloaded. This is a regression from intel-ucode 20190918-1 and affects more than one bootloader and at least the linux, linux-zen and linux-lts kernels.

Additional info:
* package version(s)

Affected version: intel-ucode 20191113-1
Previous working version: intel-ucode 20190918-1

Bootloaders affected: systemd-boot (from systemd 243.78-2), rEFInd (from refind-efi 0.11.3-1)
Kernels affected: linux (, linux-lts (4.19.84-1), linux-zen (

* config and/or log files etc.

No log files are available; the hang occurs before the initcpio can run any hooks.

For systemd-boot, the loader entry is:
title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options root=UUID=[masked] rw
options consoleblank=600
options audit=0

For rEFInd, the loader entry is the default created by refind-install. rEFInd was not configured to load the microcode; it locked up after warm rebooting from an initial boot using systemd-boot that loaded the microcode from a cold boot.

* link to upstream bug report, if any

There does not appear to be a corresponding upstream bug report.

Steps to reproduce:

1. Install any of the kernels listed above (other kernels may be similarly affected).
2. Configure systemd-boot to boot with a loader entry like that above.
3. Install intel-ucode 20191113-1 and make sure systemd-boot will attempt to load the microcode.
4. Cold boot the system; everything should boot as expected.
5. Invoke "shutdown -r now".
6. After systemd-boot selects the kernel, the system should hang on the "SHA256 validated" message.
7. Forcibly power down the system.
8. [In my case, attempted to turn on the system at this point will cause the fans to spin, then the system to immediately shut itself down; powering on a second time will bring up the system as expected.]
9. Replace intel-ucode 20191113-1 with version 20190918-1 and confirm that the system boots and reboots as expected.
This task depends upon

Closed by  Christian Hesse (eworm)
Tuesday, 09 June 2020, 20:14 GMT
Reason for closing:  Fixed
Additional comments about closing:  intel-ucode 20200609-1
Comment by loqs (loqs) - Thursday, 14 November 2019, 18:58 GMT Comment by Andrew J. Hesford (ahesford) - Thursday, 14 November 2019, 19:47 GMT Comment by Andrew J. Hesford (ahesford) - Monday, 18 November 2019, 16:00 GMT
I believe the issue is resolved by replacing the `-w` flag to `iucode_tool` in the PKGBUILD with `--write-earlyfw`; my system has so far survived four warm reboots after making this change and building a new package. Specifically, line 20 of the PKGBUILD should read

iucode_tool --write-earlyfw=kernel/x86/microcode/GenuineIntel.bin intel-ucode{,-with-caveats}/

See for more information.
Comment by Andrew J. Hesford (ahesford) - Monday, 18 November 2019, 17:43 GMT
Mea culpa; this change only serves to break the early initrd, not correct the original issue. Ignore the previous comment.
Comment by Christian Hesse (eworm) - Thursday, 21 November 2019, 09:30 GMT
Pushed intel-ucode 20191115-2 as a workaround, which reverts 06-55-04 to the ucode from 20190918.
Comment by Christian Hesse (eworm) - Tuesday, 09 June 2020, 18:46 GMT Comment by Christian Hesse (eworm) - Tuesday, 09 June 2020, 18:59 GMT