PXE Boot Server Setup and Troubleshooting Checklist

March 7, 2026

PXE Boot Server Setup and Troubleshooting Checklist

This checklist is designed for system administrators, IT professionals, or hobbyists setting up or maintaining a Preboot Execution Environment (PXE) server. PXE allows computers to boot and install an operating system over a network, which is essential for automated deployments, diskless workstations, or recovering systems without local media. Use this list during initial configuration and when diagnosing boot failures to ensure no critical step is missed.

Pre-Setup Prerequisites & Network Configuration

  • Verify Network Infrastructure — Ensure your network switches support broadcast/multicast traffic and that firewalls (including host-based ones like `firewalld` or `ufw`) are configured to allow DHCP (ports 67/UDP, 68/UDP) and TFTP (port 69/UDP) traffic. This is foundational.
  • Assign a Static IP to the PXE Server — The server hosting PXE services must have a fixed IP address on the network. Dynamic assignment can cause client boot failures.
  • Confirm DHCP Server Availability — Decide if your PXE server will also run the DHCP service or if it will coexist with an existing enterprise DHCP server. Coexistence requires configuring DHCP options (next-server, filename) on the existing server. (Key Item)
  • Prepare Sufficient Storage — Ensure the server has adequate disk space for boot images (e.g., Linux kernels, initrds), installation files, and potentially client-specific configurations.

Core Service Installation & Configuration

  • Install Required Packages — On a Linux server (e.g., CentOS/RHEL, Ubuntu), install `dnsmasq` (combined DHCP/TFTP/DNS) or separate `dhcp-server` and `tftp-server` packages. Also install `syslinux` or `pxelinux.0` for the bootloader and an HTTP/NFS server for serving large OS files.
  • Configure DHCP Service Correctly — In `dhcpd.conf` or `dnsmasq.conf`, explicitly set the `next-server` (TFTP server IP) and `filename` (e.g., `pxelinux.0` or `grub/x86_64-efi/shim.efi`). For UEFI vs. Legacy BIOS clients, different filenames may be required. (Key Item)
  • Set Up TFTP Root Directory — Populate the TFTP root (often `/var/lib/tftpboot/`) with the bootloader files from `syslinux`. Ensure permissions are correct (world-readable) and that the `tftp` service is running. SELinux/AppArmor contexts may need adjustment. (Commonly Missed)
  • Place Boot Images and Menus — Copy your kernel (`vmlinuz`) and initial RAM disk (`initrd.img`) files to the TFTP directory. Create a `pxelinux.cfg` directory and a default configuration file (or client-specific files by MAC/IP) to define boot menu entries.
  • Configure the Network File Server — Set up an HTTP (Apache/Nginx) or NFS share to host the full OS installation tree (e.g., the contents of an ISO). Point your PXE menu entry to this location (e.g., `inst.repo=http://pxeserver/path/to/os/`).

Client Boot Process Verification

  • Test Network Boot in Client BIOS/UEFI — On the target client, enable "Network Boot" or "PXE Boot" as a primary boot option in the firmware settings. Some systems require enabling legacy ROM for PXE.
  • Capture DHCP Offer — Use a network sniffer (like `tcpdump`) on the PXE server to verify the client is sending DHCP Discover packets and that the server replies with the correct `next-server` and `filename` options.
  • Monitor TFTP Transfer Logs — Check TFTP server logs (`journalctl -u tftp`) for file transfer attempts. Repeated timeouts or "File not found" errors indicate path or permission issues.
  • Verify Bootloader and File Paths — Ensure the `filename` in DHCP matches the actual case-sensitive path in the TFTP root. A typo here is a common point of failure.
  • Check Kernel/Initrd Compatibility — Confirm the provided kernel and initrd support network drivers for the client's hardware. Using a generic or newer driver set may be necessary.

Post-Boot & Installation Phase

  • Validate Access to Installation Repository — Once the kernel boots, the client must reach the HTTP/NFS path specified. Test this URL from another client on the same network. Firewall rules for ports 80 (HTTP) or 2049 (NFS) are often overlooked. (Commonly Missed)
  • Prepare Automated Answer Files — For unattended installs (e.g., Kickstart for RHEL, Preseed for Debian), ensure the answer file is correctly referenced in the PXE menu and is accessible via the network file server.
  • Test Multiple Client Architectures — If supporting both x86_64 UEFI and Legacy BIOS, verify you have the correct bootloaders (`shim.efi`, `grubx64.efi` for UEFI; `pxelinux.0` for BIOS) and configurations for each.

Ongoing Maintenance & Troubleshooting

  • Document All Customizations — Keep a record of any non-standard DHCP options, custom PXE menu entries, or firewall rules. This is crucial for disaster recovery or server migration.
  • Update Boot Images Regularly — Periodically update the kernel, initrd, and installation repository to include security patches and new hardware support.
  • Implement Logging and Monitoring — Centralize logs from DHCP, TFTP, and web services. Monitor for failed boot attempts to proactively identify issues.
  • Secure the PXE Environment — In non-isolated networks, consider using DHCP snooping, MAC address filtering, or secure boot to prevent unauthorized network boots.

Key Reminders

Network Isolation for Testing: Initial setup is best done on an isolated VLAN or physical network to avoid conflicts with production DHCP services.
The Chain of Trust: Remember PXE is a chain: Client BIOS → DHCP → TFTP (bootloader) → TFTP (kernel/initrd) → HTTP/NFS (OS files). Failure at any step breaks the chain. Methodically verify each link.
Print-Friendly Note: For a printable version, ensure your browser's print settings are set to "Background Graphics" to capture all bullet points and headers clearly.

FROM THE DINING TABLEtechnologyLinuxopen-source