I want to close the loop on this in case other folks run into this. Although the Wyse 5060 thin client supports UEFI mode, it looks like it’s buggy enough that none of the pxe files included with Fog will boot it. Legacy mode works however, so that’s what I’m going with. I actually did a test on each file in /tftpboot and here are the results:

c68fa3c6-af25-4320-aa01-daf8263a7fc7-image.png

So I’m going with undionly.kpxe.

The other issue I’ve had is that once I did a Win 10 IoT install on a legacy-booted 5060, the fog capture process would fail, saying I needed to run fixparts. In the ‘capture - debug’ shell, the fixparts command wasn’t available, and I ended up accidentally nuking my Win10 boot partition. Oh well.

I’m retrying this again. I have a flash drive that’s MBR (not GPT) formatted with the Win10 IOT installer. I made sure the 5060 is in legacy mode, and when I started the install I hit Shift-F10 to drop to a cmd prompt and used these commands to ensure there were no linger gpt partitions on this disk:

diskpart
list disk
select disk 0
clean
convert mbr
exit

and I went ahead with the install. When windows updates finish, I’m going to attempt to capture the image and see if it works.

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

@rdr I see what you mean now. I thought FOG server saves the last IP address to its database and use it to determine if the powered off host is on the same subnet. If it is using live ARP lookups via agents to determine the subnets/agents matching then I can not customize or hardcode it.

@GRISLET The task is only marked complete by one request: POST /fog/service/Post_Stage3.php, sent by fog.imgcomplete as the last step of the deploy. Your log shows it never went out, so the script exited before reaching it.

You see no error because S99fog prints * Rebooting system as task is complete and reboots whenever /bin/fog exits, for any reason. A silent early exit is indistinguishable on screen from a real completion.

The 48-second gap points at where. fog.statusreporter posts progress.php every 3 seconds for the whole task and stops only when killStatusReporter kills it — which is the first line of completeTasking. After that line, only three things run before the completion POST. One of them is /images/postdownloadscripts/fog.postdownload, which is sourced into the imaging shell. An exit or a reboot in that script, or in any script it calls with ., ends the task before FOG is told about it.

Two things would confirm it:

cat /images/postdownloadscripts/fog.postdownload, plus any script it sources. Look for exit or reboot. The last ten lines on the client screen before the reboot. Do Stopping FOG Status Reporter, * Task Complete and Updating Database appear? If they do not, the run ended early and the image type is not involved.

The image type is probably a red herring. Nothing between the end of the restore and the completion POST depends on Single Disk - Resizable.

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

@Tom-Elliott I edited the sshd_config file and changed
/usr/lib/openssh/sftp-server
to
internal-sftp

I’m not sure how the installer failed to make this accomodation in the first place but I’m glad it appears to be working. I deployed the image to another laptop to make sure everything is working. It looks like the problem can be considered resolved now. Thanks for your help!

@gmaurice resetting the host encryption in the gui and then restart the fog service and it should be back up and running. You can also use the api for this, the FogApi powerhsell module (links in my signature) I have this Reset-HostEncryption function https://fogapi.readthedocs.io/en/latest/commands/Reset-HostEncryption/?h=reset+host which will also handle this reset.

Your other other option is to look into post download scripts, there’s some examples in the forums and the docs. If you’re using sysprep and unattend.xml you can inject domain join information into the unattend.xml after imaging and before windows launches for the first time, so the computer is joined to the domain before the fog service or any ui is reachable.

@Tom-Elliott Thank you, tested, confirmed it’s fixed.

@scottrayr I’m not able to replicate the issue you’re seeing.

@Tom-Elliot
Unfortunately, I had to get the PCs up and running right away, so I wasn’t able to work through everything on the list. For now, I’ve cloned them without multicast. Next week, I’ll get back to you—I’ll test the rest then.
–public-web-cert.
root@fog:~# openssl s_client -connect fog.mm.htlwien10.at:443 -servername fog.mm .htlwien10.at </dev/null 2>/dev/null | grep -E ‘^ *[0-9]+ s:|^ +i:’

0 s:CN=fog.mm.htlwien10.at, O=FOG Project, OU=FOG Web UI
i:CN=FOG Web CA, O=FOG Project, OU=FOG Web UI
root@fog:~#

Power management.
fb4a04fa-e1db-45b0-8cef-e7e0ea456b60-grafik.png
SERIAL Number from SSD
I had another PC that wouldn’t clone because of an error when entering the SSD’s serial number…
The number BNE7N774610407R8O ends with an “O” and contains a “0” in the number. Unfortunately, the second SSD was listed in Inventory Static, and I had determined the number of the relevant ssd using lsblk -o SERIAL. There my mistake happend
ee68d2d1-4524-4087-8099-8ee0490afa3c-grafik.png WhatsApp Image 2026-09-10 at 17.12.42.jpeg

@Balage80 Thanks for confirming the enrollment fix.

UEFI boot: I think the cause is two new lines in default.ipxe. They read Secure Boot state from the firmware. iPXE reads it by stepping through every firmware variable, and some firmware never ends that list, so iPXE hangs there.

Please test this: take the new 979-byte default.ipxe and delete only these two lines. Keep everything else.

param secureboot ${efi/SecureBoot} param setupmode ${efi/SetupMode}

Does UEFI boot with that file? Please also post the make, model, and BIOS version of the machine. Note that re-running installfog.sh writes a new default.ipxe, which replaces a manual edit.

Pending MACs: these are not related to default.ipxe. They come from the legacy FOG Client’s Host Registration module. That module reports every adapter Windows sees, including Wi-Fi, Bluetooth, and virtual Wi-Fi Direct adapters. FOG stores each unknown MAC as pending, up to FOG_QUICKREG_MAX_PENDING_MACS per host (default 4). iPXE cannot see those adapters. You can delete the pending MACs. To stop new ones, add MAC fragments to FOG_QUICKREG_PENDING_MAC_FILTER (comma separated), or turn off Host Registration.

@Tom-Elliott That was quick 😊 I just tested and it works as expected. Thank you.

Rahman

@Tom-Elliott

I can’t modify the company’s switches or other hardware since the system is in production. I’m currently rebuilding the FOG server on a VM on my PC and doing everything locally; it’ll be easier to troubleshoot that way. Gemini has wiped out all the previous messages and is giving me nonsense—I can’t seem to recreate the environment up to the capture stage anymore. Could you give me a rundown of everything that needs to be done—downloads, decompressing specific files in binary mode, etc.?

Thanks.

@azm9s Good that legacy boot works now. For UEFI, your first tcpdump already shows one problem. It stops UEFI clients on every board, with Secure Boot on or off.

First: remove option 60 from your Windows DHCP server.
Your DHCP offer contains option 60 = “PXEClient”. UEFI firmware reads this as “this server is a PXE boot server”. It sends a second request to 192.168.65.35 on UDP port 4011 and waits. FOG does not listen on port 4011, so the firmware stops before it downloads any file. That is why no boot file worked. Legacy network boot does not do this, so legacy works. You only need option 60 if WDS runs on the same server as DHCP.

Second: set option 67 for UEFI to secureboot/snponly-shimx64.efi.
Your version (1.5.10.2253) installs this file. Check that it is there:

ls /tftpboot/secureboot/

It is signed by Microsoft, so it boots with Secure Boot on or off. You do not need to disable Secure Boot. Do not point option 67 at secureboot/ipxe.efi directly. With Secure Boot on, the firmware rejects it. If the menu loads but the network does not start, use secureboot/ipxe-shimx64.efi instead.

To keep legacy and UEFI working at the same time, use Windows DHCP policies. Vendor class PXEClient:Arch:00000 keeps your current legacy file, and PXEClient:Arch:00007 gets the file above:
https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence

If UEFI still fails after these two changes, run this on the FOG server while the PC boots, and post the output:

tcpdump -i eth0 -n -vv ether host fc:9d:05:76:7c:00

FYI for anyone else running into this issue - I believe the problem was that I didn’t erase the /tftpboot images when I switched from http to https. I’m not really sure why that would matter, but when I did that, then re-ran the server reinstall and selected https, the images got but back in /tftpboot and my hosts didn’t see the mac error anymore.

@ahaeder No:

The idea of fog client is to rename the host based on what you name the computer within FOG, not the other way around.

If you want it to be a specific name, and you have the FOG Client installed, set the wanted name in the FOG UI, and the host will change automatically.

@jmeyer I have some e16 g1s and I am not having the same issue. What version of fog are you running? Are there any other secure boot settings you have configured or maybe not configured? Can you get to the mok enroll with secure boot off? And then turn it back on?

@Priyankha We need a lot more details.

FOG Version

What bootfile is your boot server trying to send?

Is you server sending the right FOG server for option 66/67?

What OS are you trying to capture?

What does the error show or maybe a screen shot? (UEFI Boot looks different from Legacy boot from Mac from arm, etc…)

What type of machine are you trying to image?

What have you tried?