@Tom-Elliott Hi, Yes with the proposed fix, it works now.

@rpycroft Please attempt to update to 2231.

Working 👍

** WARNING: /etc/exports still exports with no_root_squash.
** Captures land as root, so moving the image out of
** /images/dev fails with ‘550 Rename failed’.
** Replace the /images/dev export options with:
** all_squash,anonuid=1002,anongid=1002

Fixed problem

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

@Valer Thanks for the report and the writeup, that’s a good catch. You’re right about the cause. Debian 13 dropped the sysv-rc-conf package since it’s fully on systemd now, so the installer chokes trying to apt-get it. We never actually use that tool on a systemd system anyway, it only ever got called on the old non-systemd paths, so it was just dead weight on Trixie.

I pushed a fix to working-1.6. It leaves the package off the list on Debian 13 and up, and it also strips it out of a cached .fogsettings so an in-place upgrade doesn’t drag it back in. Older Debian keeps installing it like before so nothing changes there.

If you want to get moving before you pull the update, you can either grab the latest working-1.6 and rerun the installer, or just open /opt/fog/.fogsettings and delete sysv-rc-conf from the packages line, then run the installer again. Either one gets you past it.

Let me know if you hit anything else on Trixie.

@Tom-Elliott Thanks for the clarification! I’ll try upgrading to the latest stable version, I was planning on doing this anyway.

I’ll look into the Persistent Groups plugin and see how it works!

@mashina Ah, thank you for that and sorry for my denseness. Indeed this is a bug and I’ve replicated and figured out where this is occurring.

I have pushed a few mroe adjustments in an attempt find and fix more bugs (thanks AI review and whatnot)

Please pull and let me know if there’s any other issues.

Okay - So what killled this installation was the fact a 1.5.9 csv load was imported into my 1.5.10.1698 FOG - this killed a bunch of features and I eded up having to reinstall.

@rodluz yes, directly from 1.5.10.1754 to 1.5.10.1763 when I saw the prompt in the FOG gui that I’m not using the latest version - it was up to date before.

in 1.5.10.1754 recapture didn’t added up, just updated the image size to the latest one.

@Clebboii Following up if you’d be willing to let us know?

Thank you!

Also occurring on Dell Latitude 5450 laptops.

@sgennadi
Fixed by
touch /images/dev/.mntcheck

Can you help me with bug topic ?
Fog 1.6.0-beta.2141 remove folder with image

@Tom-Elliott Cheers, works as expected now!

Thank you!

Ok, nevermind, did the git thing, got it working, cheers 🙂

@Tom-Elliott cheers - looks like someone changed working branch in 2019 to add hdbios, and it’s not something that’s in the dev branch either!

@Tom-Elliott Thanks, going to switch back to 1.6 very soon.