@Valer — good news on both counts.
In-place upgrade. With 200 hosts and a pile of images, upgrade in place. The installer handles the schema migration, and nothing about your images or host records needs to move. A clean install plus migration buys you nothing here and gives you a lot more to get wrong.
cd /opt
git clone https://github.com/fogproject/fogproject.git --branch working-1.6
cd fogproject/bin
sudo ./installfog.sh
Back up /opt/fog/.fogsettings and take a database dump first, as always.
(If you still have your 1.5 clone at /opt/fogproject, clone this one to a different directory rather than pulling a new branch into the old checkout.)
Your existing Secure Boot key. You don’t have to re-enrol anything. FOG 1.6 signs the FOS kernels itself, and it will use your key if you hand it over:
sudo ./installfog.sh \
--secure-boot-key /root/SB_key/FOG_SB.key \
--secure-boot-cert /root/SB_key/FOG_SB.crt
Three things that matter here:
- An admin-supplied pair always wins and is never touched or overwritten. FOG only generates a key of its own when you haven’t given it one.
- Both paths get written into
.fogsettings, so every future upgrade re-signs the kernels with the same key without you passing the flags again. An upgrade quietly replacing signed kernels with unsigned ones is the main way this setup breaks, so it’s deliberately persistent.
--secure-boot-cert takes either PEM or DER, so your .crt or your .der both work. It converts internally — sbsign wants PEM, mokutil wants DER, and you shouldn’t have to care which.
Since your key is already enrolled as a MOK on all 200 machines, that’s the whole job. Kernels get signed with the key those machines already trust, and they keep booting exactly as they do now.
After the upgrade, go to FOG Configuration → Secure Boot and check the SHA-256 fingerprint shown there against your enrolled cert:
openssl x509 -in /root/SB_key/FOG_SB.der -inform der -noout -fingerprint -sha256
If those match, you’re done.
Bringing your own key doesn’t cost you the automatic path. The server still generates its own PK and KEK, and the db.auth it publishes is built from your signing certificate — Microsoft’s db CAs plus yours. So for any machine you buy next year, you can use the hands-off enrolment described below and it will enrol the same key your existing 200 already trust. Your key and FOG’s platform keys are doing two different jobs and don’t conflict.
Kernel updates stay signed. When you pull a new FOS kernel from FOG Configuration → Kernel Update, the web UI doesn’t get near your private key. It downloads into a staging directory and then calls a helper through one narrow sudoers rule:
<apache user> ALL=(root) NOPASSWD: /opt/fog/bin/fog-sign-kernel
That helper deliberately takes no arguments — every path it uses comes from a root-owned config file at /opt/fog/.fog-secureboot (mode 0600), which it parses as data rather than sourcing as shell. So the web tier can ask for a signature but cannot point the signer at a different key, read the key, or write outside the staging area. The rule is validated with visudo -cqf before it’s installed; if validation fails the installer refuses to install it and tells you the Kernel Update page will serve unsigned kernels, rather than leaving you with a broken sudo.
Worth knowing because it’s the piece that keeps working silently for years — your key stays root-only at 0600, and kernel updates keep coming out signed with it.
What FOG does out of the box, for anyone starting fresh
Two different keys doing two different jobs — worth separating because they get conflated constantly:
- The signing key (
MOK.key / MOK.pem, generated at /opt/fog/secureboot/, root-only, 0700). This signs the FOS kernel so a Secure Boot client will execute it. It never regenerates once it exists — a fresh key would silently invalidate enrolment on every machine that trusted the old one, and you’d only find out when a client failed to boot.
- Platform keys (
PK and KEK). These sign nothing that ever executes. They exist only to authorise updates to a client’s Secure Boot databases.
Then three ways to get a machine to trust it:
A. Live USB. The server publishes an enrolment kit at http://<server>/fog/service/secureboot/ — MOK.der, plus fog-enroll-mok.sh and a .desktop launcher. Boot any stock Ubuntu/Debian live image with Secure Boot still on (they boot fine on their own signed shim), run the launcher, confirm the fingerprint, reboot into MokManager. No firmware trip.
B. PXE menu item “Enroll Secure Boot Key”, which chains straight to MokManager. Handy for answering a pending request, or for a machine FOS can’t boot.
C. Automatic, no touch — the new one. The server generates its own PK and KEK and publishes three signed variable updates alongside the kit:
| File |
Contents |
PK.auth |
this server’s platform key, self-signed |
KEK.auth |
Microsoft’s KEK CAs + this server’s KEK, signed by PK |
db.auth |
Microsoft’s db CAs + this server’s FOS signing cert, signed by KEK |
Schedule the Enroll Secure Boot task and FOS writes them. No USB, no live image, no keyboard.
The catch, and it’s the part people get wrong: the client must be in Setup Mode — Secure Boot keys cleared. Turning Secure Boot off is not the same thing and does not help; a machine with Secure Boot off but keys still present is in User Mode, and the databases cannot be written. In the firmware, look for “Erase all Secure Boot settings”, “Clear Secure Boot keys” or “Custom mode”. It’s still a firmware visit, but it can be the same visit that turns Secure Boot on afterwards.
Microsoft’s certificates are in there on purpose. Enrolling a PK replaces the platform’s trust anchor, so anything not in the db you write stops being bootable — that includes Windows, and it includes the Microsoft-signed shim in FOG’s own PXE chain. Omitting them would mean enrolling a key and destroying the thing you enrolled it for.
Everything above, including key rotation, is written up here: https://docs.fogproject.org/en/latest/kb/how-tos/secure-boot-signing/
Last thing — to PXE boot with Secure Boot on, DHCP option 67 needs to point at secureboot/snponly-shimx64.efi. The usual boot file is unsigned and a Secure Boot client will refuse it.
