@pilipp_edv That should be enough I imagine, thanks for being thorough. I’ll take a look at the kernel config when I get a chance.

@pilipp_edv I had a very similar issue to this a while back but it was with an HP laptop. It turned out to be a hardware defect. I was able to get the motherboard replaced under warranty, so maybe you can too for this laptop.

fixed it by installing gcc-aarch64-linux-gnu on ubuntu and running the script again. compilation errors are not logged to the script shown on screen, but to the bin/error_logs/ directory in the extracted archive.
Update now ran without issues.

@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.

Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.

@pilipp_edv said in general questions about storage / master storage nodes:

After that, I configured the windows DHCP servers in the other locations to point to the main FOG server.

FWIW: You can (should) point the remote dhcp server to the remote storage node so the clients doesn’t need to transfer the ipxe boot image across your wan. The storage node will instruct the clients to “check in” with the fog master node.

The part you are missing is the FOG server plugin “Location”. With the location plugin you first identify your different locations. Then assign storage nodes to the “location” then assign existing client computers to the location. As you full register new clients there will be an added prompt for location during registration. This plugin pulls all of the bits together to make the clients find the proper storage node.