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

[Tom Elliott]

@Jeremy Sorry about the VM. Take the snapshot, and also export the host and image from the web UI (Hosts → Export Host, Images → Export Image), so the next rebuild is an import rather than a retype.

Your screenshot is actually the best news so far, and it answers your “fine-tune” question with “there is nothing to type”:

U-Boot’s DHCP works now. DHCP client bound to address 192.168.203.77 (1 ms) — twice, once inside bootflow scan and once by hand. Whatever was blocking it on the old setup is gone. (The C0A8CB4D.img “File not found” right after is harmless: with no bootfile from DHCP, U-Boot guesses a name from its IP and fails to fetch it. setenv autoload no silences it, but you can’t save that without a card, and it costs nothing.)

bootflow scan is already doing the FOG boot path for you. Look at the top of your screen: after DHCP it asked the TFTP server for pxelinux.cfg/default-arm-bcm283x, then default-arm, then default (and, above what’s visible, 01-88-a2-9e-53-34-c0 first). That is pxe get — U-Boot runs it by itself as part of standard boot, no bootcmd, no environment, no boot.scr. Every one came back “File not found” because FOG only writes the 01-<mac> file while that host has a task queued, and nothing was queued. So the whole automation is: queue the task in the web UI, power the Pi on, done. No typing.

Drop boot.scr entirely. Wrong image format for "source" command is because your boot.scr is plain text; source only runs mkimage-wrapped scripts. You don’t need to fix that, you need to stop using it — the pxe path replaces it.

So, on the rebuilt server, please confirm two things and then do one test:

• FOG Settings → TFTP Server has a FOG_TFTP_ROOT_DIR entry reading /tftpboot. If it doesn’t, the install is older than the fix; run the updater on the beta channel.
• Queue a Deploy task for Raspberry-test, then on the server cat /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 — it should start # Generated by FOG Project and contain kernel arm_Image — and ls -l /tftpboot/arm_Image /tftpboot/arm_init.cpio.gz. Paste both here.
• Then just power-cycle the Pi and let bootflow scan run. It should now find the 01- file, pull arm_Image, and boot into FOS.

On “can’t get an IP via DHCP” during deployment: I need to know which DHCP. U-Boot’s is fine per your screenshot. If you mean FOS itself (after the kernel boots, the FOG banner, Attempting to check in never coming), that’s a different network stack — tell me which kernel booted (FOG’s arm_Image via the 01- file, or kernel8.img from your old script) and paste the lines around udhcpc / eth0. Text rather than a photo if at all possible; a serial adapter on the Pi’s UART pins makes that easy and is worth the few euros for a 200-unit project.

[Jeremy]

@Tom-Elliott

I created a new snapshot to avoid losing data again and having to start everything from scratch; right now, I’m stuck on this page on the Raspberry Pi.

[Tom Elliott]

@Jeremy That screen is the STP pattern, and I’m now fairly confident that’s your DHCP problem. Look at the timing: bootflow scan starts DHCP the instant the link comes up, retries for two cycles (about 20 seconds total), then gives up. Yesterday’s “1 ms” success was typed at the prompt after the board had been sitting there a while. A switch port running classic spanning tree drops everything for roughly 30 seconds after link-up. First 20 seconds: nothing gets through; a minute later: instant lease. That matches every screenshot you’ve posted.

U-Boot can’t be made to wait longer without a saved environment, and without an SD card you can’t save one. So this is fixed on the switch, not on the Pi: ask whoever runs it to enable PortFast (Cisco) / edge port (most others) on the ports the Pis plug into, or move to RSTP. That is a normal setting for any PXE client, not a Pi special case. If you want proof before asking, plug the Pi into a dumb unmanaged switch for one boot; if bootflow scan gets a lease first time, you have your answer.

Two more things from that screen:

• 0 Storage Device(s) found. Last time it found 1 (the USB SSD). If the SSD isn’t attached, there’s nothing to deploy to, so make sure it’s plugged in and powered for the deploy test.
• I still need the three things from my last post, and I can’t go further without them: whether FOG_TFTP_ROOT_DIR exists in FOG Settings → TFTP Server; the contents of /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0 after you queue a Deploy task; and ls -l /tftpboot/arm_Image /tftpboot/arm_init.cpio.gz. Those tell me whether the FOG side is doing its job on your rebuilt server. Everything else in this thread is now on the network side.

[Jeremy]

@Tom-Elliott

Regarding OPNsense, there isn’t anyone on the infrastructure team available to look into it right now; I can probably check on that Monday morning.

To be transparent with you, I’ve been retraining for a new career since February 2026 and only just obtained my IT diploma in July. What helps is that I’m persistent with projects and usually manage to get the job done. I’ll get back to you once I have the information regarding OPNsense.

[SimonGuenther]

@Jeremy Haven’t done this on a Pi specifically, so take this as pointers rather than a known fix, but a few things jump out.

First, if udhcpc is already getting a lease, then the FOS init is running, so it’s not really a kernel hang, it’s stopping somewhere in the init scripts after network up. Which makes me look straight at mode=debug in your bootargs. Debug mode in FOS is interactive, it waits for you to hit a key or type at a shell before it does anything. If the console you’re watching isn’t the one it’s prompting on, that looks exactly like a hang. I’d drop mode=debug for a run and see if it moves on, and separately get a serial console on the Pi (enable_uart in config.txt, add console=serial0,115200 alongside your tty1) so you can actually see where it stops instead of guessing from HDMI.

Second, you swapped the kernel but kept the stock FOS initrd. That’s fine in principle, but the FOG init was built against FOG’s own kernel config. Worth checking that the Pi kernel has everything the init expects when it mounts root from /dev/ram0 with that ramdisk_size, and that nothing later in the init is relying on a module or kernel feature the Pi build doesn’t ship. A serial log with loglevel=7 will tell you quickly.

Third, unrelated to the hang but it’ll bite you right after: for a capture (type=up) FOG normally points storage at the dev share, storage=IP:/images/dev/, not /images/. The image gets moved into /images/ by the server once the upload finishes. If you hand rolled the bootargs from a deploy example, that one’s easy to miss.

Also, since the target is a single USB SSD, you might get more mileage checking whether the FOS init even handles /dev/sda as a capture target the way you’d expect on ARM, but that’s step two. Get it past checkin first. Would be good to hear if Tom or Sebastian have opinions on running FOS with a non FOG kernel, I don’t think that’s a path many have gone down.

[Tom Elliott]

@Jeremy If you can put a dumb switch between the Pi and the cable you currently connect into:

Connect the cable you normally plugin to the Pi into the 5 port switch then your pi to that switch and this should test the connectivity STP problem I believe is occurring.