@Jeremy Thanks for running it. The model doesn’t change anything: a Pi 4 Model B is what all of this was written for, and 2 GB is plenty.
From the screenshot I can’t tell whether the minute had passed before you typed boot (it looks like it went straight after the first failure). But rather than argue about seconds, let’s get the one measurement that settles this, and it needs nothing from the infrastructure team: watch the DHCP traffic from the FOG server, which sits on the same network and sees every broadcast.
On the FOG server, as root, start this and leave it running:
tcpdump -ni any -e port 67 or port 68Then power-cycle the Pi and let U-Boot do its BOOTP broadcast loop. You’ll see one of three things:
Nothing at all from 88:a2:9e:53:34:c0 while U-Boot is broadcasting → the frames never leave the Pi’s switch port. That’s the switch (STP or port security), full stop. Hand that to your colleagues with the capture. Requests arrive but no reply comes back (lines from the Pi’s MAC, none from OPNsense’s) → OPNsense is receiving and ignoring them. Then it’s a DHCP-server question, and the OPNsense DHCP log for that MAC at the same moment will say why. Request and reply both appear, but U-Boot still says “Retry time exceeded” → the reply is being dropped on the way back or U-Boot isn’t accepting it. Rare, but it points at the switch again, or at the MAC below.Copy the tcpdump lines here as text (that’s a terminal, so no photo needed).
One more thing to check at the U-Boot> prompt, since it costs ten seconds:
printenv ethaddrIt must read 88:a2:9e:53:34:c0. U-Boot takes it from the firmware; if for any reason it shows something else, OPNsense’s reservation won’t match, and if your DHCP scope has no dynamic pool that alone would produce exactly this. I don’t expect it, but it’s cheap to rule out.
Once DHCP binds, the rest of the path is already proven on your server, so this really is the last gate before you see FOS boot.