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

@Matthiman Your issue appears similar to an issue that’s being described here:
https://forums.fogproject.org/topic/18213/version-1-6-0-beta-3187-ipxe-2-0-0-x-problems

Though they seem to indicate changing to an older bootfile (snponly.efi/ipxe.efi whatever) worked so it’s not a kernel/init issue that’s happening causing this to occur.

This may be what’s happening with everyone in this thread as well, but the first image that I see from Fog_Newb looks more like what I’d expect where there’s not enough ram available to load.

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

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

@JJ-Fullmer My version is 270. Do you still want me to try updating PHP to 8.3?

2b08c072-e93f-40b2-b2e2-43226ebf9d98-image.png

@Lucas26 Thanks for letting us know and should be fixed in the latest.

Also found a similar class of bug for FTP ports and we are porting the FTP side to dev-branch as we speak.

Please let us know if this is working now?

@JJ-Fullmer This was it, thank you!!

Everything I read kept telling me this machine was x86 based and there is no hint in the BIOS or the serial number lookup tool, of it running an ARM processor(other then “Elite”). We are going to return these machines to the vendor, so problem solved for us.

Would be interested in hearing about future support for ARM in FOG because I’m sure this isn’t the last time we will cross paths with it.

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.

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

@Tom-Elliott Hello Tom yes I have installed the compatible Fog client from the Fog server on the reference machine, sys prepped and captured the image and now I am deploying.

@Tom-Elliott
Updated to latest dev-branch and snapins are working now
Thansk for help.

@Numa09
I had the same problem with a TP-Link switch. The model was a TL-SG2428P, and the FOG client would get stuck at:

“Running post init scripts…”

There were no error messages on the server, and the server firewall was disabled.

After seeing your comment, I disabled the DoS protection feature on the switch, and FOG started working normally.

Thank you, man!

@DiegoP I believe mdadm will still be allowed to work, but I think you’re supossed to use “mdraid=true” for a kernel argument. If this is not set, FOG won’t know to build the array. This would help explain why the disk couldn’t find a partition layout as well since it’s expecting to be part of an array (which then looks/acts as the disk you’re truly working with.

As for “partclone to partimage” I’m not sure I understand.

Fog moved FROM partimage -> partclone way back in the 1.0.0 days as partimage has been obsolete for quite some time now.

To check the BitLocker status, open an elevated Command Prompt and run:

manage-bde -status

If the C drive shows as encrypted, disable BitLocker and allow the drive to fully decrypt before attempting another capture:

manage-bde -off C: manage-bde -off D:

Have you tried setting the image type to “Multiple Partition Image - All Disks (Not Resizable)” instead of “Single disk - resizable”?

In “Single disk - resizable” mode, you will save an image of only one of the two disks. In the host settings, you can set the primary disk.

Try disable Windows Fast Boot or restart computer from cmd

shutdown /r /t 0

UPDATE 07/17/2026

After some experimentation and examining the fogftp.class.php file, I found that FOG calls ftp_rename to move files from the /image/dev/<mac_host> folder to the /image/<image_name> folder.

Finally, it helped me to connect with a regular ftp client (WinSCP) and try to move the folders manually. This is how I found out that the problem was in the permissions set on the folders.

So I found out that from my original version 1.5.10.10 to the current 1.5.10.1903 there was a change in the file

/lib/reg-task/taskqueue.class.php

in the private function _moveUpload() method it was previously

->chmod(0777, $dest) and now it is ->chmod(0775, $dest)

That (maybe) could be the reason why it stopped working for me. Thanks to this post https://forums.fogproject.org/post/156271

chown -R fog:users /volume1/images/ #set inheritance to the dev folder chmod g+s /volume1/images/dev/

I connected to the NAS with ssh and fixed the permissions over the folders. Now it’s working fine again.

@Tom-Elliott

Thanks for your quick response. We’ll be using Fog heavily over the next few days, so we won’t be able to update the version right away.
We’ve found a workaround while we wait for the update by setting the setgid bit on the directory:

chown fog:fog /images/dev
chmod 2775 /images/dev

Best.

Jérôme

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!

Thank you!

With the experimental init.xz when it said the following in my case: “Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)” does this mean the following command was run?: nvme sanitize /dev/nvme0n1 -a 2

Does this mean the bug is patched? Should I use the experimental init.xz file on the production FOG server? What ramifications will this have? Is it better to wait until this is released in an official version down the road?