Arch Linux User Repository

shim 15.4 requires SBAT. It will not launch EFI binaries without a .sbat section.

shimx64.efi is signed with Microsoft key, they also have a hardcoded Ubuntu key inside. MokManager (mmx64.efi) is signed with Ubuntu's key.

shimx64.efi can launch any EFI binary signed with Microsoft keys.

More information is available on the wiki: Secure Boot#shim.

fbx64.efi scan the ESP for CSV files with bootloader information and adds boot entries to the NVRAM. Read README.fallback.

Alternative signed shim sources:

• Debian shim: https://tracker.debian.org/pkg/shim-signed
• Fedora shim: https://koji.fedoraproject.org/koji/packageinfo?packageID=14502

I am using shim-signed and it works great. My Dell Inspiron 5593 firmware has the Microsoft UEFI CA 2011 certificate enrolled. If I upgrade to Microsoft UEFI CA 2023 will shim-signed continue to work?

Thanks in advance.

Sorry, just forget my about previous comment! I believe it's actually my mistake. 😁 Turns out I have made a change in the script that I wrote perform the whole installing procedure, believing that it was an oversight and changing it was a good idea.

I'll explain it here so that other people making the same mistake can learn from it:

I changed it copy everything from /usr/share/shim-signed/ to my /boot/efi/EFI/<bootloader-name>/ location, instead of online specific files.

And that was not supposed to be done, according to the wiki 🧐:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Set_up_shim

"Note: Make sure you do not copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will not execute grubx64.efi but will appear to fail to work and just reset the machine."

Whoops. Moral of the story: Always read the wiki, also do it again when changing things later. :)

Is this current used version not supposed to work with booting from a USB device? Or am I missing something. I cannot boot GRUB on my USB drive with Secure Boot enabled anymore.

Using this thing in the EFI partition on my laptop and desktop builtin SSD works fine, which proves that for a part things still go actually right.

But on a portable device (on which a maintain a separate Arch installation, a bit like live disk but then actually writable and usable to work on as well) I also used it.

In this way I was nicely able to boot my drive on Secure Boot enabled systems (useful as a way for me to quickly fix problems, and also on systems where Secure Boot cannot be disabled). I sign the actual GRUB binary and kernel with my own keys.

But turns out on the USB device I was still using a Fedora shim from 2022 as it seems. But also from this AUR repo.

There is already a noble package published: http://archive.ubuntu.com/ubuntu/pool/main/s/shim-signed/shim-signed_1.58+15.8-0ubuntu1_amd64.deb

see also https://packages.ubuntu.com/noble/shim-signed

I'm waiting for Ubuntu for publish a new 15.8 amd64 package. I'm assuming it should happen before 2024-04-11 when the Ubuntu 24.04 LTS beta is scheduled.

@nl6720 Would you kindly let us know when the package will be updated? It is currently out of date

Thank you @nl6720 and @solsticedhiver for the response.

Yes I have executed the grub-install command using the helper scripts available in this repository: Aur-secureboot-grub 0.2.3-1 and this script runs without any error and creates the grubx64.efi. The difference I see is that with previous release the command sudo mokutil --list-sbat-revocations returns:

sbat,1,2022052400

grub,2

But, with the present release the output is

sbat,1,2023012900

shim,2

grub,3

grub.debian,4

Which tells me that some thing is amiss with the sbat versioning.

@philch Have you tried to re-install grub? not the package, but the booloader with grub-install .... With the latest grub package installed, of course.

I think I saw a warning about resintalling with a recent grub update (of the package)

Note: I don't use grub as bootloader

Edit: Also, looking at the install file of grub, on can see:

  Grub does no longer support side-loading modules when secure boot is
    enabled. Thus booting will fail, unless you have an efi executable
    'grubx64.efi' with bundled modules

Sorry, I have no idea about GRUB. All I've read about using Secure Boot + GRUB is that it is a pain.