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.
2 Likes
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=https://dl.rockylinux.org/pub/rocky/9.3/BaseOS/x86_64/os \
--source=https://dl.rockylinux.org/pub/rocky/9.3/AppStream/x86_64/os \
--variant="BaseOS" \
--volid="Rocky-9-3-x86_64-dvd" \
--buildarch="x86_64" \
--rootfs-size=3
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.
BUT.
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?
[EDIT]
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!
3 Likes
My post #11 in this thread shows the shim versions next to each o/s.
1 Like