How to upgrade to FOG 1.6?

[Valer]

Hello everyone,

I am currently using FOG 1.5.10.1903 and have about 200 computers on my network, already registered in FOG, with a lot of image. I would like to upgrade to FOG 1.6.

I also now have my own certificate for secure boot, which I manually enrolled to all computers (before this option appeared in FOG) and I had fog files signed with it and a working secure boot.

/root/SB_key/FOG_SB.crt
/root/SB_key/FOG_SB.der
/root/SB_key/FOG_SB.key

What would you recommend? Should I perform an in-place upgrade from 1.5 to 1.6, or would it be better to do a clean installation and migrate database and images to the new server?

Thanks for your advice.

[Tom Elliott]

@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.

[Tom Elliott]

Small correction to my own post above — I wrote “automatic, no touch” and then said it still needs a firmware visit, which reads as a contradiction. Let me untangle it, because the distinction is actually useful.

There is one Enroll Secure Boot task. What it manages to do depends on the state the client is in when it runs:

Client state	What the task does
Setup Mode (platform key cleared)	Enrols outright. Nothing to confirm, nobody at the keyboard.
Normal (keys present, Secure Boot off)	FOS stages the MOK request itself, non-interactively. Someone answers the blue MokManager screen once on the next reboot.
Already enforcing Secure Boot	Cannot run — the machine will not boot FOS in the first place. Use the live USB route for those.

So the task always removes the USB stick and the live image, which is the part that matters when you have 200 machines. Putting a machine in Setup Mode first removes the MokManager keystrokes as well.

Setup Mode is one visit to the firmware screen per machine, once — and it can be the same visit where you turn Secure Boot on afterwards. It is not the same as turning Secure Boot off: a machine with Secure Boot disabled still has a platform key and still refuses the database write. In the firmware, look for “Erase all Secure Boot settings”, “Clear Secure Boot keys” or “Custom mode”.

One practical note if you go the MokManager route: that blue screen has timeouts FOG cannot change. It gives up and boots normally if nothing is pressed within about 10 seconds of appearing, and it reboots if left idle partway through. Do not walk away from it.

None of this changes the answer for your existing fleet, @Valer — your key is already enrolled on those 200 machines, so you just pass it to the installer and they carry on as they are. The above is for machines you enrol from here on.