New key signed boot entries not appearing

TheWallaby · 2026-07-17 03:24:57

Problem

I finally decided it was time to implement secure boot into my bootloader, so I spent the day following the wiki to try and create a secure boot entry. However, I have encountered an issue where my created entries disappear after reboot.

Process

1. chroot into system

# Mount partitions
mount -o noatime,rw,compress=lzo,space_cache=v2,subvol=@ /dev/sda6 /mnt
# Mount every subvolume ...
mount -o rw /dev/sda5 /mnt/boot/
arch-chroot /mnt

The /boot/EFI/Arch directory already has the BOOTx64.efi and mmx64.efi files

2. Create grub file and sign it

# Modules in the env var
GRUB_MODULES = "all_video
..."
grub-install --target=x86_64-efi --efi-directory=/boot --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv --bootloader-id=Arch
sbsign --key MOK.key --cert MOK.crt --output /boot/EFI/Arch/grubx64.efi /boot/EFI/Arch/grubx64.efi

3. Add shim boot entry (Fallback? Not sure if it is neccesary)

efibootmgr --unicode --disk /dev/sda --part 5 --create --label "Shim" --load /EFI/Arch/BOOTx64.efi

4. Reboot to firmware and turn on/don't turn on secure boot

5. No entry present either way, efibootmgr reports no entry present either

Last edited by TheWallaby (2026-07-17 06:36:19)

cryptearth · 2026-07-17 05:12:39

is this a laptop?

TheWallaby · 2026-07-17 06:37:34

No. It is a tower with a MSI MAG Z790 Motherboard.

cryptearth · 2026-07-17 10:11:20

hm, aside from the usual "check for latest bios update" msi is usually rather easy to work with using custom keys and such - not sure how about stock keys
anyway: msi uefi usually boot entries at POST and remove non existing ones
so when after reboot no entry exist this hints to the uefi wasn't able to verify its existence and hence kicked it from the list
this could either be due to bad path - or that the drive wasn't yet up during POST (unlikely as it worked before - secure boot shouldn't interfere with that)
when you retry verify the entry with efiboitmgr before reboot

when in doubt: kill the power of the entire system (unplugging everything) for a minute or two - or reflash bios

dimich · 2026-07-17 10:52:04

Can you configure boot entries from BIOS Setup?

dimich · 2026-07-17 10:57:43

TheWallaby wrote:

sbsign --key MOK.key --cert MOK.crt --output /boot/EFI/Arch/grubx64.efi /boot/EFI/Arch/grubx64.efi

Doesn't this corrupt EFI binary? I doubt sbsign can update image in place.
If you want to keep filename unchanged, try

sbsign --key MOK.key --cert MOK.crt --output /boot/EFI/Arch/grubx64.efi.tmp /boot/EFI/Arch/grubx64.efi && mv /boot/EFI/Arch/grubx64.efi.tmp /boot/EFI/Arch/grubx64.efi

UPD: according to sources, sbsign loads input image entirely into memory first, so in-place signing should work fine. Nevermind.

Last edited by dimich (2026-07-17 13:10:33)

TheWallaby · 2026-07-17 16:02:38

cryptearth wrote:

hm, aside from the usual "check for latest bios update" msi is usually rather easy to work with using custom keys and such - not sure how about stock keys
anyway: msi uefi usually boot entries at POST and remove non existing ones
so when after reboot no entry exist this hints to the uefi wasn't able to verify its existence and hence kicked it from the list
this could either be due to bad path - or that the drive wasn't yet up during POST (unlikely as it worked before - secure boot shouldn't interfere with that)
when you retry verify the entry with efiboitmgr before reboot
when in doubt: kill the power of the entire system (unplugging everything) for a minute or two - or reflash bios

This gives me a chance to clarify some things, might help solve it too.
I am using a dual boot system, should I be using "custom keys" or the provided platform keys? Does that change the processes I should be using?
Also, I have tested if they persisted before rebooting, efibootmgr seems to recognize the entries before rebooting, but they disappear after reboot.
I took your suggestion, so I tried flashing the BIOS and redoing the process.
BIOS flash went fine, I was on the latest version already.
Seems the same issue keeps happening, they appear before I reboot, but disappear from the boot menu after I reboot.

TheWallaby · 2026-07-17 16:03:38

dimich wrote:

Can you configure boot entries from BIOS Setup?

I can change the boot order and disable certain entries on any disk I please, but I can not do much else.

TheWallaby · 2026-07-17 16:13:48

dimich wrote:

TheWallaby wrote:
sbsign --key MOK.key --cert MOK.crt --output /boot/EFI/Arch/grubx64.efi /boot/EFI/Arch/grubx64.efi
Doesn't this corrupt EFI binary? I doubt sbsign can update image in place.
If you want to keep filename unchanged, try
sbsign --key MOK.key --cert MOK.crt --output /boot/EFI/Arch/grubx64.efi.tmp /boot/EFI/Arch/grubx64.efi && mv /boot/EFI/Arch/grubx64.efi.tmp /boot/EFI/Arch/grubx64.efi 
UPD: according to sources, sbsign loads input image entirely into memory first, so in-place signing should work fine. Nevermind.

Just to be sure, I added this to the script. Probably best to do anyway.

cryptearth · 2026-07-17 18:05:19

sanity check:
- https://wiki.archlinux.org/title/Dual_boot_with_Windows
- part 5 hints towards a second ESP
- disable secure boot
- install grub but don't sign it
- don't add shim
- reboot and check
- if grub is still present: sign it and reboot again
- if it's still there: the issue is not the signing but seems rather the verification when secureboot is enabled
- reenable secureboot and only add shim
- reboot
- check whether shim entry is still there
- if not: something seems to go wrong when secureboot is enabled - COULD be an issue with second esp
-> search for "Install Windows - the Arch way" by Chris Titus - the idea is pretty much the same as with arch: pre-partition the drive yourself, use dism to unpack the install.wim (equivalent to pacstrap), use bcdboot to install windows bootloader (equivalent to install grub)

i suspect an issue that secureboot might could go haywire due to the second esp on the same drive - but just an idea

TheWallaby · 2026-07-17 19:56:32

cryptearth wrote:

- part 5 hints towards a second ESP

The first 4 are windows partitions. I originally used that to house my linux esp as well, but I don't use that method anymore, part 5 is a 1G esp for the Linux system
Usually os-probe reads that /dev/sda4 is the windows esp and adds it as an entry to grub

I followed your advice and did the following:
I disabled secure boot and ran a normal grub install, did not work
On the second run, I added the --removable option to grub install, since I remember having a similar issue when doing my fresh install ~1 year ago (Something to do with my SATA SSD?)
The new option worked and the non signed boot entry reappeared properly as "UEFI OS" in my BIOS
After I adjusted the script to use --removable and the now needed "/boot/EFI/BOOT" directory instead, which required some changes to the script:

GRUB_MODULES="..."
EFI_DIR=/boot/EFI/BOOT/
grub-install --target=x86_64-efi --efi-directory=/boot --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv --bootloader-id=Arch --removable
sbsign --key MOK.key --cert MOK.crt --output $EFI_DIR/grubx64.efi $EFI_DIR/BOOTX64.efi
cp /usr/share/shim-signed/shimx64.efi $EFI_DIR/BOOTx64.efi
cp /usr/share/shim-signed/mmx64.efi $EFI_DIR/
efibootmgr --unicode --disk /dev/sda --part 5 --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

After turning secure boot on, I was able to open the entry "Shim", which brought up grub.
Before grub appears, it has this error it prints to the screen

error: kern/efi/sb.c:shim_lock_verifier_init:177:prohibited by secure boot policy.

When pressing then Arch entry it reports this error

Loading Linux linux ...
error: kern/efi/sb.c:shim_lock_verifier_write:200:bad shim loader signature.
Loading initial ramdisk ...
error: loader/i306/linux.c :grub_cmd_initrd:1002:You need to load the kernel first

The other boot entries in the grub menu hang and do not boot/report any errors
I assumed this meant that the kernel image needed to be resigned, so I went back in with the archiso and ran mkinitcpio -P to rebuild it
It says the file was already signed, so I assume that it's not that, and I try to run grub-mkconfig -o /boot/grub/grub.cfg
After reboot same issue occurs.
Let me know if that gives any hints as to what I should do, otherwise i'll keep following the instructions you gave.

Last edited by TheWallaby (2026-07-17 20:26:10)

cryptearth · 2026-07-18 02:28:55

we closing in: you seem to have not enrolled you custom MOK into your uefi - hence shim fails to verify it (which makes sense as you mentioned you reflashed your bios - which likely removed your MOK if you had previously enrolled it)
according to the wiki this is where mok-manager should start to allow you to either enroll the hash or the key used to sign

https://wiki.archlinux.org/title/Unifie … _Boot#shim
and as you use grub
https://wiki.archlinux.org/title/GRUB#Shim-lock

unfortunately this is pretty much where my ability to help ends as i have quite my own view of secureboot
as for why --removable works: i highly suspect your uefi gets confused by the second esp in combination with secureboot - wonder how/why it worked before you started looking into securebokt - maybe some conincidence

TheWallaby · 2026-07-18 03:12:20

cryptearth wrote:

we closing in: you seem to have not enrolled you custom MOK into your uefi - hence shim fails to verify it (which makes sense as you mentioned you reflashed your bios - which likely removed your MOK if you had previously enrolled it)
according to the wiki this is where mok-manager should start to allow you to either enroll the hash or the key used to sign
https://wiki.archlinux.org/title/Unifie … _Boot#shim
and as you use grub
https://wiki.archlinux.org/title/GRUB#Shim-lock
unfortunately this is pretty much where my ability to help ends as i have quite my own view of secureboot
as for why --removable works: i highly suspect your uefi gets confused by the second esp in combination with secureboot - wonder how/why it worked before you started looking into securebokt - maybe some conincidence

That was the part I was missing, I had secure boot on "Custom" and "OS compatibility" mode, so it didn't work, I set it to back to standard secure boot, it brought up MOK and I used the MOK.cer file to verify it.
Thanks for you help! Also, I will likely not fix the esp, I am hoping to transfer this install to a nvme in the future with only linux, so hopefully that won't be an issue anymore.
While that fix worked initially, it broke after updating the secureboot dbx from lvfs with fwupdmgr, not sure if that is intended, and it seems the bug is caused by upstream changes to grub, or maybe because shim isn't signed with the new key?

Last edited by TheWallaby (2026-07-18 15:29:53)

cryptearth · 2026-07-18 08:03:45

what exactly was updated and what exactly stopped working?
from what i remember the only thing that fwupdmgr ever updated on my system was the DBX - that's the bad-list of secureboot and usually contains a list of hashes of known bad bootloaders - either withdrawn by devs due to bugs or blocked because some hacker got a valid signature on a modified build

let's work this step by step:
- after reflash you bios it usually should default to be set to Windows-Secureboot mode with the oem hardware key and microsofts keys loaded (with recent versions this should already include microsofts new keys as the old ones ran out); in this state a current version shim + mok-manager should work out of the box ready to both enroll a custom bootloader hash or a mok
- you mentioned that when you checked the secureboot setting was something different ... as i only ever played around with stock keys for a regular windows only install and once with custom keys the only time i encountered mok and mok-manager was when i was on suse and did a bios update as suse has thier own set of keys signed by m$ so the grub they ship thier install iso with usually works with stock m$ keys; tl,dr: i'm not sure what difference that other setting made that shim not has started mok-manager
- you switched it back to Windows and shim did what it's supposed to: start mok-manager to let you deal with grubs signature
- then you ran an update that updated one of the secureboot databases and now it stopped working

this leads me to:
- either for some reason the key that shim is signed with is no longer part of this updated db
- or the current shim hash was added to the dbx for some reason and is actively blocked
- or the db got so large it doesn't fit in your boards nvram and something got somehow corrupted

as mentioned before: this is where my knowledge ends and hence i can only guess without actual helping - sorry
maybe someone else can takeover from here?

TheWallaby · 2026-07-18 20:01:53

I have been trying some stuff, here's what Ive tried.
Also, for clarification, It did update my dbx, it has new signatures
1. Delete the key using mokutil ---delete /boot/MOK.cer
Result: mmx64.efi brought back up, still doesn't work after reboot though, and yes, it was listed for deletion in mokutil --list-deleted
2. See listed keys using mokutil -l
Result: There's an entry for ventoy, one issued by xecurity@rockylinux.org, and then my key
3. Followed a guide to "prevent secure boot policy on by default", by turning the secure boot preset to custom/Maximum security: https://github.com/Foxboron/sbctl/wiki/FQ0001
Result: No change, same issues
4. Deleted key with mokutil, but then deleted it in mmx64.efi instead of enrolling, and then enrolled it on the next reboot in mmx64.efi
Result: No change, same issues
Let me know if anything else would be helpful!

Arch Linux

#1 2026-07-17 03:24:57