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