7 thoughts on - After Update To 8 (2004) … System Is Unbootable – UEFI Secure Boot

• Hi Leon,

  Don’t think that it’s due to secureboot, as on my work laptop (thinkpad t490s), I have secureboot on, and kernel working fine.

  OTOH, on my family laptop (also in secureboot mode), when I updated from
  8.1.1011 to 8.2.2004, laptop became unresponsive during the microcode_ctl update (in scriptlet) and after that it auto-reset itself
  , so in the middle of the whole rpm transaction. I tried to recover it but it was to a point where it was faster to just reinstall from scratch with 8.2.2004, which I did … and in gnome, everything was fine, etc (adding repo, pkgs) but then on the *same*
  kernel it was installed with, just tried a reboot, and nothing : grub shows menu, you select kernel and on upper left there is only cursor
  (fixed) and nothing happens ..

  I’ll try to diagnose what’s the issue as actually that means troubles with family using that laptop :)

• Am 16.06.20 um 22:04 schrieb Fabian Arrotin:

  Hi Fabian,

  an earlyprintk

• I finally had reinstalled the laptop over pxe at home *but* pointing to kickstart repo (so GA content without updates, and so local mirror of http://mirror.CentOS.org/CentOS/8/BaseOS/x86_64/kickstart/), to ensure that microcode_ctl wouldn’t be installed, and in some minutes laptop was back in action. Excluding it from updates and updated the rest and all is ok.

  I’ve seen some people mentioning strange problems like this due to microcode, and it seems Ubuntu even had a second update a in row to fix issues :
  – https://usn.ubuntu.com/4385-1/ (introducing issue)
  – https://usn.ubuntu.com/4385-2/ (fixing the introduced issue)

  All that was reported for CentOS 7 as we had the same issue there too
  (see https://bugs.CentOS.org//view.php?id=17452)

  So for people impacted, I guess we have to wait for a new update to land, and excluding it from updates for now

• Am 16.06.20 um 22:04 schrieb Fabian Arrotin:

  Did you got managed to boot kernel-4.18.0-193.14.2.el8_2 or a newer one?
  I must still boot into kernel-4.18.0-147.8.1.el8_1.x86_64 … and with the upcoming new kernel that depends on a new shim and grub2 package I
  wonder about the implications for my XPS hardware …

• The following article discusses a way to add a hash for older kernels to the Allow List that should allow older kernels to continue to boot:

  https://access.redhat.com/security/vulnerabilities/grub2bootloader

  Quoting…

  Red Hat Enterprise Linux 8

  Due to hardening within the kernel, which is released as part of these updates, previous Red Hat Enterprise Linux 8 kernel versions have not been added to shim’s allow list. If you are running with Secure Boot enabled, and the user needs to boot to an older kernel version, its hash must be manually enrolled into the trust list. This is achieved by executing the following commands:

  # pesign -P -h -i /boot/vmlinuz-

  # mokutil –import-hash

  # reboot

• Am 29.07.20 um 20:54 schrieb Phil Perry:

  Thank you very much, Phil! This helps to boot the old kernel.

  Also the newer kernel-4.18.0-193.14.2.el8_2.x86_64 can not boot on this notebook (Intel i7-8750H (06-9e-0a) / DELL XPS 15 9570).

  I had open a bug report already (not public as usual for kernels)

  https://bugzilla.redhat.com/show_bug.cgi?id=1848743

  Does someone else has this problem?

  —
  Leon

• Am 29.07.20 um 20:43 schrieb Leon Fauster:

  JFYI: latest (kernel-4.18.0-227.el8.x86_64) 8-stream kernel is bootable on this machine … (full updated (C8.2.2004) with latest shim, grub2 stuff. Just the kernel is from 8-stream) …

  —
  Leon