@Tom-Elliott

I can’t modify the company’s switches or other hardware since the system is in production. I’m currently rebuilding the FOG server on a VM on my PC and doing everything locally; it’ll be easier to troubleshoot that way. Gemini has wiped out all the previous messages and is giving me nonsense—I can’t seem to recreate the environment up to the capture stage anymore. Could you give me a rundown of everything that needs to be done—downloads, decompressing specific files in binary mode, etc.?

Thanks.

@Tom-Elliott

Here are the two screenshots of the requested tests.

@Tom-Elliott

I tried your test and am sending you a screenshot; I’ll keep testing on my end, and if I have any good news, I’ll let you know.

@Tom-Elliott

My Raspeberry is :

RaspberryPI 4 2GB Model B

The settings might vary depending on the model?

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

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

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

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

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

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

@Jeremy

I finally managed to configure the Raspberry Pi image capture; now I just need to fine-tune it to avoid having to enter these commands in the U-Boot terminal:

dhcp
tftp ${scriptaddr} boot.scr
source ${scriptaddr}

Now I’m back to working on the deployment, but I can’t seem to get an IP address via DHCP—I don’t understand why.

@Tom-Elliott

Hi, I ran into a problem: my VM completely crashed, so I have to start over from scratch. I’m still stuck at the capture stage; Gemini can’t review the entire conversation history we had to get to this point, though I had already reached U-Boot.

When I’ve completed this step, I’ll take a snapshot of the VM this time.

@Tom-Elliott

I’m also showing you screenshots of my host and image to see if I made a mistake.

@Tom-Elliott

Hey, I’m sending you the screenshot of the test.
I’m also sending you the configs to see if I made a mistake.
My colleague told me that STP would be enabled on the switch but not in OPNsense.

Config u-boot

cat /tftpboot/pxelinux.cfg/01-88-a2-9e-53-34-c0

cat /tftpboot/pxelinux.cfg/boot.scr

cat /tftpboot/pxelinux.cfg/default

cat /tftpboot/pxelinux.cfg/default-arm

cat /tftpboot/pxelinux.cfg/default.bak

@Tom-Elliott

I do have the filename you requested.

When U-Boot starts, DHCP doesn’t work; it spends 8 seconds searching. Sometimes, when rebooting the Raspberry Pi, it manages to obtain an IP address, successfully detects the server’s IP, and downloads pxelinux, but then stops.

What I don’t understand is why U-Boot sometimes manages to get an IP address and sometimes doesn’t.

@Tom-Elliott

Hi, I’m sending you the two screenshots—one from OPNsense and the other from the Raspberry Pi.

@Tom-Elliott

Here is an update following our latest troubleshooting sessions and tests:

The !V@JL artifact: That part was indeed a leftover artifact from editing the file manually with nano. Once cleaned up, we hit a regression: the Raspberry Pi no longer downloads the 563-byte config file at all anymore. It now loops directly on BOOTP broadcast and times out without hitting the TFTP stage (Retrieving file... doesn't trigger anymore).

Goal & Architecture: The target deployment must remain 100% cardless (no local storage, no SD card, no USB drive used during boot), relying purely on the RPi 4 network boot EEPROM + OPNsense DHCP + FOG/U-Boot.

Regarding your earlier notes on TFTP/Firewall:

    We are running UFW on the FOG server, and we verified that nf_conntrack_tftp is active (lsmod | grep tftp confirmed).

    BOOT_external_tftp_server is not enabled (TFTP runs locally on the FOG box).

    The Pi and FOG server are on the same subnet, with no intermediate restrictive ACLs on that local segment.

The permission fix: We noted your mention about the file permissions fix for downloaded files not being set properly after upload in the working-1.6 branch. Could this regression (dropping back to infinite BOOTP loops instead of attempting the TFTP fetch) be tied to how the file is currently served or indexed, or is there a specific way U-Boot expects the handoff after DHCP?