@Tom-Elliott

"Hi again! Great news regarding the new TFTP fallback mechanism.

I tested it manually by setting the IP addresses:
Plaintext

setenv ipaddr 192.168.203.50
setenv serverip 192.168.203.113
pxe get

What happened:

U-Boot successfully found the correct path generated by FOG based on the MAC address (Retrieving file: pxelinux.cfg/01-88-a2-9e-53-34-c0).

However, the download times out (Loading: T T T T T T) and results in a Retry count exceeded.

For context: a deployment task was explicitly active and queued in the FOG web interface before running the test, so the file should be there.

Is there a specific TFTP block size or setting required in working-1.6 for U-Boot’s pxe get to successfully pull the file without timing out, or could it be related to firewall/TFTP service configuration on the server side?"

@Tom-Elliott

"To answer your question directly: yes, so far I have only been testing manually at the U-Boot prompt (=>).

My main concern right now is scalability. Since I need to deploy this across a fleet of 100 to 200 Raspberry Pi units, configuring each SD card manually or typing commands at the prompt for every single machine is not an option.

What is the recommended best practice in FOG working-1.6 to handle automation for a large fleet? Can the bootcmd be permanently stored in the Pi’s onboard EEPROM once, or can U-Boot fetch a boot script via TFTP automatically without manual card preparation?"

@Tom-Elliott "Hi again,

Following your instructions, I checked the U-Boot prompt. When typing wget, it responds with:
Unknown command wget try help
So the U-Boot build on these boards does not include the wget command.

Also, for context on how the board behaves at boot, here is what happens visually during the startup sequence (attached photo): it tries to boot locally, times out on storage (mmc / usb), and then falls back to a standard network BOOTP broadcast loop (Retry time exceeded).

Given that U-Boot lacks wget and relies on standard BOOTP/PXE broadcast rather than direct HTTP fetching, what is the recommended way or fallback mechanism to have these boards pull their configuration from FOG?"

@Tom-Elliott

I checked both database entries for hostKernelArgs, and isdebug=yes was indeed not present there.

Regarding the U-Boot wget error, I followed your suggestion and went to the U-Boot prompt (=>) on the Raspberry Pi. When I type wget, it responds with:
Unknown command wget try help

So it seems the U-Boot build on these Raspberry Pis does not have the wget command compiled into it at all. What would be the recommended fallback or alternative method to fetch the script from FOG in this case (e.g., using TFTP or an alternative command if available)?"

@Tom-Elliott

Thanks for your clarification, and apologies for the confusion. I think there was a misunderstanding about what I am trying to achieve.

I am not trying to bypass FOG or do something outside of FOG — quite the contrary. I am actively using FOG to deploy images to a fleet of Raspberry Pi devices.

My previous confusion came from the fact that my test units kept landing in the interactive FOG debug mode (requiring pressing Enter to get a prompt), which led me down the wrong path thinking I needed a manual workaround. My ultimate goal is simply to have a standard, fully automated deployment task (non-debug) run seamlessly on the Raspberry Pis without requiring manual intervention at each boot.

I will look into standard deployment tasks and post-init scripts as you suggested. Thanks for pointing me in the right direction!

@Tom-Elliott

1. Context and Objective

   Hardware: Raspberry Pi (ARM architecture) running U-Boot.

   FOG Server: Updated to the working-1.6 branch (tested version: 1.6.0-beta.4707).

   Objective: Enable fully automated and dynamic deployment/boot (without human intervention or blocking debug mode) using the new U-Boot endpoint created by the developer (/fog/service/uboot/boot.php).

2. Testing Process and Results

   Step A: Initial Manual Validation (Success)

    By executing the deployment commands manually on the Raspberry Pi terminal, the image cloning completed successfully, and the image was properly copied to the new Raspberry Pi. This confirmed that the hardware and image transfer parts are functional.
   

   Step B: FOG Server Update

    Updated the server to the working-1.6 branch and executed ./bin/installfog.sh to integrate the new U-Boot endpoint.
   

   Step Testing the U-Boot Endpoint (boot.php)

    The curl request executed on the FOG server for a specific MAC address:
    Bash
   
    curl "http://127.0.0.1/fog/service/uboot/boot.php?mac=88:a2:9e:53:34:c0"
   
    Server Response: The endpoint correctly generates and returns a script in PXE/Syslinux format structured as follows:
    Plaintext
   
    # Generated by FOG Project. Do not edit -- it is not stored.
    default fog
    timeout 1
    label fog menu label FOG Project tasking kernel http://192.168.203.113/fog/service/ipxe/arm_Image initrd http://192.168.203.113/fog/service/ipxe/arm_init.cpio.gz append ...
   

   Step Testing Automatic Boot on the Raspberry Pi

    Used the U-Boot sequence with wget and the pxe boot command to attempt dynamic file retrieval at startup.
   
    Technical observation noted: The wget tool embedded in the BusyBox/FOS environment on ARM encounters parsing issues with URLs containing GET parameters (?mac=...), throwing a wget: bad port error.
   

3. Attention Point

   The script generated by boot.php returns a Syslinux/PXE-style configuration format (label fog …), which is natively supported by U-Boot’s pxe boot command. However, full automation via a clean U-Boot command line (bootcmd) requires ensuring that the embedded wget on ARM environments can handle URLs with dynamic parameters without syntax errors.

@Tom-Elliott

I’ve been working on deploying images to a Raspberry Pi 4 (ARM64) using FOG (version 1.5.10.2254, FOS kernel 6.18.38), and I wanted to share our findings, encountered errors, and current limitations we faced during the process. Hopefully, this can help improve native ARM support or guide others trying to achieve unattended RPi deployments.

Here is a summary of what we experienced and how we bypassed it:

1. U-Boot bootargs Buffer Overflow

   Issue: When adding extra environment variables to bootargs inside boot.cmd (such as custom storage IPs, disk targets, or MAC addresses), the ARM64 kernel command line exceeded the maximum allowed size. This caused the kernel boot process to silently halt right after the network interface came up (Link is Up).

   Workaround: Kept the bootargs string as minimal as possible and relied on FOG web settings where applicable.

2. Missing osid Parameter

   Issue: FOS initialization stops with No os id passed (determineOS) and reboots if the kernel parameters do not explicitly provide osid=50 (or the corresponding OS ID) alongside type=down.

   Workaround: Explicitly appending osid=50 type=down in the U-Boot script parameters.

3. FOG Automatic Script Orchestration vs. ARM Multi-Partition Layout

   Issue: Even when successfully booting into FOS and passing the correct variables (img=Raspberry, storage=…, fdrive=/dev/sda), the automated fog script skips or fails to correctly parse multi-partition layouts on USB/SD external drives (/dev/sda), directly jumping to “Task Complete” without actually writing data via Partclone or triggering errors like Fatal Error: Unknown request type :: Null.

   Workaround: We had to enter FOG Debug Mode (isdebug=yes), export variables manually (export storage, export img, export type=down), and notice that FOG’s single-partition versus multi-partition routines expect specific raw file structures (d1.mbr, d1p1.img, d1p2.img).

4. Raw Image Files (.img) vs. Partclone Format

   Issue: When attempting manual deployment via partclone.restore, Partclone throws This is not partclone image because FOG stores standard multi-partition RPi captures as raw binary dumps (.img) rather than compressed partclone streams.

   Workaround: Restoring the MBR and partitions required direct block-level commands:
   Bash

   dd if=/images/Raspberry/d1.mbr of=/dev/sda bs=512 count=1
   dd if=/images/Raspberry/d1p1.img of=/dev/sda1 bs=4M status=progress
   dd if=/images/Raspberry/d1p2.img of=/dev/sda2 bs=4M status=progress

   Result: While the partitions are written, the RPi firmware still struggles to directly boot the resulting USB structure (Unable to read partition as FAT), indicating that standard FOG MBR generation (d1.mbr) doesn’t align cleanly with RPi’s expected GPT/FAT bootloader requirements for USB-MSD booting.

It seems the automated deployment engine (fog script) inside FOS needs specific adaptations for ARM/Raspberry Pi multi-partition disk imaging (handling fdrive=/dev/sda and raw dd-like partition layouts seamlessly).

Any insights or recommendations on how to properly handle native RPi deployments through FOG would be greatly appreciated!

@Tom-Elliott

Thank you so much for the detailed explanation and for all your hard work on this!

It’s amazing to know that this was a first for the Raspberry Pi and FOG Project, and I’m really glad my tests helped validate those three major fixes on real hardware.

Good catch on the :filesize argument syntax for booti as well. That clarification will definitely be super helpful for anyone setting up ARM64/Pi deployments in the future!

Everything is working smoothly on my end now. Thanks again for the incredible reactivity and support.

The next test is to deploy the image to other Raspberry Pis; I’ll keep you posted.

@Jeremy said in FOG Project Image Capture on Raspberry Pi 4 (ARM64) via U-Boot:

@Tom-Elliott

GREAT NEWS! The capture completed successfully!

Here is a summary of the steps and final configuration that made it work seamlessly on the Raspberry Pi 4:

1. Display Fix (Kernel side):
   Downloading build EXP_20260827-114033 with the integrated VC4 driver completely resolved the display freeze on the 4 raspberries logo. HDMI output initialized perfectly.

2. Ramdisk Format Fix (U-Boot side):
   Passing raw arm_init.cpio.gz via booti was triggering a “Wrong Ramdisk Image Format” error in U-Boot. Wrapping it into uInitrd with the following command solved the issue:
   mkimage -A arm64 -O linux -T ramdisk -C none -d arm_init.cpio.gz uInitrd

3. Final Working boot.cmd:

---

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

setenv bootargs console=tty1 loglevel=7 consoleblank=0 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

tftp ${kernel_addr_r} 7efcf632/arm_Image
tftp ${ramdisk_addr_r} 7efcf632/uInitrd
tftp ${fdt_addr_r} 7efcf632/bcm2711-rpi-4-b.dtb

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

4. Imaging Status:
   Once booted into FOS, Partclone captured /dev/sda without any error and uploaded the full image to the FOG server!

Thank you so much for adding the VC4 driver and supporting ARM64 builds!

@Tom-Elliott

Hi! I downloaded the full updated pair from build EXP_20260826-143004 (arm_Image, arm_init.cpio.gz, and bcm2711-rpi-4-b.dtb from arm_dtbs.tar.gz).

I set the memory addresses exactly as requested:

• kernel_addr_r: 0x00080000
• fdt_addr_r: 0x08000000
• ramdisk_addr_r: 0x09000000

I also passed isdebug=yes in bootargs and removed the old kernel8.img / uInitrd references to ensure only the new build files are booted.

Result on real hardware (Pi 4B):
The Pi hangs indefinitely on the 4 Raspberry logos screen with a blinking cursor, right after U-Boot executes booti. No text output appears after the logos, and I am unable to type commands or reach the FOS shell, so I cannot run uname -a or cat /proc/....

It seems the kernel halts before initializing the console/framebuffer or hangs during early memory setup on real Broadcom hardware.

Let me know if you want me to test another build or change specific earlycon/console bootargs!

@Tom-Elliott Thanks for the feedback; I started the tests and got this:

1. Bugs 1 & 2 are 100% fixed!

• The kernel successfully unpacks the initramfs (Trying to unpack rootfs image as initramfs..., Run /init as init process).
• Broadcom SoC drivers, USB storage (/dev/sda - JMicron), and the internal NIC (bcmgenet -> eth0 Link is Up) are all working great.

2. Where it stops:
   After getting the network link up, FOS fails when trying to mount with the following errors on screen:

ext3: Unknown parameter ‘nolock’
ext2: Unknown parameter ‘nolock’
ext4: Unknown parameter ‘nolock’
vfat: Unknown parameter ‘nolock’
msdos: Unknown parameter ‘nolock’
f2fs: Unknown parameter ‘nolock’

It looks like FOS is passing the NFS nolock mount option when trying to probe/mount local filesystem types or local partitions. After these errors, the Pi reboots back to the U-Boot prompt.

Let me know if you need me to test a updated init containing a fix for the mount options!

@Tom-Elliott

Thanks a lot for your feedback; I’ve been trying to get it working for a week without success, and your reply confirms that the issue isn’t on my end.

I’d be more than happy to help once you’ve found the solution.

Hello, the goal of using FOG Project at the company where I work is to capture an image of a Raspberry Pi 4 that is already configured (with SSH, Wi-Fi, locale, and keyboard settings enabled).

I haven’t been able to find a topic to help me set this up; for now, I am relying on Gemini and Claude for assistance.

Project Overview:
I am trying to capture an image from a Raspberry Pi 4 (2 GB RAM) to a FOG Project server (v1.5.10). The Pi 4 uses an external 512 GB JMicron SSD/USB drive connected to an USB 3.0 port (/dev/sda).

What has been done and validated so far:

PXE / TFTP Chainloading: The Raspberry Pi 4 successfully boots via native PXE, loads U-Boot, and downloads via TFTP the boot.scr script, the bzImageARM64 kernel, the uInitrd ramdisk, and the bcm2711-rpi-4-b.dtb DTB file

Network Driver Issue Resolved: The default FOG bzImageARM64 kernel lacked support for the Pi 4’s onboard Broadcom NIC. I replaced it with the official Raspberry Pi ARM64 kernel (kernel8.img / 6.18.46-v8+).

Hardware Detection:

The native Broadcom Ethernet controller (bcmgenet) initializes properly (eth0: Link is Up - 1Gbps/Full).

An IP address is assigned via DHCP (udhcpc: lease of 192.168.203.73 obtained).

The external storage drive is properly detected at /dev/sda (JMicron drive with sda1 and sda2 partitions).

Current boot.cmd Configuration (U-Boot):

setenv kernel_addr_r 0x00080000
setenv kernel_comp_addr_r 0x0a000000
setenv kernel_comp_size 0x02000000
setenv fdt_addr_r 0x02600000
setenv ramdisk_addr_r 0x03000000

setenv bootargs console=tty1 root=/dev/ram0 rw ramdisk_size=275000 web=192.168.203.113/fog/ loglevel=7 mode=debug type=up mac=dc:a6:32:c8:b4:33 osid=50 img=ImagePi4 storage=192.168.203.113:/images/ storageip=192.168.203.113 imgType=mps imgPartitionType=all storagedev=/dev/sda

tftp ${kernel_addr_r} 7efcf632/bzImageARM64
tftp ${ramdisk_addr_r} 7efcf632/uInitrd
tftp ${fdt_addr_r} 7efcf632/bcm2711-rpi-4-b.dtb

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

Current Issue:
During the FOS Linux kernel boot, the process hangs right after displaying the network link line (bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx) and does not automatically proceed to the FOG init scripts / check-in process (/bin/fog.checkin).

Has anyone successfully automated a full FOS capture workflow on ARM64 / Raspberry Pi 4 architecture?