FOG Secure Boot with Shim
-
Some Updates (08/12/2025):
- Fedora has successfully obtained a signed copy of Shim 16.1 which should fix Dell Network boot issue. You can obtain it by downloading the rawhide rpm package and extracting it. I haven’t tested it yet, but will post an update once I do. - I have now tested the new shim, and can confirm it works.
- Around 9 months ago, it looks like a change was pushed to fog which actually updated the general.h header file, enabling the shim command by default. As such performing this modification manually isn’t required anymore.
-
Quick Update (19/12/2025):
Hi Everyone,
I’ll probably open another topic for this in the coming weeks, as it probably deserves it’s own thread for bug reports and feature requests etc (mostly need to convince myself to write it, but also wanted to double check which category such a thread should go under, is tutorials fine?), but I’ve created an ansible role to help with the installation and configuration of fog.
Notably it will help with creating a secureboot valid setup with shim like above. It should implement most of the important functions of the fog installer, and can also automatically perform a lot of the steps in the guide above for you.
I figured I’d drop it here on the forum somewhere in case it’s helpful for others. More detailed usage information will be added to the readme or the new topic. Naturally I’ll link to a new topic here once I get around to making it.
The role is currently hosted on my forgejo instance here: https://forgejo.cwavs.xyz/Cwavs/ansible-role-fog
-
@KMEH Great job !
I can’t wait for it to be implemented directly during the installation of FOG.
Are the bugs on Dell only affecting older models? -
@Florent Thanks Florent. Hopefully it does!
The issues I’ve listed here do seem to only affect older models of Dell, however UEFI (despite having the word unified in the name) varies wildly by vendor, and even within Vendors, so I wouldn’t be surprised to learn there are similar or different issues affecting newer Dells or even non-Dell machines.
That said, based on my experience at work. I can’t say I’ve seen too many machines have the number of bizarre issues as I have seen with the older Dell PCs we have.
As with all things, I’d suggest testing it on some of the machines common in your fleet of computers and seeing what works and what doesn’t.
-
@KMEH Hi,
I tried your method and it only partially worked. It reached the FOG menu correctly after enrolling the key, but the problem arises when I try to perform a quickreg or deploy an image. In both cases, I get the following error (it starts working again when I disable Secure Boot)
my version is 1.5.10
-
@toalalife Hi there! Sorry for the late reply. I’ve been on holiday and I forgot to check up on this. That is interesting. There are a couple of things I can think of to double check/try off the top of my head.
That particular error happens when iPXE can’t execute the binary, usually because either an architecture mismatch (e.g arm64 on x64) or because secboot fails to verify. Given that disabling secboot fixes it, I’m leaning towards that. (https://ipxe.org/err/2e0080)
So I would say you should double check that your kernel is signed. If you’ve updated them you’ll have to resign the kernel to ensure it keeps working.
The other would be to double check that the shim command is being invoked at some point prior to boot.php being chained. There’s a none zero chance that if you’ve updated FOG, it may have overwritten the modified default.ipxe
Other than that, if you could try and record the boot process I’d be happy to take a look and see if I can spot anything out of the ordinary, I’m also happy to take a look at your kernel or any ipxe scripts etc if you want me to double check if they’re signed or bootable.
As a final note, I don’t think I see iPXE loading the initrd.xz file there, which contains the ram filesystem that FOG uses on boot. I could be misremembering the boot process (I can’t recall if it’s normal for it to not do that if the bzImage fails to verify, or if it loads it prior to bzImage), but if that’s failing to load it might also be worth checking that out, though it shouldn’t have to be signed!
-
@KMEH Well, it must be another image I couldn’t attach. I’ve honestly dedicated many hours to this without success. I’ve seen another project called foguefi (https://github.com/abotzung/foguefi), compatible with Secure Boot directly, without using MOK, and it works. It’s just that when you select options like quickreg or deploy an image, it takes forever. But the point is, it works with recursive boot enabled. It shouldn’t be that complicated.
Anyway, do you have a list of commands to configure it? Maybe I or the AI is missing something.
-
@KMEH Well, it must be another image I couldn’t attach.
Which image are you referring to here? bzImage? If so bzImage is the filename of the kernel.
I’ve honestly dedicated many hours to this without success. I’ve seen another project called foguefi (https://github.com/abotzung/foguefi), compatible with Secure Boot directly, without using MOK, and it works. It’s just that when you select options like quickreg or deploy an image, it takes forever. But the point is, it works with recursive boot enabled. It shouldn’t be that complicated.
Yeah, I am aware of foguefi (I actually reference it in the original post), but I think you are slgithly mistaken, it actually is also using MOK. It chains grub via shim (which is similar to what we’re doing here, chaining iPXE via shim) and then re-implements the iPXE menus into grub. This works great, but requires a lot of maintenance effort if anything changes upstream in FOG.
As you can see that project is currently archived, but FOG is also reasonably stable, so I’m not sure how long it will take for a breaking change to stop it from working. Part of the reason I devised this method is that (although hackier to implement on a user level), it doesn’t rely on any functionality that isn’t already present in standard FOG server itself for the most part and it could reasonably be implemented by the FOG developers should the wish to add it.
Anyway, do you have a list of commands to configure it? Maybe I or the AI is missing something.
Sorry I’m a little lost here, commands to configure what? foguefi? If so I’m not sure, I haven’t used it myself so you’d have to ask the developer. If it’s commands to configure my method, the guide above should have everything you need.
-
I don’t understand well everything but maybe it’s more complex than this and I understand nothing at all. haha
On my server I have a “shimx64.efi” in “/boot/efi/EFI/debian/” can I use it directy or I must install shim-signed and use the shimx64.efi.signed ?
-
@jmeyer Now worries, it gets a little confusing, and sorry for the late reply again, I was on Holiday last week so didn’t check the forums for a while. I believe that shim should already be signed and you should be able to use it. You should already have the signed shim package installed which would provide that file I would imagine, though I’m not familiar with Debian to say that with any certainty. However, that shim would need to be copied into the /tftpboot folder and it’s permissions changed accordingly. Remember to renamed your ipxe binary to grubx64.efi or whatever the Debian shim is programmed to automatically chainload.