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

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

[Jeremy]

@Tom-Elliott

Hi, I’m using a Proxmox bridged network interface, I can’t connect anywhere else because otherwise it wouldn’t be the same network, so we’re trying to find a solution on our end.

[Jeremy]

@SimonGuenther

Hi, The blockage isn’t caused by a forgotten debug command, since that isn’t present in the deployment test; we have a managed switch right before the Raspberry Pi connection—that might be the issue. I’m discussing it with my colleagues at work to see how we can handle it.

[Jeremy]

This post is deleted!

[Jeremy]

This post is deleted!

[Jeremy]

@Tom-Elliott

OPNsense:

Option 66: I correctly entered the FOG server’s IP address.

Option 67: I entered the filename ipxe.efi.

Do I always need to keep ipxe.efi in OPNsense?

[Tom Elliott]

@Jeremy
Option 66 -> The FOG server or your TFTP Server.
Option 67 -> The Filename ALL machines should use for booting automatically.

I don’t think this matters in respect to the Raspberry Pi’s though.

[Jeremy]

@Tom-Elliott

Okay, thanks for the reply.

The OPNsense box does assign an IP address to the Raspberry Pi at startup—and it is always the same one, even though it is set to DHCP—but during the U-Boot boot process, it fails to find an IP address.

[Jeremy]

@Tom-Elliott

My Raspeberry is :

RaspberryPI 4 2GB Model B

The settings might vary depending on the model?

[Tom Elliott]

@Jeremy That’s a useful data point, and it says the same thing as before, more firmly: OPNsense hands the Pi’s firmware a lease every time (same address, so you have a static mapping, good), and the only DHCP client that fails is U-Boot’s, which runs seconds after U-Boot resets the network port. The DHCP server is fine. The reservation is fine. What differs is when the request happens relative to the port coming up, and that’s the managed switch your colleagues are now looking at. Nothing in OPNsense will change this.

You can test the whole FOG deploy today, without waiting for anyone. I asked for this last time and haven’t seen the result yet, so once more, because it matters: power the Pi on, let it fail and land at the U-Boot> prompt, wait until it has been powered for a full minute, then type boot. By then the switch port is forwarding, DHCP will bind at once, and standard boot will find your 01- file and pull arm_Image. Whatever appears after Starting kernel ... is the next thing I need to see. This is the same sequence that will run automatically once the switch is fixed; you’re only giving it the head start by hand.

Option 67: the Pi doesn’t use it. The Pi’s bootloader finds the TFTP server from option 66 / next-server and fetches its files by fixed names, and U-Boot’s pxe code only looks at the filename to work out a directory to prefix onto pxelinux.cfg/… — a bare ipxe.efi has no directory, so it prefixes nothing, which is what you want. Two cautions: don’t ever put a path with a folder in there (boot/ipxe.efi would make the Pi look for boot/pxelinux.cfg/01-…), and ipxe.efi as the single filename for all machines is wrong for your x86 fleet — BIOS machines need undionly.kpxe, UEFI ones ipxe.efi, and OPNsense has the per-architecture fields for exactly that. That’s a separate topic; it won’t affect the Pi either way.

One more thing so you don’t chase it: the advice above about mode=debug, running FOS on kernel8.img, VLANs and firewall rules between subnets was written against your old hand-typed setup and doesn’t apply any more. You’re on FOG’s own arm_Image via FOG’s own file now, on one subnet, and the FOG side is already proven on your server. It’s the switch port, then whatever the kernel says after it boots.