# BeaglePlay network boot guide cuts kernel dev loop from SD card swaps to pure NFS

> **Key takeaway:** A BeagleBoard.org developer documented setting up TFTP/NFS network boot on BeaglePlay, eliminating physical SD card transfers for kernel and module testing.

**Published:** 2026-10-18T12:11:30+00:00 
**Source:** BeagleBoard.org Blog 
**Category:** open-hardware 
**Canonical URL:** https://fosswire.org/news/beagleplay-network-boot-guide-cuts-kernel-dev-loop-from-sd-c.html 

## Summary
A BeagleBoard.org developer published a detailed guide for network-booting the BeaglePlay single-board computer using U-Boot TFTP for the kernel and device tree, with an NFS-exported root filesystem from a Fedora Atomic host. The setup replaces a slow development loop of repeatedly removing and copying to an SD card. The post includes specific fixes for boot failures, such as masking the bbbio-set-sysconf.service dependency on /boot/firmware, handling SELinux xattr conflicts during rsync, and ensuring required network and NFS drivers are built into the kernel rather than modules.

## Boot flow and gotchas
- U-Boot brings up Ethernet via DHCP, downloads pxelinux.cfg over TFTP, then fetches kernel, DTB and overlays; kernel uses `ip=dhcp` and mounts root over NFS
- Host uses socket-activated tftp-server and nfs-utils with `no_root_squash` and `async` for the export
- Rootfs copied from BeaglePlay Debian image with `rsync -aHAX --numeric-ids` and SELinux filter to preserve permissions and capabilities
- Required built-in kernel options: `NFS_FS`, `NFS_V3`, `ROOT_NFS`, `IP_PNP`, `IP_PNP_DHCP`, plus TI Ethernet drivers (`TI_K3_AM65_CPSW_NUSS`, `TI_DAVINCI_MDIO`)
- `pxelinux.cfg` `append` must be single-line; keyword is `fdtoverlays` not `fdtoverlay`; overlays require explicit `fdt` entry
- `serverip` must be set after `dhcp` since DHCP overwrites it with the router address
- Workaround for boards without `saveenv`: keep kernel on local storage, use NFS only for rootfs

## Why it matters
The guide lowers the barrier for kernel development on ARM boards by replacing slow physical media transfers with a standard network boot workflow, and documents specific pitfalls that would otherwise cost hours of debugging.