I’ve been working on deploying images to a Raspberry Pi 4 (ARM64) using FOG (version 1.5.10.2254, FOS kernel 6.18.38), and I wanted to share our findings, encountered errors, and current limitations we faced during the process. Hopefully, this can help improve native ARM support or guide others trying to achieve unattended RPi deployments.
Here is a summary of what we experienced and how we bypassed it:
U-Boot bootargs Buffer Overflow
Issue: When adding extra environment variables to bootargs inside boot.cmd (such as custom storage IPs, disk targets, or MAC addresses), the ARM64 kernel command line exceeded the maximum allowed size. This caused the kernel boot process to silently halt right after the network interface came up (Link is Up).
Workaround: Kept the bootargs string as minimal as possible and relied on FOG web settings where applicable.
Missing osid Parameter
Issue: FOS initialization stops with No os id passed (determineOS) and reboots if the kernel parameters do not explicitly provide osid=50 (or the corresponding OS ID) alongside type=down.
Workaround: Explicitly appending osid=50 type=down in the U-Boot script parameters.
FOG Automatic Script Orchestration vs. ARM Multi-Partition Layout
Issue: Even when successfully booting into FOS and passing the correct variables (img=Raspberry, storage=…, fdrive=/dev/sda), the automated fog script skips or fails to correctly parse multi-partition layouts on USB/SD external drives (/dev/sda), directly jumping to “Task Complete” without actually writing data via Partclone or triggering errors like Fatal Error: Unknown request type :: Null.
Workaround: We had to enter FOG Debug Mode (isdebug=yes), export variables manually (export storage, export img, export type=down), and notice that FOG’s single-partition versus multi-partition routines expect specific raw file structures (d1.mbr, d1p1.img, d1p2.img).
Raw Image Files (.img) vs. Partclone Format
Issue: When attempting manual deployment via partclone.restore, Partclone throws This is not partclone image because FOG stores standard multi-partition RPi captures as raw binary dumps (.img) rather than compressed partclone streams.
Workaround: Restoring the MBR and partitions required direct block-level commands:
Bash
dd if=/images/Raspberry/d1.mbr of=/dev/sda bs=512 count=1
dd if=/images/Raspberry/d1p1.img of=/dev/sda1 bs=4M status=progress
dd if=/images/Raspberry/d1p2.img of=/dev/sda2 bs=4M status=progress
Result: While the partitions are written, the RPi firmware still struggles to directly boot the resulting USB structure (Unable to read partition as FAT), indicating that standard FOG MBR generation (d1.mbr) doesn’t align cleanly with RPi’s expected GPT/FAT bootloader requirements for USB-MSD booting.
It seems the automated deployment engine (fog script) inside FOS needs specific adaptations for ARM/Raspberry Pi multi-partition disk imaging (handling fdrive=/dev/sda and raw dd-like partition layouts seamlessly).
Any insights or recommendations on how to properly handle native RPi deployments through FOG would be greatly appreciated!
