Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @Fog_Newb As to “a bunch of stuff deleted”

    Yes, in the past we shipped all the ipxe binaries we natively built with FOG, then those would end up being rebuilt if https.

    The process is still the same, but I decided to update to iPXE 2.0.0 and split the repo so we have a central point for new builds (similar to now Kernels/Inits are done as well) and worked very hard to begin basic level support for Secure boot capabilities.

    The SB enabled part still (as it stands today) requires enrolling the key on each machine (so still tedious) but we build the key, provide a UI bit of information to what needs to do and that was part of why you see the “many files deleted” in short.

    So yes, lots of changes, all expected.

    I would ask, if you don’t mind, upgrading to 1.6 and see if that fairs a little better as all these new things also got put in there, but there’s also a lot more I think most poeple might actually enjoy.

  • 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
    8

    @Cpasjuste

    Thank you, I appreciate that. And yes, I did spend a lot of time on it.

    I agree that it bypasses the official installer in order to make use of Docker environment variables; however, at this stage, I don’t believe that FOG is going to change so dramatically that it’ll break it often.

    I will add that if this could get adopted as an official docker image, we could work with the FOG team to make sure nothing gets to pushed to the FOG code that would break the container until we can adjust the container as well.

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

    Hi everyone, / @george1421

    I’ve been trying to capture the SD card of a Raspberry Pi 4 and I’ve hit a wall. I am booting via a USB stick using the EDK2 UEFI firmware, and I have explicitly set the System Table Selection to <Devicetree> in the UEFI settings.

    I managed to get past the iPXE phase without issues, and the capture task successfully loads the FOS kernel and init. However, the boot process stops right after with the following error (see attached image):
    No network interfaces found, your kernel is most probably missing the correct driver!

    Current Setup & Debug info:

    FOG version: 1.5.10.2149

    Hardware: Raspberry Pi 4 (trying to capture the built-in SD card)

    Boot method: USB stick with UEFI firmware

    Kernel version: 6.18.38

    Init version: 20260726

    (No PCI network hardware detected - obviously, as it’s the SoC’s built-in NIC)

    I think it seems the current experimental ARM kernel is missing the built-in Pi 4 network driver (bcmgenet). Unfortunately, using an external USB-to-LAN adapter is not an option for me, as the UEFI firmware refuses to boot from it in my environment.

    My question is:
    Given that I am booting from a USB stick and making it exactly to this point in the capture task, is there any chance or workaround to successfully capture the Pi 4’s SD card? Is there a custom/specific kernel available that includes the built-in Pi network driver, or any other method I can use to bypass this missing driver issue?

    Any help or guidance would be greatly appreciated!
    20260803_152648.jpg

93

Online

12.7k

Users

17.6k

Topics

156.8k

Posts