@tlehrian I don’t have enough information.

Try the latest dev-branch or working-1.6?

@craigcoulson Update to the latest dev-branch and you should be good to go.

@KMEH This might be able to help:
https://docs.fogproject.org/en/latest/management/server/install-fogsettings/

@Valer This should be fixed in latest/greatest

@KMEH This wasn’t somehow. partly it was yours (among all the others) requests for secure boot and some max access to claude that really helped get this more flushed out more properly.

And a lot of mind tossing to get there.

Hopefully you enjoy it and like it (everyone).

@Valer I think we need to understand what this plugin is doing.

CSS isn’t something we’ve allowed to be injectable though it could be.

You can still use your own CSS but that’s more at the FOG Configuration -> FOG Setting -> FOG_THEME, but you would need to put it on your server in a location you type the path too here.

https://docs.fogproject.org/en/latest/development/plugin-development

This is a good toolkit for understanding how to build your own plugin.

@Strahd Have you been able to make progress?

@Valer I was able to replicate and believe I’ve updated the code enough to fix all the issues you were seeing if you don’t mind doing the git pull and re-install.

@Valer For the Storage Group/Storage Node issue, fog doesn’t delete anything when installing.

At most it may alter tables or swap data around but I don’t think that’s what happened here.

I do see it showing 12 storage groups, I don’t see your screen for storage nodes. I’ll see if I can replicate the problem there. Confusing why it shows 12 to 1 of 1 entry? A little strange

Refind needing being signed, makes sense. The Secureboot stuff we worked on was mostly concerned with the flow from IPXE -> Kernel, I didn’t think about the refind file. I’ll see if I can address that.

Can you tell me what schema version you’re on?

MariaDB [fog]> select * from schemaVersion;
+-----+--------+
| vID | vValue |
+-----+--------+
|   1 |    323 |
+-----+--------+
1 row in set (0.000 sec)

Is what you should see. 323 is the latest which injects that new Task item, that said if your machine is in legacy boot, (non-uefi) you won’t be presented with the menu.

If you can give me:

SELECT vValue FROM schemaVersion;
SELECT pxeID, pxeName FROM pxeMenu ORDER BY pxeID;

@Strahd At the least I’d suggest downloading an export of your hosts/images:

From there you can delete the database or rebuidl from scratch by:

mysql -u root If you have a password on your db I don’t know it but use the -p and you’ll be prompted to enter it.

DROP DATABASE fog;

Will delete everything.

From there, I still highly recommend you delete the /opt/fog/.fogsettings

Then rerun the installer.

I’m still going to say use working-1.6 as the testbed.

I hate that you’re having issues and I assure you I’m unable to replicate the problem you’re currently having which makes trying to fix your specific case impossible of course.

Hope this helps.

I’d still (at the least) get a full backup of your DB just in case something goes horribly wrong.

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.

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

Thanks for letting us know. It wasn’t really “hurting” things but you’re right that it’s not as “pretty”.

Please update dev-branch again and re-install and it should do what you’re expecting again.

Thank you.

@FireGun679 Would you be able to update your fog to dev-branch or even better if you can update all nodes to working-1.6? potentially?

worst case at least upate to dev-branch or even the current stable and I think you’ll see things working.

@FireGun679 What version of FOG are you running? (Bottom right corner)

@rpycroft Please attempt to update to 2231.

@sgennadi It already is possible You just have to do the MOK or (use the new task type you see in working-1.6 to do all the work)

Kernels are already signed automatically.

@Matthiman, @sgennadi We are workign to a processed method of allowing secureboot which (in my test env’s) has proven successful.

The nicer part is this does not require Secure boot to be enabled to work.

@sgennadi SWEET! Thank you!

@Matthiman Your issue appears similar to an issue that’s being described here:
https://forums.fogproject.org/topic/18213/version-1-6-0-beta-3187-ipxe-2-0-0-x-problems

Though they seem to indicate changing to an older bootfile (snponly.efi/ipxe.efi whatever) worked so it’s not a kernel/init issue that’s happening causing this to occur.

This may be what’s happening with everyone in this thread as well, but the first image that I see from Fog_Newb looks more like what I’d expect where there’s not enough ram available to load.