FOG Project Image Capture on Raspberry Pi 4 (ARM64) via U-Boot

[Jeremy]

@Tom-Elliott Thanks for the feedback; I started the tests and got this:

1. Bugs 1 & 2 are 100% fixed!

• The kernel successfully unpacks the initramfs (Trying to unpack rootfs image as initramfs..., Run /init as init process).
• Broadcom SoC drivers, USB storage (/dev/sda - JMicron), and the internal NIC (bcmgenet -> eth0 Link is Up) are all working great.

2. Where it stops:
   After getting the network link up, FOS fails when trying to mount with the following errors on screen:

ext3: Unknown parameter ‘nolock’
ext2: Unknown parameter ‘nolock’
ext4: Unknown parameter ‘nolock’
vfat: Unknown parameter ‘nolock’
msdos: Unknown parameter ‘nolock’
f2fs: Unknown parameter ‘nolock’

It looks like FOS is passing the NFS nolock mount option when trying to probe/mount local filesystem types or local partitions. After these errors, the Pi reboots back to the U-Boot prompt.

Let me know if you need me to test a updated init containing a fix for the mount options!

[Tom Elliott]

@Jeremy That mount error is our bug. FOS was passing NFS mount options without
actually telling mount it was NFS, so when the storage path doesn’t come
through, busybox falls back to trying every local filesystem in turn and each
one rejects nolock — the ext2/ext4/vfat lines were never really involved.
Fixed and merged, and there’s a new experimental build below with it in. Test it
when you get a chance and let me know how it goes.

Two things when you do. Add isdebug=yes to your bootargs — mode=debug isn’t
our debug switch, so right now you’re getting rebooted back to U-Boot before you
can read anything. And send me the output of these from the failing boot:

uname -a
cat /proc/cmdline
cat /proc/filesystems

Your error listed f2fs, and our arm64 kernel is built without f2fs and without
module support, so it can’t have produced that. I think that boot was running
your kernel8.img with our init rather than our kernel — which would mean we
still haven’t actually tested the kernel fixes on real hardware.

wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_Image
wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_init.cpio.gz
wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_dtbs.tar.gz

All three are from the same build, so there is no mixing them up with what you
have now.

[Jeremy]

@Tom-Elliott

Hi! I downloaded the full updated pair from build EXP_20260826-143004 (arm_Image, arm_init.cpio.gz, and bcm2711-rpi-4-b.dtb from arm_dtbs.tar.gz).

I set the memory addresses exactly as requested:

• kernel_addr_r: 0x00080000
• fdt_addr_r: 0x08000000
• ramdisk_addr_r: 0x09000000

I also passed isdebug=yes in bootargs and removed the old kernel8.img / uInitrd references to ensure only the new build files are booted.

Result on real hardware (Pi 4B):
The Pi hangs indefinitely on the 4 Raspberry logos screen with a blinking cursor, right after U-Boot executes booti. No text output appears after the logos, and I am unable to type commands or reach the FOS shell, so I cannot run uname -a or cat /proc/....

It seems the kernel halts before initializing the console/framebuffer or hangs during early memory setup on real Broadcom hardware.

Let me know if you want me to test another build or change specific earlycon/console bootargs!

[Tom Elliott]

@Jeremy I found it, and it’s our bug. Our kernel is built without DRM, so it has
no vc4 driver and it depends on the firmware handing it a framebuffer the way
EFI does on a PC. On a Pi that doesn’t hold - our bcm2711-rpi-4-b.dtb has no
simple-framebuffer node, and the one the firmware would normally inject is
suppressed as soon as config.txt turns on the vc4-kms-v3d overlay, which current
Pi OS ships enabled. So our kernel had no way to write to your screen at all,
and a working boot and a dead one look exactly the same. That’s also why your
earlier test had output - kernel8.img has vc4 built in.

I’ve built the vc4 driver into our kernel. New build, same three files as
before, all from the one build:

wget https://github.com/FOGProject/fos/releases/download/EXP_20260827-114033/arm_Image
wget https://github.com/FOGProject/fos/releases/download/EXP_20260827-114033/arm_init.cpio.gz
wget https://github.com/FOGProject/fos/releases/download/EXP_20260827-114033/arm_dtbs.tar.gz

Boot it exactly the way you did last time - same load addresses, same booti
line, our DTB is fine now. One firmware note: the vc4 driver wants
avoid_warnings=2 in config.txt, otherwise the firmware can scribble over the
display setup.

All I need to know is whether you get text on the screen this time. If you do,
we’re past this and I’ll want the uname -a / cat /proc/cmdline / cat
/proc/filesystems output I asked for before. If it’s still blank, then it isn’t
the display and I’ll need serial to see what’s happening - but let’s find out
which it is first.

[Jeremy]

This post is deleted!

[Jeremy]

@Jeremy said in FOG Project Image Capture on Raspberry Pi 4 (ARM64) via U-Boot:

@Tom-Elliott

GREAT NEWS! The capture completed successfully!

Here is a summary of the steps and final configuration that made it work seamlessly on the Raspberry Pi 4:

1. Display Fix (Kernel side):
   Downloading build EXP_20260827-114033 with the integrated VC4 driver completely resolved the display freeze on the 4 raspberries logo. HDMI output initialized perfectly.

2. Ramdisk Format Fix (U-Boot side):
   Passing raw arm_init.cpio.gz via booti was triggering a “Wrong Ramdisk Image Format” error in U-Boot. Wrapping it into uInitrd with the following command solved the issue:
   mkimage -A arm64 -O linux -T ramdisk -C none -d arm_init.cpio.gz uInitrd

3. Final Working boot.cmd:

---

setenv kernel_addr_r 0x00080000
setenv fdt_addr_r 0x08000000
setenv ramdisk_addr_r 0x09000000

setenv bootargs console=tty1 loglevel=7 consoleblank=0 web=http://192.168.203.113/fog/ mac=dc:a6:32:c8:b4:33 osid=50 type=up img=ImagePi4 imgType=mps imgPartitionType=all storage=192.168.203.113:/images/dev/ storageip=192.168.203.113 fdrive=/dev/sda

tftp ${kernel_addr_r} 7efcf632/arm_Image
tftp ${ramdisk_addr_r} 7efcf632/uInitrd
tftp ${fdt_addr_r} 7efcf632/bcm2711-rpi-4-b.dtb

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

4. Imaging Status:
   Once booted into FOS, Partclone captured /dev/sda without any error and uploaded the full image to the FOG server!

Thank you so much for adding the VC4 driver and supporting ARM64 builds!

[Tom Elliott]

@Jeremy That’s the first time anyone has captured an image from a Raspberry Pi
with FOG, so thank you for sticking with it through three rounds of this. The
vc4 change is merged and will be in the next build.

One correction to your boot.cmd before someone copies it: you didn’t actually
need the uInitrd wrapper. The “Wrong Ramdisk Image Format” error came from
dropping the size off the ramdisk argument - without it U-Boot reads the address
as a legacy uImage and insists on a header. Either of these works:

booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

or the wrapper you built, which is fine as-is because you used -C none. That
part matters: -C gzip would have U-Boot decompress it and the kernel’s own gzip
support - the first bug we fixed in this thread - would never have been
exercised.

For anyone finding this later, the display problem was ours. We build without
DRM everywhere and rely on the firmware handing us a framebuffer, which is safe
on a PC because UEFI always publishes one. On a Pi it isn’t: our device tree has
no simple-framebuffer node, and the one the firmware would normally inject
disappears as soon as config.txt enables vc4-kms-v3d, which current Pi OS ships
turned on. So the kernel was booting fine the whole time and had no way to tell
anyone.

Worth saying plainly: your report exercised three separate fixes on real
hardware for the first time - the initramfs decompression, the ARM platform
support, and the NFS mount options. All of it had only ever run in QEMU before
you.

[Jeremy]

@Tom-Elliott

Thank you so much for the detailed explanation and for all your hard work on this!

It’s amazing to know that this was a first for the Raspberry Pi and FOG Project, and I’m really glad my tests helped validate those three major fixes on real hardware.

Good catch on the :filesize argument syntax for booti as well. That clarification will definitely be super helpful for anyone setting up ARM64/Pi deployments in the future!

Everything is working smoothly on my end now. Thanks again for the incredible reactivity and support.

The next test is to deploy the image to other Raspberry Pis; I’ll keep you posted.

[Jeremy]

@Tom-Elliott

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:

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

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

3. 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).

4. 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!

[Tom Elliott]

@Jeremy Stop the dd approach - it’s what’s breaking the disk, not the Pi.

Those .img files are not raw dumps. They’re zstd-compressed partclone streams;
check any of them and you’ll see the zstd magic 28 b5 2f fd in the first four
bytes. So dd’ing d1p1.img onto /dev/sda1 writes compressed bytes straight onto
the partition, which is exactly why the firmware then can’t read it as FAT.
That’s also why partclone.restore told you it wasn’t a partclone image - it was
looking at the zstd wrapper. FOS does this at funcs.sh:847:

zstdmt -dc /images/Raspberry/d1p1.img | partclone.restore --ignore_crc -O /dev/sda1 -N -f 1

One per partition. If the image was captured with a gzip format instead, swap
zstdmt for pigz -dc.

The MBR is wrong too. d1.mbr isn’t one sector - we capture everything up to the
first partition, capped at 1MiB, so it’s usually 2048 sectors. Your count=1
threw away everything between the boot sector and the first partition. Drop the
count entirely and let it write the whole file:

dd if=/images/Raspberry/d1.mbr of=/dev/sda bs=512

Now the more useful finding. “Fatal Error: Unknown request type :: Null” is
FOS telling you $type arrived empty, and that’s the same problem as your
missing osid - your bootargs are being truncated before FOS ever reads them. It
isn’t the kernel: arm64’s COMMAND_LINE_SIZE is 2048, the same as x86, and the
bootargs line you posted is 233 characters. Look at U-Boot’s own command and
console buffer instead, that’s where the ceiling is on your setup.

Which gets to the real limitation, and I’d rather be straight about it: FOG’s
server has no U-Boot support at all. boot.php emits iPXE, and nothing generates
a boot.scr, delivers a DTB, or builds arguments for a non-iPXE client. Every
variable you’re hand-assembling is one the server would normally hand the
client, and doing it by hand is why the ordering and length problems are yours
to fight.

Two ways forward. Keep hand-rolling U-Boot, in which case use the two commands
above and keep bootargs minimal. Or put UEFI firmware on the Pi (pftf/RPi4) so
it PXE-boots into iPXE like any other machine and the server drives the whole
thing - that’s the route that already works today, and it’s where native
support would build from.

Capture works, which is the half that was broken. Deploy needs the server side
to exist.