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

[Jeremy]

@Tom-Elliott

I checked both database entries for hostKernelArgs, and isdebug=yes was indeed not present there.

Regarding the U-Boot wget error, I followed your suggestion and went to the U-Boot prompt (=>) on the Raspberry Pi. When I type wget, it responds with:
Unknown command wget try help

So it seems the U-Boot build on these Raspberry Pis does not have the wget command compiled into it at all. What would be the recommended fallback or alternative method to fetch the script from FOG in this case (e.g., using TFTP or an alternative command if available)?"

[Tom Elliott]

@Jeremy Good, that narrows it down — no wget at all in this build, not just the older syntax. Two ways to close that:

Rebuild U-Boot with wget compiled in (keeps you on the dynamic per-host endpoint). CONFIG_CMD_WGET is a plain menuconfig option — you don’t need the HTTPS variant, which pulls in the whole lwIP/mbedTLS stack, just plain HTTP:

make rpi_4_defconfig
make menuconfig # Command line interface -> Network commands -> wget
make

Reflash the resulting u-boot.bin. Since dhcp already works for you, the network stack is there — this just turns on the one command. Once it’s in, the sequence from before should work as documented.

Or skip the dynamic endpoint and hand-roll a static boot.cmd — which is exactly what already worked for your capture: plain tftp for kernel/initrd/dtb, fixed bootargs with the task’s mac=, osid=, type=, img=, etc. baked in. The real tradeoff: tftp doesn’t ask FOG anything, so that config is identical for every board that boots it. Fine if every Pi runs the same task; not fine if you need FOG to decide per-host. boot.php exists specifically to answer “what does this MAC need right now” dynamically, and there’s currently no TFTP equivalent of it for boards that can’t do HTTP — that’s a real gap on FOG’s side, not something you’re doing wrong.

For 100+ boards I’d lean toward rebuilding U-Boot rather than going static, since you keep per-host tasking either way — but that’s your call based on how uniform the fleet’s deployment actually needs to be.

[Jeremy]

@Tom-Elliott "Hi again,

Following your instructions, I checked the U-Boot prompt. When typing wget, it responds with:
Unknown command wget try help
So the U-Boot build on these boards does not include the wget command.

Also, for context on how the board behaves at boot, here is what happens visually during the startup sequence (attached photo): it tries to boot locally, times out on storage (mmc / usb), and then falls back to a standard network BOOTP broadcast loop (Retry time exceeded).

Given that U-Boot lacks wget and relies on standard BOOTP/PXE broadcast rather than direct HTTP fetching, what is the recommended way or fallback mechanism to have these boards pull their configuration from FOG?"

[Tom Elliott]

@Jeremy Good news on the wget front — I closed that gap I mentioned. FOG can
now serve boards with no wget at all, over plain TFTP instead of HTTP.

U-Boot’s pxe get command doesn’t need wget — every U-Boot build has it,
and unlike wget it isn’t configurable: it always fetches
pxelinux.cfg/01-<mac, dash-separated, lowercase> by TFTP from whatever
server your board’s serverip points at. FOG now keeps a real file at that
path for every host, kept in sync automatically whenever a task is queued,
completed, or canceled — so your boot sequence becomes just:

dhcp
pxe get
pxe boot

No URL, no query string, nothing for the “bad port”/no-wget class of problem
to trip over — the filename is fixed by the MAC, so there’s nothing to
substitute.

This just merged into working-1.6 — same branch you’re already tracking
(you quoted 1.6.0-beta.4707 a few hours ago; this landed after that), so
running your update again should pick it up. Two things to check once you
have:

• Settings → FTP/TFTP needs a TFTP host/username/password configured — same
  connection FOG already uses to upload your ARM kernel, so if that’s
  already working for you, you’re set.
• I still don’t have a Pi to test this against, same as everything else in
  this thread — if pxe get doesn’t find the file, or finds one FOG didn’t
  mean to serve, that’s exactly the kind of thing I need you to report back.

One thing from your last post I want to flag separately, because it looks
like a different problem from the wget one: the boot sequence you
described — times out on local storage, then falls into a BOOTP broadcast
loop that gives up with “Retry time exceeded” — reads like U-Boot’s own
default bootcmd running, not a custom one. That’s the standard
Raspberry Pi fallback behavior when nothing else answers, and it wouldn’t
run dhcp / pxe get / pxe boot at all, custom or not.

Everything you’ve described testing so far — the wget/pxe boot sequence,
the curl check, now pxe get — sounds like it’s been typed by hand at the
=> prompt each time. That proves the commands work, but it can’t be “fully
automated,” which was the goal from your very first post: nothing runs
automatically unless it’s persisted as bootcmd, either with
setenv bootcmd '...'; saveenv on the board itself, or as a boot.scr /
extlinux.conf your SD card or TFTP server hands U-Boot on its own at power-on.

Can you confirm which of those two you actually have in place right now? If
the answer is “neither yet — I’ve only been testing at the prompt,” that’s
probably the real blocker to automation, independent of wget vs. TFTP, and
worth sorting out before we look any further at the fetch mechanism itself.

[Jeremy]

@Tom-Elliott

"To answer your question directly: yes, so far I have only been testing manually at the U-Boot prompt (=>).

My main concern right now is scalability. Since I need to deploy this across a fleet of 100 to 200 Raspberry Pi units, configuring each SD card manually or typing commands at the prompt for every single machine is not an option.

What is the recommended best practice in FOG working-1.6 to handle automation for a large fleet? Can the bootcmd be permanently stored in the Pi’s onboard EEPROM once, or can U-Boot fetch a boot script via TFTP automatically without manual card preparation?"

[Jeremy]

@Tom-Elliott

"Hi again! Great news regarding the new TFTP fallback mechanism.

I tested it manually by setting the IP addresses:
Plaintext

setenv ipaddr 192.168.203.50
setenv serverip 192.168.203.113
pxe get

What happened:

U-Boot successfully found the correct path generated by FOG based on the MAC address (Retrieving file: pxelinux.cfg/01-88-a2-9e-53-34-c0).

However, the download times out (Loading: T T T T T T) and results in a Retry count exceeded.

For context: a deployment task was explicitly active and queued in the FOG web interface before running the test, so the file should be there.

Is there a specific TFTP block size or setting required in working-1.6 for U-Boot’s pxe get to successfully pull the file without timing out, or could it be related to firewall/TFTP service configuration on the server side?"