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

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

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

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.

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 ?

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