How to PXE Boot a Raspberry Pi Fleet with OpenClaw Provisioning

Raspberry Pi shipped 7.6 million boards in FY2025 alone, bringing the all-time total past 68 million units. A growing share of those boards run in production: edge computing nodes, digital signage clusters, IoT sensor arrays, retail kiosks. In every fleet deployment, the microSD card slot remains the weakest link in the hardware stack.

SD cards fail because they have a finite number of write cycles. A Pi running an always-on workload writes continuously to system logs, temporary files, and application databases. Consumer-grade microSD cards were designed for cameras that write large sequential files, not operating systems performing thousands of small random writes per hour. The result is predictable: data corruption, failed boots, and dead nodes that need manual intervention to bring back online.

For a single Pi on your desk, swapping a corrupted SD card takes five minutes. For a fleet of twenty Pis mounted in server racks, ceiling enclosures, or outdoor housings, the math changes fast. Each failure means physical access to the node, a freshly imaged card, and manual reconfiguration of the replacement. At scale, SD card failures become an operational tax that grows linearly with every node you add to the fleet.

PXE (Preboot eXecution Environment) network boot eliminates the card entirely. Each Pi loads its operating system over Ethernet from a central server. No local storage media means no write-cycle degradation and no card swaps. The OS image lives in one place on the server, and every Pi in the fleet boots from it. Update the image once, and every node picks up the change on the next reboot.

OpenClaw adds an automation layer on top of this infrastructure. Instead of manually editing dnsmasq configs, cloning root filesystems, and running post-install scripts for each new node, you describe the provisioning workflow in natural language and let the agent handle the repetitive execution. The combination of PXE boot and AI-driven provisioning turns "add a new Pi to the fleet" from a thirty-minute checklist into a conversation.

PXE boot on Raspberry Pi follows a well-defined sequence. When a Pi powers on with network boot enabled, its firmware broadcasts a DHCP discovery packet over Ethernet. The DHCP server responds with an IP address and the location of a TFTP server that holds the boot files.

The Pi then requests its boot files from the TFTP server. For a Raspberry Pi 4 or 5, these include the firmware files (start4.elf, fixup4.dat), the device tree blobs, the Linux kernel, and an initial ramdisk. The TFTP server identifies each Pi by the last eight characters of its serial number, serving the correct boot files from a per-device directory under the TFTP root.

Once the kernel loads, it mounts a root filesystem over NFS (Network File System) from the same server or a dedicated storage node. At this point, the Pi is fully booted and running with its entire filesystem living on the network. From the perspective of applications running on the Pi, the experience is identical to booting from a local SD card, just without the SD card.

The tool that makes this practical for small and medium fleets is dnsmasq. It combines DHCP, DNS, and TFTP into a single lightweight service that uses only a few megabytes of RAM. Instead of running three separate daemons with three separate configuration files, you configure one process that handles IP assignment, hostname resolution, and boot file delivery.

Hardware compatibility: PXE boot support was introduced on the Raspberry Pi 3 Model B+ and is native on Pi 4, Pi 400, and Pi 5. The Pi 3B+ requires a one-time OTP (one-time programmable) bit set via raspi-config before it can network boot. Pi 4 and later models support it out of the box, though you may need to update the EEPROM bootloader to configure the boot order.

One hard constraint to plan around: PXE boot requires a wired Ethernet connection. WiFi network boot is not supported on any Raspberry Pi model. Your fleet deployment needs Ethernet to every node, whether through direct cables, a managed switch, or Power over Ethernet (PoE) HATs that deliver both power and data through a single cable.

Your PXE server can be a Raspberry Pi itself, a spare Linux box, or a VM. A Pi 4 or 5 with 4 GB of RAM and a USB SSD handles serving a fleet of 10 to 20 client nodes comfortably. For larger fleets, an x86 server with gigabit networking and fast storage is worth the investment, since NFS performance scales directly with server I/O throughput.

Start by installing the required packages on your server:

sudo apt update
sudo apt install -y dnsmasq nfs-kernel-server

Create the TFTP root directory where boot files will live:

sudo mkdir -p /tftpboot
sudo chmod 777 /tftpboot

Configure dnsmasq by editing /etc/dnsmasq.conf. The key directives for PXE serving:

interface=eth0
log-dhcp
enable-tftp
tftp-root=/tftpboot
tftp-unique-root=mac
pxe-service=0,"Raspberry Pi Boot"

The tftp-unique-root=mac directive tells dnsmasq to look for boot files in a subdirectory named after each client's MAC address. This lets you serve different OS configurations to different nodes in the fleet.

If you already have a DHCP server on your network (most routers run one), run dnsmasq in proxy mode by adding dhcp-range=<your-subnet>,proxy to avoid IP assignment conflicts while still responding to PXE boot requests.

For each client Pi, create a directory under /tftpboot using the last eight hex digits of its serial number (e.g., /tftpboot/abcd1234/). Copy the boot files from a working Raspberry Pi OS installation into this directory. You need at minimum: start4.elf, fixup4.dat, the appropriate device tree blob for your Pi model, kernel8.img, and cmdline.txt.

Next, set up the NFS root filesystem. Create a directory for each client:

sudo mkdir -p /nfs/client01

Copy or rsync a complete Raspberry Pi OS root filesystem into that directory. Export it by adding a line to /etc/exports:

/nfs/client01 *(rw,sync,no_subtree_check,no_root_squash)

Apply the exports and restart dnsmasq:

sudo exportfs -ra
sudo systemctl restart dnsmasq

Finally, edit cmdline.txt in each client's TFTP directory to point the kernel at the correct NFS root. Replace the existing root= parameter with:

root=/dev/nfs nfsroot=192.168.1.100:/nfs/client01,vers=4.1,proto=tcp rw ip=dhcp rootwait

Substitute 192.168.1.100 with your PXE server's static IP address.

Each Pi in the fleet needs its boot order changed to prioritize network boot. On a Pi 4 or 5, this is an EEPROM setting. If the Pi currently has an SD card, boot it and run:

sudo raspi-config

Navigate to Advanced Options, then Boot Order, and select Network Boot. This writes the new boot order to the Pi's EEPROM. After a reboot, the Pi will attempt network boot before falling back to SD card if one is present.

To go fully diskless, remove the SD card after confirming network boot works. The Pi will find the DHCP/PXE server on the local network, download its boot files via TFTP, and mount its root filesystem over NFS without any local storage.

For Pi 3B+ models, enable the network boot OTP bit first:

echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
sudo reboot

This is a one-time change burned into the hardware. After setting it, the Pi 3B+ will check for network boot on every power-on.

Scaling the filesystem approach: You have two practical strategies for managing NFS roots across the fleet. The first is a shared read-only base image with per-node overlay filesystems. Every Pi boots from the same base, and an OverlayFS mount captures node-specific writes. This saves significant disk space on the server and simplifies updates, since you only maintain one base image. The tradeoff is more complex initial setup and occasional overlay management.

The second approach is a full root filesystem clone per node. Each Pi gets its own complete copy under /nfs/client01, /nfs/client02, and so on. This uses more server disk space but gives each node full independence. Rsync makes cloning fast:

sudo rsync -xa /nfs/client01/ /nfs/client02/

For fleets of five or fewer nodes, full clones are simpler to manage. Beyond ten nodes, the shared-base-with-overlay approach starts saving meaningful disk space and keeps OS updates centralized.

Test each new node by powering it on without an SD card and watching the dnsmasq log in real time:

sudo journalctl -u dnsmasq -f

You should see the DHCP request, the TFTP file transfers, and the NFS mount sequence. If the Pi hangs at the rainbow splash screen, the most common causes are an incorrect TFTP directory name (must match the Pi's serial number), missing boot files, or restrictive NFS export permissions.

Centralize your fleet's provisioning artifacts in one workspace

Fastio gives your Raspberry Pi fleet shared storage with generous storage, MCP access for your OpenClaw agent, and Intelligence Mode for searching fleet documentation. No credit card, no expiration.

Start 14-Day Trial

The manual PXE setup works, but it involves repetitive steps for each new node: create the TFTP directory, copy boot files, clone the NFS root, update dnsmasq, restart services, edit cmdline.txt with the right NFS path. For a fleet that changes over time, with nodes added, replaced, or repurposed, this becomes the kind of structured, repeatable work that an AI agent handles well.

OpenClaw is an open source AI agent that runs directly on a Raspberry Pi as a headless service. It connects to cloud LLM providers (Anthropic, OpenAI, or others) for reasoning and executes commands locally on the Pi where it's installed. For PXE fleet provisioning, you install OpenClaw on the same machine that runs your dnsmasq and NFS services.

The official installation takes about thirty minutes on a fresh Pi OS Lite image. Once running, OpenClaw accepts instructions through messaging channels like Telegram or Discord. Instead of SSHing into the server and running commands by hand, you describe what you need in plain language and the agent executes the sequence.

To add a new node, you describe the steps: create a TFTP directory for serial number X, copy the base boot files from the template, clone the NFS root for the new node, update the dnsmasq configuration, and restart the service. OpenClaw handles each command through its local shell access, checking for errors at each step and reporting results back through the messaging channel.

The deeper value shows up in post-install configuration. After a new Pi boots for the first time via PXE, it still needs application-specific setup: installing packages, starting services, setting environment variables, joining a monitoring or logging stack. OpenClaw supports SSH into remote devices, so it can connect to freshly booted client nodes, run setup commands, verify that services started correctly, and report per-node status back to you.

This is not a replacement for dedicated fleet management tools like Ansible, Puppet, or Salt. Those tools excel at declarative state management for large fleets where strict reproducibility matters. The advantage of OpenClaw is flexibility for smaller fleets and ad-hoc operations. You describe what you want in conversation rather than writing YAML playbooks or maintaining a configuration management codebase. For fleets under 50 nodes, the conversational approach often finishes faster than setting up a full automation framework.

For larger environments, pair both approaches. Use Ansible for the declarative baseline and OpenClaw for troubleshooting, one-off provisioning tasks, and the ad-hoc work that doesn't fit neatly into a playbook.

Running a Pi fleet generates artifacts that outlive any single provisioning session: base OS images, dnsmasq configuration templates, provisioning logs, node inventory records, firmware update packages. Keeping everything on the PXE server creates a single point of failure. If the server drive fails, you lose both the fleet's boot infrastructure and its operational history.

Local NAS or S3-compatible object storage (MinIO, Backblaze B2) handles backups well. For workflows where fleet artifacts need to be shared across a team or handed off to a new administrator, Fastio provides workspaces built around that collaboration pattern.

A Fastio workspace stores files with full version history and granular permissions at the organization, workspace, folder, and file level. Upload your base OS images, dnsmasq configurations, and provisioning scripts to a shared workspace. When you update the base image, version history preserves the previous state. If an update causes boot failures across the fleet, pull the last known-good image from the history without maintaining your own backup rotation scheme.

With Intelligence Mode enabled, uploaded documents are automatically indexed for semantic search. A new team member can ask questions like "what network range does the staging fleet use" or "when was the base image last updated" and get citation-backed answers that point to the specific files. No manual folder browsing or log file grep sessions required.

The Fastio MCP server exposes workspace operations through Streamable HTTP, so your OpenClaw provisioning agent can interact with Fastio programmatically. Upload completed provisioning logs after each fleet change, create branded shares for delivering firmware packages to field technicians, or pull configuration templates from a workspace without manual file transfers. The MCP interface supports 19 consolidated tools covering workspace, storage, AI, and workflow operations.

When fleet ownership changes hands, ownership transfer lets the agent hand off an entire organization, including workspaces, shares, and permission structures, to a human account while retaining admin access for ongoing maintenance. The Business Trial includes 50 GB of storage, included credits, and 5 workspaces with no credit card required and no expiration date.