@FlareImp Thanks, the log shows the cause. 1.6.0.14 has a replication bug: the check for a transfer that is still running never matched. So each cycle compared the files while lftp was still copying them. It saw the half-copied file on the node, logged “File size mismatch”, deleted it, and started the copy again. A large file over your rate-limited link never finished. That is why rsync worked and the replicator did not.

1.6.0.158 fixes this. Please update the master and every storage node to 1.6.0.158, then turn the replicator back on.

The “File does not exist win11” lines are the subfolder name, not a missing file. 1.5 logs the same lines. They make lftp run once per cycle, but it copies nothing when the files already match.

@Tom-Elliott Thank you once again for the amazing support and turnaround.

@lperoma The fix is now in stable release 1.6.0.158. Update to it, and a refused task shows its reason in the modal instead of hanging on “Loading, please wait…”.

@JYost With agent 0.1.23 or later, you do not need to stop or disable it before Sysprep, and you do not need the SetupComplete.cmd line. The agent waits until Windows setup has finished before it enrolls, checks in, or reboots. It starts on its own after OOBE completes.

On an older agent, update it on the reference machine first. Or use the same steps as before with the new service name: sc config fog-agent start= disabled before Sysprep, then sc config fog-agent start= delayed-auto and sc start fog-agent in SetupComplete.cmd.

You also do not need to clear the agent’s key before capture. Each deployed machine has different firmware IDs, so the agent drops the captured key and enrolls as itself. A deploy from your server approves it automatically.

No firewall rule is needed. The agent opens no listening port. It only connects out to the FOG server over HTTPS.

Details: https://docs.fogproject.org/installation/client/install-fog-agent#capturing-an-image-with-the-agent-installed

@Tom-Elliott Okay, thank you for the information.

I ran this command on the host, and then restarted the FogService., but my issue might have been slightly different.

reg add “HKLM\System\CurrentControlSet\Control\Lsa” /v NetJoinLegacyAccountReuse /t REG_DWORD /d 1 /f

Then it joined to AD with no issues.

Are those exisiting machines in AD that you re-imaged with FOG, or were they new devices?

This only happened to us with exisitng machines in AD that we re-imaged and then couldn’t join AD again after.

@Shuttleu Thank you for testing on the HP. That confirms the fix on real firmware.

The task error after a menu enrollment. This is a FOS bug, not the agent. The menu item runs the enrollment with no task scheduled. When the enrollment finishes, FOS tries to close the task. The server answers “No Active Task found”, and FOS shows an error. The enrollment itself succeeded. The fix is in FOS release 20261106-134043. After a menu run, FOS now says that no task is scheduled and ends normally. The server records the enrollment on the host only when you schedule the task from the web UI.

FOG Agent. You found the cause. Uninstall keeps C:\ProgramData\FOG on purpose. It holds the machine’s key, its certificate and the trusted CA, so a reinstall keeps the same identity. The reinstall kept the CA of your earlier server, so every connection failed and the token was never used. Agent v0.1.21 fixes this. Setup now checks the stored trust against the server. If it no longer verifies, setup settles trust again like a first install, and the host enrolls again with the token. Until you install v0.1.21, deleting C:\ProgramData\FOG before the reinstall is the right workaround.

Your server certificate comes from your company CA, which Windows already trusts. So no fingerprint is needed, as the probe said. Leave CAFINGERPRINT out on these machines.

@Tom-Elliott

Hopefully I’ll have the answer to that question within the next two weeks!

@fgaudin Good to hear it works.

UEFI alone does not need secureboot=1. The setting is only for computers that have Secure Boot turned on in the firmware. With secureboot=0, FOG does not sign its boot files, and a computer with Secure Boot on refuses to boot them.

If Secure Boot is off on your computers, keep secureboot='0'. If Secure Boot is on, set secureboot='1' and run ./installfog.sh -y. Do not use -C or -K. Each computer then enrolls the FOG key one time at its first PXE boot.

Install sudo before you set it to 1. The Secure Boot signing helper needs /etc/sudoers.d.

@Tom-Elliott All is working now

Hey Tom, updated to 1.6.0.97 this morning and everything checks out:

Exports: migrated to /etc/exports.d/fog.exports, and my kubuntu.exports came through untouched.
SSH keys: fog@fogger key landed in authorized_keys, works on my custom port. Pulled the Match password exception, so the box is key-only again.
Dashboard: 1.5 history is back, and the Nov 3 runs are on Nov 3 now.
Capture: new capture shows local time, no asterisk, and moved out of /images/dev over the key with no errors in the log.
Ports: FOG_SSH_PORT now shows up under FOG Settings → General Settings with my 2416, and the per-node fields are blank, so it falls back to that.

Seriously impressive turnaround. Thanks for taking the reports seriously and running with them!

@Tom-Elliott Hey Tom, updated to 1.6.0.97 this morning and everything checks out:

Exports: migrated to /etc/exports.d/fog.exports, and my kubuntu.exports came through untouched.
SSH keys: fog@fogger key landed in authorized_keys, works on my custom port. Pulled the Match password exception, so the box is key-only again.
Dashboard: 1.5 history is back, and the Nov 3 runs are on Nov 3 now.
Capture: new capture shows local time, no asterisk, and moved out of /images/dev over the key with no errors in the log.
Ports: FOG_SSH_PORT now shows up under FOG Settings → General Settings with my port, and the per-node fields are blank, so it falls back to that.

Seriously impressive turnaround. Thanks for taking the reports seriously and running with them!

@Tom-Elliott All good! Thank you and keep up the awesome work!

@rogalskij Glad to be of help and your finding did notice an issue that was also addressed on the dev-branch so thank you!

@Tom-Elliott As always, thanks for the answer and quick fix 😊

@Tom-Elliott Thanks fo the quick reply!
I did rerun the installer today and it seems to be working now, thanks a lot for the quick feedback and fix!

@Coolguy3289 I believe we fixed the problem, please confirm and I can solve this thread, thank you!

@piaFOG26 Are you able to confirm if things are now working for you?

@Tom-Elliott sorry tom yes i am, sorry for the late reply, tbh i think its just hp machines that do this

@Tom-Elliott

Thank you!

As you thought, it was a double DHCP server… Even though .6 was in bridge mode, the DHCP server on it was still enabled, unlike the other MikroTik switches we have. Disabling it brought the iPXE booting back. I’ve run a re-inventory task and am now running an image capture task.

I’ll have to keep a future eye open for that as we expand our classroom network.

Cheers!

@robertkwild The issue most likely is not coming from the flip of Secureboot On/Off.

Unsigned or test-signed boot drivers. This is where a real BSOD can happen. If the machine has bcdedit /set testsigning on or nointegritychecks, and a boot-start driver depends on that (an unsigned storage or RAID driver, some sketchy anti-cheat, a dev build), turning Secure Boot on makes those settings get ignored. If the storage driver doesn’t load, you get INACCESSIBLE_BOOT_DEVICE. That one only happens in the off-to-on direction.