@Tom-Elliott
to make a backup I use now sql in bash

root@fog:~# mysql -u root -N -B -e “USE fog; SELECT CONCAT(‘UPDATE hosts SET hostDevice = ‘’’, hostDevice, ‘’’ WHERE hostID = ', hostID, ‘;’)FROM hosts;” > restore_hostdevice.sql

and restore with
root@fog:~# mysql -u root fog < restore_hostdevice.sql

@GregorS

Found it. The ~1KB you were seeing isn’t a truncated snapin — it’s a 6-byte #!auth error response that the FOG Client wrote to disk and then hashed (which of course doesn’t match the real snapin’s SHA512).

The root cause is on me. A recent security patch on dev-branch added a token check on the snapin download/checkin endpoints, but the deployed FOG Client doesn’t know to send that token — so every legitimate snapin download was getting rejected with #!auth. Closing one hole, opening a different one. Sorry about that.

I’ve reverted the patch on both dev-branch and working-1.6. If you pull the latest and re-run the installer (or just git pull + your usual deploy method), snapins should start working again. Versions to look for:

dev-branch: 1.5.10.1856
working-1.6: 1.6.0-beta.2336
The underlying security issue this was meant to address still needs a real fix, but that requires coordinated changes to both the server and the FOG Client itself, so it’ll be a future release rather than a hotfix.

Let me know if pulling the revert gets your snapins running, and thanks for the detailed report — the “binary garbage” file you described was the clue that cracked it.

We can mark this closed. Turns out it was a old/bad snapin package on the old server. I set up Fog with a new DB and everything worked fine. Once I removed the snapins and exported and imported the DB again it all worked as expected.

Thanks for the help.

@mashina Ah, thank you for that and sorry for my denseness. Indeed this is a bug and I’ve replicated and figured out where this is occurring.

I have pushed a few mroe adjustments in an attempt find and fix more bugs (thanks AI review and whatnot)

Please pull and let me know if there’s any other issues.

@Tom-Elliott just bumping this. Is there anything I can do to help? I have some experience building Linux kernels from a few years ago.

@Tom-Elliott
This is resolved in latest dev-branch version: 1.5.10.1853
Thanks.

@Mr_K
Thanks for the help Tom. You got me pointed in the right direction. Everything is working now.

I did a complete Ubnutu and fog fresh install to make sure I wasn’t missing anything and noticed during the installation it was grabbing my WAN IP as the fog server IP and then somehow changing the fog server IP to my LAN IP. So when I clicked on the link from the terminal after it had finished it was 192.168.1.148 however everything was setup “certs, storage Ipxe” ect as my WAN IP 20.21.X.X.

All I had to do was just change the fog settings so the IP’s matched re ran the installer to grab the new files and everything is running perfect now.

@Tom-Elliott Thanks for the clarification! I’ll try upgrading to the latest stable version, I was planning on doing this anyway.

I’ll look into the Persistent Groups plugin and see how it works!

@vanfifty1
I have some simelar Problems maby read the post
https://forums.fogproject.org/topic/18157/windows-11-65x-hp-z2-tower-g1i-update/2
My problem is/was that Fog uses sometimes the wrong nvme …

Fresh install using ver1.5.10.1826

Works perfectly. Can register hosts as normal

Maybe a bug with 1.6.0… hopefully if anyone else experiences this issue this might help

@bruno67

Are you sysprepping the image with all OOBE options set to be skipped before capturing it with FOG?

@gabriel-pissoto

I often record this with a phone then you can pick out the error in that micro flash of text.
I think most of the time picking a different X.pxe file resolves this for me.

@Nono Without going through the web interface you can check the file in /var/www/fog/lib/fog/system.class.php.
Toward the bottom of the file there is a line that start with define('FOG_VERSION'

@bond007fink A new version of ntfs-3g, which is the parent package for ntfsresize, has finally been released last week. That’s after 4 years of no updates. If all goes well, I will be doing an experimental release this weekend with the newer package.

As @Tom-Elliott stated, this is not an issue with FOG itself, instead FOG relies on tools like ntfs-3g and partclone to handle all the NTFS filesystem changes. Hopefully this updated version fixes your issue.
I will update the thread once the experimental release is available.

I don’t understand well everything but maybe it’s more complex than this and I understand nothing at all. haha

On my server I have a “shimx64.efi” in “/boot/efi/EFI/debian/” can I use it directy and rename it to autoexec.efi since I have build my own binaries that call autoexec.efi at pxe boot or I must install shim-signed and use the shimx64.efi.signed ?

Managed to figure it out after looking in the wiki for instructions to uninstall FOG with the intention of reinstalling it. Delete that file, delete the fogproject user, and run the install script again. Now it works.