Network Boot and Automated Provisioning

Network booting lets a machine start without local install media. Automated provisioning builds on that: firmware gets a boot program from the network, the boot program loads an installer kernel and initrd, and the installer fetches a declarative answer file that partitions disks, installs packages, configures users, and hands off to first-boot automation.

Command Examples

tcpdump -ni <interface> 'port 67 or port 68 or port 69 or port 80 or port 4011'
journalctl -u isc-dhcp-server -u dnsmasq -u tftpd-hpa --no-pager
curl -fsS http://<boot-server>/boot.ipxe
curl -fsS http://<boot-server>/autoinstall/user-data
ls -l /srv/tftp /var/lib/tftpboot /var/www/html

Example output and meaning:

Boot Flow

TFTP is simple and widely supported by firmware, but it is slow and fragile for large payloads. A common pattern is to use PXE/TFTP only to load iPXE or GRUB, then use HTTP for the kernel, initrd, ISO, and configuration.

DHCP, PXE, and ProxyDHCP

Classic PXE depends on DHCP-like information:

• client IP address,
• gateway and DNS,
• boot server,
• boot filename,
• sometimes architecture-specific bootloader selection.

Common DHCP options:

ProxyDHCP is useful when the network already has a DHCP server that should keep owning IP address assignment. A separate PXE service answers only boot metadata, often on UDP 4011, while the normal DHCP server still assigns addresses.

Avoid hard-coding one bootloader for every machine. BIOS PXE, x86_64 UEFI, ARM UEFI, Secure Boot, and iPXE may need different files.

iPXE

iPXE is a network boot firmware and bootloader that can be chainloaded from ordinary PXE. Its practical advantage is scriptability and better protocol support, especially HTTP.

Minimal iPXE script:

#!ipxe
dhcp
kernel http://boot.example.com/ubuntu/vmlinuz ip=dhcp autoinstall ds=nocloud-net;s=http://boot.example.com/autoinstall/node-01/
initrd http://boot.example.com/ubuntu/initrd
boot

More production-friendly scripts usually:

• detect ${mac}, ${serial}, ${asset}, or ${uuid},
• choose a profile from an inventory service,
• retry DHCP or HTTP cleanly,
• present a short timeout menu for rescue tools,
• chain to local disk after provisioning,
• avoid infinite reinstall loops.

Example shape:

#!ipxe
dhcp || goto shell
set base http://boot.example.com
chain ${base}/profiles/${serial}.ipxe || chain ${base}/profiles/default.ipxe || goto shell

:shell
echo Boot profile not found for ${serial}
shell

Ubuntu Autoinstall and cloud-init

Modern Ubuntu Server automated installs use Subiquity autoinstall data, commonly delivered through cloud-init NoCloud or NoCloud-Net.

Typical kernel parameters:

autoinstall ds=nocloud-net;s=http://boot.example.com/autoinstall/node-01/

The NoCloud directory commonly contains:

Autoinstall controls storage layout, packages, identity, SSH keys, late commands, and handoff behavior. Treat the file as infrastructure code. Review disk selectors carefully: automated installs can wipe the wrong disk if serial matching, size matching, or install target logic is loose.

Kickstart, Preseed, and Other Installers

Red Hat-family systems commonly use Kickstart with Anaconda. Debian historically used preseed; newer workflows often prefer cloud images, curtin, or installer-specific automation. The idea is the same: boot a small installer environment, pass it a URL, and let the installer consume a declarative answer file.

Kickstart-style kernel parameter examples often include a network source and Kickstart URL:

inst.repo=http://boot.example.com/rhel/9/BaseOS inst.ks=http://boot.example.com/kickstart/node-01.ks

Keep installer media, repositories, and answer-file syntax aligned with the OS release. A working RHEL 8 Kickstart or Ubuntu 22.04 autoinstall can fail subtly on a newer major release.

Inventory-Driven Provisioning

Automated network installs become safer when tied to inventory:

A provisioning system should know whether a node is allowed to install, which OS profile it should use, which disks it may wipe, which network it should join after install, and how it enrolls into config management.

Preventing Reinstall Loops

Network boot is powerful enough to destroy data repeatedly. Design explicit brakes:

• provision only hosts marked installable in inventory,
• chain to local disk after successful install,
• change the iPXE profile state after first boot,
• use BMC one-time boot instead of permanent network-first boot when possible,
• require a short menu timeout for destructive install paths,
• gate destructive storage profiles by serial or asset tag,
• keep rescue tools separate from install automation.

Secure Boot, Secrets, and Trust

Security-sensitive points:

• UEFI Secure Boot may reject unsigned EFI binaries or bootloaders.
• Answer files often contain password hashes, SSH keys, tokens, or enrollment secrets.
• Plain HTTP on an untrusted provisioning network can be modified in transit.
• DHCP spoofing or rogue PXE services can redirect hosts.
• Installer logs can preserve secrets unless redacted.

Mitigations include isolated provisioning VLANs, DHCP snooping, signed bootloaders, short-lived enrollment tokens, HTTPS where firmware/tooling supports it, per-node secrets, and wiping installer logs or avoiding secret material in answer files.

Troubleshooting

Debug from the wire first. DHCP/PXE bugs are easiest to see with packet capture because firmware logs are often thin or hidden behind BMC console output.

Study Cards

References

• iPXE documentation
• iPXE scripting
• Ubuntu autoinstall documentation
• cloud-init NoCloud datasource
• Red Hat Kickstart documentation
• UEFI Specification