@Cpasjuste I just wanted to let you know that I’ve added in your method of using userland NFS support to my container. I have given you credit for the method in the README. I’d love for you to test it out if/when you get a chance. Thank you again for your work!

@Coolguy3289 Thanks for the log line. It points at a bug, not at your approach.

The installer creates a “FOG Agent CA” under the server root CA. It only creates it when the file is missing. If the root CA changes later (for example, you copy the old server’s /opt/fog/snapins/ssl onto the new box so existing clients keep trusting it), the agent CA stays signed by the first root. Every enrollment then fails with the error you see, and the agent gets a 503.

The fix is in PR #1810: the installer now re-creates the agent CA when the current root did not sign it.

To fix your server now, without waiting for the PR:

sudo grep PKI_AGENT_CA_CERT /opt/fog/.fog-pki

Move the .fogAgentCA.pem and .fogAgentCA.key files in that directory to a backup location. Then re-run the installer. It creates a new agent CA under your current root, and enrollment works.

You do not need your internal PKI for this. The FOG-generated root is fine for production.

@DiegoP Thanks, your workaround found the cause.

FOS installs mdadm’s udev rule, and that rule assembles every RAID member at boot. It ignored mdraid=true. The arrays then held nvme0n1p2/p3, so capture could not read the partitions.

FOS now assembles arrays only when mdraid=true is on the kernel command line. Without the flag, it leaves the member partitions alone. With the flag, nothing changes.

The fix is in the experimental FOS release EXP_20261001-163131: https://github.com/FOGProject/fos/releases/tag/EXP_20261001-163131. Replace /var/www/html/fog/service/ipxe/init.xz on your FOG server with that release’s init.xz. Then remove the postinit workaround and capture again. Please tell us whether it works.

@Tom-Elliott
These are the two machines that were just cloned!

I deployed the Snap-in three times:
the two newly cloned machines and one old machine to see if any certificate issues arise with the old computers. All of them were assigned Image B.

The computer, which has not yet been cloned, did not process the snap-in.

ec06f2be-575a-48f2-9f68-3a9f156dd330-grafik.png

------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 28.09.2026 07:38:56 Client-Info Version: 0.13.0 28.09.2026 07:38:56 Client-Info OS: Windows 28.09.2026 07:38:56 Middleware::Authentication Waiting for authentication timeout to pass 28.09.2026 07:40:56 Middleware::Communication Download: http://192.168.0.196/fog/management/other/ssl/srvpublic.crt 28.09.2026 07:40:58 Middleware::Communication ERROR: Could not download file 28.09.2026 07:40:58 Middleware::Communication ERROR: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. 28.09.2026 07:40:58 Client-Info ERROR: Failed to authenticate, will not run Module Looper.

78935d01-cc19-4dd8-b5bc-fb03e7885c58-grafik.png
Resetting the encryption settings, deleting the snap-in that wasn’t running, and restarting it didn’t help…

Rebooting of the pc helped

@astrugatch I don’t think it matters really. The issue was more about the initial pinning of the certificate during the install process. After it is pinned I think this is the correct expectation (it should only communicate to the FOG server over HTTPS).

@servicedesk-pianezza Yes, FOG writes that boot code, and I can show you where. Your finding holds up against our
source and against a reproduction here.

Where it comes from. On capture, saveGRUB() in funcs.sh copies the first 1 MiB of the
source disk into d1.mbr with dd — LBA0 included, boot code and all. On deploy,
clearPartitionTables() runs sgdisk -Z, which does clear the MBR, and then restoreGRUB()
writes d1.mbr straight back over it. The next two commands are sgdisk -z, which destroys
the GPT structures only and leaves the MBR bytes alone, and sgdisk -gl, which rewrites only
the protective partition entry. So the captured Windows bootstrap survives the whole
sequence, and gdisk supplies the entry in its own convention: EndCHS ff ff ff and the exact
sector count.

I replayed that sequence here on a loop-backed disk with one of our own Windows 11 resizable
images. The result matches what you found byte for byte in shape:

LBA0 : 33 c0 8e d0 bc 00 7c 8e ... (Windows MBR stub) 0x1BE : 00 00 02 00 ee ff ff ff 01 00 00 00 af 32 cf 1d

Why it is not simply a bug. On a BIOS-booted GPT Linux disk that same region is GRUB’s
boot.img, and d1.grub.mbr exists precisely so we keep it. We cannot blanket-zero LBA0 on
every GPT restore. On a Windows GPT image it is dead weight — Windows only boots GPT through
UEFI — so a targeted change is available to us. But we should change the right bytes.

Which byte is it? Your diskpart disk differs from ours in three places at once, so we do
not yet know which one the firmware chokes on. Three one-liners settle it. Start from a fresh
deploy that hangs, run one of them, power off, power on, press F2. Redeploy between tests so
each one is measured on its own:

# 1 - the bootstrap, nothing else dd if=/dev/zero of=/dev/nvme0n1 bs=1 count=446 conv=notrunc # 2 - the size field -> sentinel printf '\xff\xff\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=458 conv=notrunc # 3 - EndCHS -> the diskpart value printf '\xfe\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=451 conv=notrunc

Each writes inside LBA0 only and leaves the GPT untouched. Test 1 is the one I expect to
matter, on the theory you already stated — a CSM path in that firmware reading or validating
a bootstrap it should be ignoring.

Name the byte and the fix is small: for a GPT image whose OS is Windows, clear that field
during the restore and leave Linux images alone. That also gives the two 2020 reports on this
hardware an explanation, which is worth having on its own.

@Tom-Elliott
Hi!
I have updated to the latest dev-branch version.
No more updating database … failed error.
The multicast session closing the right way.

Thank you!

This can be closed. Thank you.

Awesome and thank you. Confirmed working.

Hi Tom,

In my case the culprit was /images/postdownloadscripts/fog.postdownload.

echo "Activating boot partition..." sfdisk --activate /dev/sda 1 echo "Rebooting..." reboot -f

Fix was simply commenting out (or deleting) those lines. After cleanup the file looks like this:

cat /images/postdownloadscripts/fog.postdownload #!/bin/bash ## This file serves as a starting point to call your custom postimaging scripts. ## <SCRIPTNAME> should be changed to the script you're planning to use. ## Syntax of post download scripts are #. ${postdownpath}<SCRIPTNAME>

Thanks for the pointer, Tom — saved me from chasing GPT partition tables for a problem that had nothing to do with them.

@servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.

The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.

There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.

The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.

It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773

It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.

@ahaeder A final setting - you have to set Bios exit type = GRUB (not the default SANBOOT) or the boot hangs at ‘Booting from SAN device’.

Now I read the AI summary and got what I need:

It stores one row for each address in the hostNetwork table. Limits of this method The sleeping host must run fog-agent. The server uses the sleeping host’s own last report to find its subnet. A host with the legacy FOG Client, or with no client, has no rows, so the relay cannot help it. The old path still runs for it.

So If I populate the hostNetwork table for the hosts that I need manually, It will work. Thank you for the details.

@mp12 Thanks for the logs. This is a bug in 1.5.10.2482, not your node passwords.

A security change in 2482 removes the storage node password from the node data that the API returns. The image and snapin replicators read their node list from that same data. So they now send an empty password, and every node rejects the login. The Undefined property: stdClass::$pass warning is that missing field.

The fix is merged to dev-branch: https://github.com/FOGProject/fogproject/pull/1770

To get it now, update from dev-branch:

cd /path/to/fogproject git checkout dev-branch git pull cd bin sudo ./installfog.sh -y

Or wait for the next stable release. Your stored passwords are correct, so you do not need to change anything on the nodes.

@AUTH-IT-Center I do believe snponly would be the recommended, rather than iPXE’s driver.

The developers at iPXE wrote the driver on their own (of course using documentation and stuff, but for all intents/purposes it is still a handrolled driver) so anything is possible.

We shipped the native iPXE 2.0.0 mainly because of the feature it allows with actual Secureboot capabilities and instead of embedding everyfile with a custom script, a more dynamic approach for when iPXE releases new version we can upgrade more easily.

For what it’s worth, I would almost want more people to default to snponly.efi (or secureboot/snponly-shimx64.efi if using/wanting secureboot after enrolling your machines of course) because this is supposed to be using the generic driver for EFI boot protocols on the NIC rather then attempting to discover the NIC using a driver loaded.

Glad you have a workaround. I think the cause is the Windows boot manager certificate change, not the image.

Your golden Optiplex installed Windows with Secure Boot on. Windows servicing then added the “Windows UEFI CA 2023” certificate to that machine’s db, and switched the boot files to a boot manager signed with it. The other Optiplex 3000s only trust the 2011 Microsoft certificates, so they reject that boot manager. bcdboot works because it copies the older 2011-signed boot manager.

Can you confirm with two checks, in admin PowerShell, on the golden machine and on one target?

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' mountvol S: /s (Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi).SignerCertificate.Issuer

If the golden machine says True and the target says False, that is the cause. A newer Dell BIOS may include the 2023 certificate in its default keys. I am also looking at having FOS add it during the Secure Boot enrollment task.