@Tom-Elliott

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

@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 got my IT diploma in July. I’m still building experience, but one thing I know about myself is that I stick with projects and usually find a way to get them finished. I’ll get back to you once I have the information regarding OPNsense. Tropical Casino https://tropical-casino.com/ gives me a similar mindset with game rules and account settings: if something isn’t clear, I’d rather work through it properly than pretend I already know the answer. I’d rather be accurate than fast.

Thanks for bearing with me on this. While I wait to get someone from the infrastructure side to look at the OPNsense box, is there anything specific you’d want me to check on it so I can come to Monday with the right information?

My assumption is that once the kernel brings the NIC up and pulls a DHCP lease, the init scripts then need to reach the FOG server over HTTP (the web= address) and NFS for the image storage. If the Pi and the FOG server are sitting on different subnets or VLANs, I’m wondering whether OPNsense could be dropping that traffic at exactly the point where it hangs, right after “Link is Up” and before fog.checkin ever runs.

If that’s a plausible direction, I can have them check the firewall rules and live logs for anything blocked between the Pi’s subnet and the server on the relevant ports. If you think it’s more likely something else entirely, let me know what you’d prioritise and I’ll chase that instead. Either way I’ll report back once I’ve been able to get onto the OPNsense side.

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