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

@Tom-Elliott I’m sorry. I restored a previous version of the FOG server and no longer have any error logs from when all this happened. I can go to 1.6… IIRC there is a change that needs to be made to SSHD conf or something. The last time I went to 1.6 FOG was unable to see the default storage node.

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

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

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.

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