Categories

• Technical Help

  Get help with your FOG system.

  FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
  13k Topics

  115k Posts

  R

  Hi guys,

  Issue seemingly with a certain NIC type on some of our kit we’ve noticed for a while but only just been able to investigate fully. Wondering if anyone else has this issue with a similar

  FOG Version: 1.5.10.2149
  FOS Kernel: 6.18.38
  Init Version: 20260804
  Server OS: Ubuntu (master + 2 x storage nodes)
  Client Hardware: Dell OptiPlex 3070

  ISSUE UEFI image deployments run at around 1.2 GB/min (~100 Mbps) on Dell OptiPlex 3070 machines. Legacy/BIOS deployments on the same hardware and infrastructure run at 6-10 GB/min as expected. UEFI uploads (capture) are also fast at ~15 GB/min so the issue is specific to UEFI downloads only.

  THINGS ALREADY RULED OUT:

  Patch lead (swapped, no difference) Image compression (tested ZSTD and Partclone, identical speed) RAID vs AHCI (no difference) Storage node (tested all 3 nodes, same result) Dell BIOS (already on latest v1.35) iPXE boot file (tested ipxe.efi and snponly.efi, no difference) Kernel arg r8169.aspm=0 (no difference) Link speed (confirmed 1000Mb/s Full Duplex via ethtool)

  ROOT CAUSE IDENTIFIED lspci in a FOG debug task on the affected 3070 shows: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15) dmesg | grep r816 shows: r8169 0000:01:00.0 eth0: RTL8168h/8111h r8169 0000:01:00.0 eth0: jumbo frames [frames: 9194 bytes, tx checksumming: ko] r8169 0000:01:00.0 enp1s0: No native access to PCI extended config space, falling back to CSI r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control off The key issues are tx checksumming: ko and the CSI fallback, both known performance problems with the r8169 driver on RTL8168h rev 15 chips.

  SUSPECTED CAUSE I noticed this recent commit in the FOS repo: Switch x64/arm64 kernels to in-kernel r8169 for RTL8168/8125/8126 I believe this switch from r8168 to r8169 may have introduced the regression. This is documented in Debian Bug #1110193 (filed July 2025): https://bugs.debian.org/1110193 The reporter has identical lspci output and the same Rx-only slowdown, resolved by installing r8168-dkms.

  WORKAROUND Booting in Legacy/BIOS mode for imaging works but is not practical long term.

  REQUEST Would it be possible to revert the r8169 switch for RTL8168h rev 15 chips or provide an experimental kernel build with r8168 re-enabled? Happy to test any experimental builds and report back. r8168 driver code is already in the FOS repo at: https://github.com/FOGProject/fos/tree/master/KernelPackages/drivers/net/ethernet/realtek

  Thanks in advance guys.

• Announcements

  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!

• General Topics

  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.

• Developers

  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