@maxcarpone I had the same problem with 2390 and reverted to an older back up. That version was broke AF

@Jeremy The build is up, and it turned out there were two separate bugs, not one.

Bug 1: our arm64 kernel couldn’t unpack our own arm64 init. The kernel had gzip
initramfs support switched off while the init we publish is arm_init.cpio.gz. I
checked a released arm_Image with extract-ikconfig to be sure and it’s real. That
pair has been unable to boot since January 2021, when a cleanup commit pruned “unneeded
initrd compression algos” from all three kernel configs. Correct for x86, wrong for arm64,
and nobody caught it because almost nobody boots the arm64 build.

Bug 2: our arm64 kernel didn’t describe an ARM platform at all. No CONFIG_ARCH_BCM,
so no Broadcom SoC and no Raspberry Pi anything. That’s the missing NIC you found. It also
had no PL011 UART and no generic PCI host bridge, so it had no serial console and no PCI
bus on basically any arm64 machine. The config was added in 2018 by someone who said in
the commit message that they couldn’t test it, and eight years of make oldconfig carried
it forward untouched.

Both are fixed and merged. The kernel now has BCM2835/2711/2712 support, which covers Pi 3
through Pi 5: the VideoCore firmware and mailbox chain, the SD card controllers, bcmgenet,
lan78xx and smsc95xx for the older boards, macb for the Pi 5’s RP1, PCIE_BRCMSTB, and the
SoC watchdog (FOS reboots through that at the end of a task, so without it a client
finishes and just sits there).

I’ve tested it under QEMU as far as QEMU can go: the new kernel unpacks the released init
and boots all the way into FOS userspace, and with a virtio NIC it gets an IP. The old
kernel produces no console output at all on the same machine. What QEMU can’t test is
any of the Broadcom code, because its Pi 4 model disables the PCIe, genet, RNG and thermal
blocks. That’s the part I need you for. None of us has a Pi.

Testing it

Good news: don’t change your setup. Keep the U-Boot chain you already have working. We’re
not asking you to switch to iPXE yet, I just want to know whether the kernel runs on real
Pi hardware.

1. Get the files # the new kernel wget https://github.com/FOGProject/fos/releases/download/EXP_20260825-141730/arm_Image # the init - unchanged, but grab this exact one, it's the pair I tested wget https://github.com/FOGProject/fos/releases/download/EXP_20260819-141018/arm_init.cpio.gz # device trees, if you'd rather use ours than the one you have wget https://github.com/FOGProject/fos/releases/download/EXP_20260825-141730/arm_dtbs.tar.gz tar xzf arm_dtbs.tar.gz # gives you broadcom/bcm2711-rpi-4-b.dtb

Drop arm_Image and arm_init.cpio.gz into your 7efcf632/ TFTP directory. Your existing
DTB is fine, ours is just there if you want it.

2. Skip the uInitrd wrapper

You can hand the gzip file straight to booti and skip mkimage entirely:

tftp ${ramdisk_addr_r} 7efcf632/arm_init.cpio.gz booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

I’d rather you did it this way for this test. If you wrap it with mkimage -C gzip,
U-Boot may decompress it before the kernel sees it, and then we won’t have tested the
decompression fix at all. If you’d rather keep uInitrd, build it with -C none so
the gzip bytes get passed through untouched.

3. Move your load addresses

This one matters. Your current layout puts the DTB at 0x02600000, which is 38 MB in,
and the kernel at 0x00080000. The new arm_Image is 30 MB and its BSS runs past the end
of the file, so it can land on top of the DTB and you’d get a hang that looks exactly like
the one you’re already seeing. Give it room:

setenv kernel_addr_r 0x00080000 setenv fdt_addr_r 0x08000000 setenv ramdisk_addr_r 0x09000000

You can drop kernel_comp_addr_r and kernel_comp_size. Those are for a compressed
kernel and arm_Image isn’t one.

4. Fix the bootargs

There are four real mistakes in what you have, and one addition that will save you a lot of
time:

storagedev=/dev/sda isn’t a thing. FOS ignores it. The variable that picks a disk
is fdrive=. That’s the “Host Primary Disk” field in the web UI. storage= is pointing at the wrong share. A capture writes to
192.168.203.113:/images/dev/. /images is exported read-only, /images/dev is the
writable one, so as written the upload will fail on permissions after a long wait. web= needs the scheme: web=http://192.168.203.113/fog/. curl usually guesses,
don’t rely on it. mode=debug does nothing here. FOS only reads mode= when type= is empty, so with
type=up it’s ignored. The one you want is isdebug=yes, which drops you to a shell
and pauses after every step. Use it for this first test, it’ll show you exactly where
things stop.

So:

setenv bootargs console=tty1 console=ttyS0,115200 loglevel=7 consoleblank=0 \ isdebug=yes \ web=http://192.168.203.113/fog/ \ mac=dc:a6:32:c8:b4:33 osid=50 type=up \ img=ImagePi4 imgType=mps imgPartitionType=all \ storage=192.168.203.113:/images/dev/ storageip=192.168.203.113 \ fdrive=/dev/sda

(console=ttyS0 is the Pi’s mini-UART. That driver is new in this build too, so if you have
a serial adapter you’ll now get output on it. Harmless if you don’t.)

5. What success looks like

Early on you should see, before anything FOG-specific:

Trying to unpack rootfs image as initramfs... Freeing initrd memory: 52576K Run /init as init process

Those three lines alone tell me bug 1 is fixed on real hardware. Then the FOG banner with
Version / Init Version / Kernel Version, then Checking Operating System ... Linux, then
Attempting to check in.

If it sits on “Attempting to check in” repeating, that is a pass, not a failure. It means
everything booted and FOS is waiting for the server to hand it a job.

Then the actual capture

FOS won’t image anything until the server has a task queued for it. Hand-writing kernel
arguments doesn’t create one, which is the other reason you weren’t getting anywhere.

In the web UI, register the Pi as a host with MAC dc:a6:32:c8:b4:33. Set that host’s Host Primary Disk to /dev/sda (that’s what fdrive= above is
doing by hand). Create an image called ImagePi4, Linux, Multiple Partition Image - Single Disk. On the host, Basic Tasks -> Capture. Boot the Pi again with the same bootargs. Check-in should return and it should start
uploading.

Fair warning on one thing I can’t predict: your Pi boots off that USB SSD, and FOS is going
to be capturing the same disk it isn’t running from, which is fine. But a Pi’s boot
partition and its partition layout aren’t like a PC’s, and I don’t know yet how our
partition code handles it. That’s the second thing I want to learn from you.

What to send back

Even a failure is useful, honestly more useful than a success.

The console output from boot, as much as you can capture. Serial is easier than
photographing a screen if you have an adapter. Specifically whether you see those three initramfs lines. If it stops somewhere, whatever the last line on screen is. With isdebug=yes it’ll be
paused at a named step rather than just hanging, which tells me exactly where to look.

Thanks for sticking with this. Two people have asked for Pi support on here over the last
couple of years and both threads died because none of the developers has the hardware, so
you finding this and being willing to test it is genuinely how it gets fixed.

@Tom-Elliott
I think something isn’t working for me.
I can’t get iPXE menu when secureboot is enable and secureboot/snponly-shimx64.efi is set.
I have :

NBP filename is secureboot/snponly-shimx64.efi NBP filesize... Downloading NBP file...

Then I go back to Boot Menu.

I thought is could be network card drive or something like this but it’s loading fine without secureboot enable.

@Jason89436 Thanks for the detailed report — the debug output is what made this findable, and sShutdown_insert coming through empty is exactly the bug.

What was happening. The snapin create path set that field from a comparison rather than from a literal, so PHP handed the database a boolean. FOG binds every parameter as a string, and (string)false is the empty string — so what actually reached the server was ‘’, which is not a member of enum(‘0’,‘1’). Hence “Data truncated for column ‘sShutdown’”.

That empty string has been going in for years. You are seeing it now because FOG used to run SET SESSION sql_mode=‘’ on every connection, which switched off the server’s own validation and let it quietly substitute a value instead of complaining. Removing that clear was the right thing to do, but it turned a long list of silent coercions into visible errors, and this is one of them.

Fixed in 1.6.0-beta.4027. You are on beta.4020, so an update will pick it up. The fix normalizes booleans to ‘0’/‘1’ at the point where parameters are bound, which covers every write path rather than just this one — the same defect was reaching the task-type editor and group/host tasking, and those are fixed along with it. The 1.5 line has it too, from 1.5.10.2399.

Since then I have gone a step further on 1.6 and stopped storing booleans as enum(‘0’,‘1’) at all — they are tinyint(1) now. The reason is that an integer written to an ENUM is a member index rather than a value, so 1 selected the member ‘0’ and meant false. Nothing in FOG hit that, because everything was bound as a string, but it was one careless cast away from silently inverting flags. That change is in the current beta and upgrades your database in place, so there is nothing to do beyond updating.

On the LDAP side — I would like the exact error for that one. The LDAP config path writes its checkboxes as integers rather than booleans, so it is not the same defect, which means either something else is failing there or it is a different symptom of the same strict-mode change. Either way it needs its own look. If you still see it after updating, post the message and the debug block the way you did here and I will chase it down.