Categories

  • Get help with your FOG system.
    FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
    13k Topics
    115k Posts
    Tom ElliottT

    @rpycroft That’s the confirmation I needed, thank you. 1.2 to 6.5 GB/min is
    the fix working. The change is merged now, so it’ll be in the next kernel
    release rather than something you have to keep hand-installing.

    Two corrections from my end.

    First, tx checksumming: ko was never broken. That line is about jumbo frames –
    it’s the driver saying this chip can’t do TX checksum offload if you enable
    jumbo, and at a normal 1500 MTU it never applies. It’s printed based on the
    chip model alone, so you’ll still see it on the new kernel. Don’t let it worry
    you when you spot it again. Your ethtool output was very likely the same before
    the swap; there was nothing to fix there.

    Second, I got two details wrong in the setpci commands I posted. My apologies.
    The write should be masked so it only touches the two ASPM bits – as I wrote
    it, it would have cleared the whole Link Control register, including the common
    clock configuration, which you don’t want to disturb on a live link. And the
    order was backwards: the spec wants L1 switched off at the NIC before the root
    port, not the other way round.

    Reading the current state (this part was fine):

    setpci -s 02:00.0 CAP_EXP+10.w setpci -s 00:1c.5 CAP_EXP+10.w

    Only the last hex digit matters:

    0 4 8 C -> ASPM off 1 5 9 D -> L0s 2 6 A E -> L1 3 7 B F -> L0s + L1

    And clearing it, NIC first, masked to the ASPM bits:

    setpci -s 02:00.0 CAP_EXP+10.w=0000:0003 setpci -s 00:1c.5 CAP_EXP+10.w=0000:0003

    If you did already run the originals, nothing you’ve reported suggests any harm
    came of it, and a reboot clears the lot either way.

    No pressure on this next bit at all – the fix is confirmed and merged, and
    this doesn’t gate anything. But if you ever have one of those 3070s spare, the
    read-only pair above run once under UEFI and once under legacy would tell us
    why the two differ. My theory is the Dell firmware enables L1 on the UEFI
    path and leaves it off under CSM, which would explain everything you saw, but
    that’s still me inferring rather than knowing. Genuinely optional – if it’s
    easy, great, and if not, don’t spend your time on it.

    Thanks again for testing this so quickly.

  • Get the latest news on what's happening.
    Security Advisories
    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.
    General Tutorials
    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.
    General Feature Request Bug Reports
    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

119

Online

12.7k

Users

17.6k

Topics

156.8k

Posts