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

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 ?