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

@Daktyl198

I think this message on the debian bug tracker best explains the situation. There will be a new version - just not yet.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112197;msg=10

This package is only signed using the 2011 Microsoft keys, which expire soon. Is there an alternative source that provides one signed using 2023 keys?

@dino66 Got hit by same issue when upgrading systemd. Strange enough downgrading systemd & systemd-libs to 257.2-1 restored correct behavior.

Hi I'd like to discuss this issue I've described here, https://answers.launchpad.net/ubuntu/+source/shim-signed/+question/819989 that is me not able to enroll hashes with mmx because every EFI I try I get a message ~ "EFI not valid (OxE) not found" (see link for the exact error), while I know it is valid because I can use them while SB not enabled. And I'm also quite sure I've able to do it before because I could boot the system at least once before I made an upgrade and broke it. Any help you could give will be appreciated.

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.