Document the Enroll Secure Boot Key boot menu item - #89
Merged
Conversation
FOG 1.6.0 adds a "Enroll Secure Boot Key" PXE menu entry (fog.enrollsecureboot, pxeID 14) that chains MokManager, so enrolling a MOK no longer needs a live Linux image. Route B was already the "no operating system at all" route but described it as a raw MokManager manoeuvre and warned it off; it is now a first-class path and worth reaching for first when you are already at the machine. Spell out the part that surprises people: MOK.der still has to be on local FAT media, because MokManager reads it through the firmware's filesystem support and has no network stack. That is not something FOG can fix. Also records the enrolment run in Verified, including why MokManager can be chained at all -- mmx64.efi carries iPXE's signature rather than Microsoft's, so the firmware would refuse it directly, but the load goes through shim's verification protocol instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mastacontrola
added a commit
that referenced
this pull request
Aug 3, 2026
PR #89 landed first and rewrote Route B around the new Enroll Secure Boot Key menu item, with verified step-by-step. This branch had rewritten the same section from the other direction: diagnosing WHY a plain shim boot never reaches MokManager. Both are right; the conflict was purely that they occupied the same prose. Kept #89's structure and steps -- they are the verified ones, run end to end on a VM with no MOK enrolled -- and folded this branch's diagnosis in as a callout, since it answers the question #89's steps leave open. Three corrections made while resolving, all in this branch's text: 1. "secureboot/arm64-efi/mmx64.efi" does not exist and never has. arm64's MokManager is mmaa64.efi. This is the exact mistake bootmenu.class.php carries a comment about, having broken every arm64 client once already. 2. Dropped the "point DHCP straight at mmx64.efi" fallback entirely. It cannot work: mmx64.efi is signed by iPXE, not Microsoft, and the firmware checks the FIRST binary against db alone -- which this page already says two sections earlier. It boots from the menu only because iPXE loads it through shim's verification protocol. Replaced with the accurate statement that pre-1.6.0 has no PXE route to MokManager, so Route A is the answer there. 3. This branch said Route A first, #89 said Route B first. Kept #89's -- it is newer, verified, and explicitly accounts for the firmware-hang risk that motivated the older advice. Also retargeted the "If MokManager does not appear" callout, which after (2) was still offering the impossible boot-file route. The two additions unique to this branch -- the internal-CA tip and the iPXE cross-signing note on HTTPS -- did not overlap #89 and carried over untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows fogproject#976, which added the Enroll Secure Boot Key PXE menu entry (
fog.enrollsecureboot,pxeID14) in 1.6.0.What changed
kb/how-tos/secure-boot-signing.mdMOK.derstill has to be on local FAT media. MokManager reads it through the firmware's filesystem support and has no network stack, so this is not something FOG can remove — worth stating before someone goes looking for the setting.mmaa64.efiautomatically.management/fos/using-fog-boot-menu.md— adds the entry alongside the other boot menu commands, in that page's existing style.Why MokManager can be chained at all
Worth recording, because it looks like it should not work:
mmx64.eficarries iPXE's signature rather than Microsoft's, so the firmware would refuse to launch it directly. The load goes through shim's verification protocol instead, and shim trusts it — the same mechanism that lets a MOK-signed kernel boot.Verified
Run end to end on a VM whose firmware had no MOK enrolled at all: PXE → menu item → MokManager →
Enroll key from disk→ reboot → MOK-signedbzImageboots. Still unconfirmed on physical hardware, and the page continues to say so.🤖 Generated with Claude Code