Rocky 9.3, shim-x64, 15.8-2.el9

Regarding the Rocky specific updates Apr 2024, will there be a new bootable ISO on the downloads page, e.g. Rocky 9.3 with the new shim and grub?

1 Like

There are currently no plans to make new ISO’s at this time. If it is found to be required, then we will do so.

The 8.10 and 9.4 betas are currently our focus (which will inevitably come with the updated versions of those packages). If there is found to be a need to recreate the 8.9 and 9.3 ISO’s before the general release of 8.10/9.4, we will create them. We also appreciate any feedback on issues using the current ISO’s, especially if something has gone wrong before then.


Anyone doing a clean install from tomorrow will end up with the old shim, grub etc. Do we know when 9.4 will be available? If it’s any day now, it won’t really matter…

1 Like

I’ve tested the new shim in the context of updating an installed system, but I want to test using bootable media, for example booting from an optical drive on real hardware, because shim works slightly differently from bootable media. I want to simultate a new user trying to install from nothing.

It’s not really practical to create a huge new 9.3 iso when 9.4 is not far off, so maybe I could create a bootable image using files from the installed system, but I don’t know how, maybe dracut (or something)?

1 Like

Logically, Rocky 9.4 will not be released before RHEL 9.4 is out, and RHEL 9.4 is not out yet.

1 Like

I must be missing something or not understanding, but why would that be a problem? You install 9.3 and then just run dnf update and you get the new shim/grub etc.

1 Like

Yes, it’s not a big problem when you already have a working system, but I want to simulate a new user installing onto bare metal to test the shim in the context of bootable media.

1 Like

If you want to create a bootable ISO all by itself, you can use lorax to do this. (The DVD is a different story).

dnf install epel-release -y
crb enable
dnf install mock -y
mock -r rocky-9-x86_64 --init
mock -r rocky-9-x86_64 --install lorax lorax-templates-rocky lorax-templates-generic xorriso
mock -r rocky-9-x86_64 --shell --enable-network --isolation=simple
. . .
lorax --product="Rocky Linux" \
  --version="9.3" \
  --release="9.3" \
  --isfinal \
  --source= \
  --source= \
  --variant="BaseOS" \
  --volid="Rocky-9-3-x86_64-dvd" \
  --buildarch="x86_64" \

This might get you somewhat close. You may have to make some tweaks here and there.

Thanks for the tip about lorax, it’s new to me, so it might take a while to get it working.

1 Like

Unless I’m missing the intent here, could you not download the netinstall media and use that to create a new system using the latest in the Rocky repos? This is how I install all my systems.

1 Like

The intent to to better understand the Apr 2024 updates in relation to shim and grub.

In all cases SecureBoot is ON.

The first thing I tested was using older bootable media on a machine with Rocky 9.3 and the Apr 2024 updates.

Test #1
Rocky-8.5-x86_64-dvd1.iso, FAIL, sbat violation, shim-x64-15.4-2.el8_5.2.rocky.x86_64.rpm

Test #2
Rocky-9.0-x86_64-dvd.iso, FAIL, sbat violation, shim-x64-15.4-2.el9.rocky.1.x86_64.rpm

These two kind of make sense, the shim is older and has been revoked by the new shim.


Test #3
CentOS-8-x86_64-1905-dvd1.iso, able to boot, shim-x64-15-8.el8.x86_64.rpm, but it’s older than Rocky?

Test #4
GParted debian, able to boot, but it’s from 2019, shim-signed-common 1.32+15+1533136590.3beb971-5

How on earch can the original CentOS 8.0 work when it’s much older than Rocky 8.5 and Rocky 9.0, and how can an ancient debian from 2019 still work??

1 Like

In case 1 & 2 you said that Rocky revoked the prior CA certificate, how is that done?

In case 3 & 4 there is no indication that those old certs were revoked so why would they fail?

1 Like

Look at mokutil -X --list-enrolled
Does it list keys?

This is from Alma8 system, for illustration:

# mokutil --pk | grep Subject:
        Subject: C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Platform Key
# mokutil --kek | grep Subject:
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
# mokutil --db | grep Subject:
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
# mokutil --dbx | grep Subject:
# mokutil -l | grep Subject:
        Subject: serialNumber=5561017/jurisdictionC=US/jurisdictionST=Delaware/businessCategory=Private Organization, C=US, ST=Florida, O=AlmaLinux OS Foundation, CN=AlmaLinux OS Foundation
        Subject: C=US, ST=Florida, L=Fort Myers, O=AlmaLinux OS Foundation/serialNumber=5561017, CN=AlmaLinux OS Foundation/businessCategory=Private Organization/jurisdictionST=Delaware/jurisdictionC=US
# mokutil -Xl | grep Subject:

The “pk/kek/db” keys were there from start. The installer must start with something (shim) signed by one of those keys, or it could not boot with Secure Boot on. The “enrolled” keys are from Alma and must have been enrolled by the installer without the manual step that the mokutil --import requires with, for example ELRepo/NVidia/RPMFusion/dkms keys.

Logically, the shim is signed with Microsoft’s key, the kernel with Rocky’s key, and the grubx64.efi probably by Rocky’s key. Naturally, the shim must then contain certificates/revokes that allows it to load the grubx64.efi.

1 Like

The most easy to understand article I can find about this is from ‘suse’.
See Section 2.5 near the bottom of the TOC.

1 Like

So here are some points:

  • Shim gets signed by MSFT , MSFT’s certs are in the firmware, vendors " like rocky " embed a CA cert into shim and generate certs to sign .EFI files such as kernelUKI, grub2, fwupd ,etc…
  • If you are booting older iso with shim and grub2, that should boot as long as the DBX in firmware didn’t get updated " vendors and MSFT didn’t release any dbx update yet to revoke older shim" at least not until the current round of shim reviews, releases is sorted, otherwise, lots of vendors won’t be bootable unless secureboot is disabled
  • You can install from the bootable media, then do dnf upgrade
  • It is not about the “old” shim, it is about the revoked grub2, shim gets revoked from the firmware via DBX updates that includes the CA hash or the shim hash
  • Shim revokes older grub2 " in our case " via the global number generation, current shim 15.8 will revoke any grub < 3 or you can also build a shim dbx to revoke grub with hashes or certs
  • I don’t know which shim centos uses on their bootable images, but I know it is really old, they already have a shim review open to get the new shim signed by MSFT

The issue of releasing new shims and new bootable media is an ongoing issue for vendors and they work it out based on how they see fit. Some vendors won’t even revoke anything via shim itself, but using external method to deliver a revocation mechanism
Hope this explains things a little bit!


My post #11 in this thread shows the shim versions next to each o/s.

1 Like

I don’t know if it’s related, but an upgrade of RHEL 9.3 to 9.4 failed today on VMWare. It won’t boot at all. Could be our VMWare firmware is not right (or something).

It would be good if someone can test upgrading Rocky 9.3 to 9.4 on VMWare with secure boot enabled. But the shim in RHEL might not be identical to the one in Rocky anyway.

RHEL 9.4 works fine for me on VMware 8 Update 2. And this is also with secure boot enabled. Rocky 9.4 is not released yet, so can only be tested properly in due course when it’s released shortly.

Secure boot is one of the many things that we test. One of our testers uses primarily vmware did not report any issues updating, booting, or installing systems.

It turns out the RHEL 9.4 box that failed to boot was caused by a “Crowdstrike” process called “falcon-sensor”, so completely unrelated.

1 Like