Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

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

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    K

    @jmeyer The first screenshot, I can’t really say what’s wrong beyond for some reason, shim either immediately exits or doesn’t start so the EFI instead moves onto the next boot option which is IPv6.

    The second one, MOK.DER is being loaded, but mokmanager itself (which does the enrolling) is failing to load. Exec format error is usually caused either by trying to load a binary built for the wrong architecture (e.g arm on an x86 CPU) or when you have Secure Boot enabled, but the binary you’re trying to load isn’t signed by one of the keys enrolled in the firmware.

    So, for the second one, double check that you have the Microsoft keys enrolled in the firmware, or try it with secureboot off and see if that fixes it.

    I’m not quite sure what to suggest for the first one, other than maybe try network booting with secureboot off to the standard snponly.efi binary.

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    Tom ElliottT

    @Valer I think we need to understand what this plugin is doing.

    CSS isn’t something we’ve allowed to be injectable though it could be.

    You can still use your own CSS but that’s more at the FOG Configuration -> FOG Setting -> FOG_THEME, but you would need to put it on your server in a location you type the path too here.

    https://docs.fogproject.org/en/latest/development/plugin-development

    This is a good toolkit for understanding how to build your own plugin.

56

Online

12.8k

Users

17.6k

Topics

157.0k

Posts