Package Details: shim-signed 16.1+fedora+8-1

Git Clone URL: https://aur.archlinux.org/shim-signed.git (read-only, click to copy)
Package Base: shim-signed
Description: Initial UEFI bootloader that handles chaining to a trusted full bootloader under secure boot environments (prebuilt x64 and AA64 binaries from Fedora)
Upstream URL: https://koji.fedoraproject.org/koji/packageinfo?packageID=14502
Keywords: fbx64 mmx64 MokManager SecureBoot shim shimx64 UEFI
Licenses: BSD-2-Clause
Submitter: nl6720
Maintainer: nl6720
Last Packager: nl6720
Votes: 40
Popularity: 0.126129
First Submitted: 2016-12-07 12:04 (UTC)
Last Updated: 2026-06-11 17:46 (UTC)

Pinned Comments

nl6720 commented on 2021-05-28 11:19 (UTC)

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

nl6720 commented on 2016-12-07 13:17 (UTC) (edited on 2026-06-11 17:47 (UTC) by nl6720)

shimx64.efi is signed with Microsoft key, they also have a hardcoded Fedora key inside. MokManager (mmx64.efi) is signed with Fedora'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.


Known signed shim sources:

Latest Comments

1 2 3 4 5 6 7 Next › Last »

akb825 commented on 2026-06-30 08:00 (UTC)

For the GRUB Windows 11 boot issue, it looks like this is the upstream issue as confirmed by a Debian maintainer: https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items/37 It seems that a new feature in shim triggers the GRUB bug introduced in 2.14. The fix is in Debian, but not in upstream GRUB as of now.

upanther commented on 2026-06-19 06:08 (UTC) (edited on 2026-06-19 06:20 (UTC) by upanther)

Seems the latest shimx64.efi can not boot UKI kernel built by mkinitcpio

  1. Latest mkinitcpio (41-4), systemd (260.2-2) and linux (7.0.12.arch1-1)
  2. I put the /usr/lib/efi/shim/16.1-8/EFI/fedora/{shim,mm}x64.efi to <efi_mount_dir>/EFI/BOOT/ (and the shimx64.efi renamed to BOOTX64.efi)
  3. I put the built UKI kernel to <efi_mount_dir>/EFI/BOOT/grubx64.efi
  4. I have sudo mokutil --disable-validation (when using shim 15.8)
  5. Old shim shim-signed 15.8+ubuntu+1.59-1 works fine.

The EFI screen shows:

Booting in insecure mode
../systemd/src/boot/linux.c:86@load_via_boot_services: Error loading inner kernel with shim: Load error

SuperNinja_4965 commented on 2026-06-13 20:48 (UTC)

@akb825 Doing some research and testing is your issue maybe a GRUB issue rather than an issue with shim? See: https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items/2

akb825 commented on 2026-06-13 08:44 (UTC)

The latest version appears to hang (or crash) when using bootloader chaining with GRUB to dual-boot Windows 11 with secure boot enabled. I created an upstream issue here: https://github.com/rhboot/shim/issues/802

SuperNinja_4965 commented on 2026-06-09 17:03 (UTC)

I'm not sure about any other builds however it appears the latest fedora shim builds are signed with the 2023 cert: https://koji.fedoraproject.org/koji/buildinfo?buildID=2984059 https://kojipkgs.fedoraproject.org//packages/shim/16.1/8/x86_64/shim-x64-16.1-8.x86_64.rpm

SuperNinja_4965 commented on 2026-01-12 02:20 (UTC)

@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

Daktyl198 commented on 2026-01-12 02:07 (UTC)

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?

User00891 commented on 2025-01-15 06:46 (UTC)

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

dino66 commented on 2025-01-10 17:56 (UTC)

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.

adv commented on 2024-08-29 16:29 (UTC)

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.