PXE Boot Server Setup and Verification Checklist

This checklist is designed for system administrators, DevOps engineers, and IT professionals deploying or maintaining a Preboot Execution Environment (PXE) server. PXE booting is a core technology for network-based operating system installation, diskless booting, and automated system provisioning. Use this list during initial setup, after significant network changes, or when troubleshooting boot failures to ensure all components from infrastructure to configuration are correctly aligned. The items are arranged in a logical operational flow, from prerequisite verification to final client testing.

• Verify Network Infrastructure Fundamentals — Ensure the physical and data link layers support PXE. Confirm the network switch ports connecting the PXE server and target clients are configured to allow broadcast/multicast traffic (DHCP/BOOTP) and are not blocked by port security or excessive spanning-tree settings. The server must be on the same VLAN as the clients, or DHCP relay (ip-helper) must be correctly configured on intervening routers to forward DHCP and BOOTP packets.
• Confirm DHCP Server Configuration & Scope — This is a critical and often misconfigured step. The DHCP server (which can be the same as the PXE server or a separate appliance) must provide, in addition to an IP address, the next-server (option 66, tftp-server-name) and boot filename (option 67, bootfile-name) options. For UEFI clients, the boot filename is typically `grubx64.efi` or `shimx64.efi`. For legacy BIOS, it's often `pxelinux.0`. Ensure the DHCP scope has sufficient free IP addresses and that the server's IP is static.
• Install and Configure TFTP Server — The Trivial File Transfer Protocol (TFTP) server hosts the initial boot files. Install a reliable TFTP daemon (e.g., `tftpd-hpa`). Verify it is running and bound to the correct interface. Crucially, check that the server's firewall (iptables/nftables, firewalld) allows UDP port 69. The TFTP root directory (e.g., `/var/lib/tftpboot/`) must exist and have correct permissions (world-readable).
• Populate TFTP Root with Boot Files — This is a key step. Copy the necessary bootloader files to the TFTP root. These typically include:
  • PXELINUX (for BIOS): `pxelinux.0`, `ldlinux.c32`, `menu.c32`, and the `pxelinux.cfg/` directory.
  • GRUB2 (for UEFI): `shimx64.efi` (for Secure Boot), `grubx64.efi`, and `grub.cfg` or architecture-specific directories.
  • The kernel (`vmlinuz`) and initial ramdisk (`initrd.img`) for your target OS.
  Ensure all files, especially NFS or symlinks, are within the TFTP root and accessible.
• Set Up Network File Sharing Service — The installation files (e.g., OS repositories) are served via HTTP, HTTPS, NFS, or FTP. An HTTP server (Apache, Nginx) is most common. Verify the service is running, the document root contains the full OS installation tree (e.g., extracted ISO), and the firewall allows traffic on the chosen port (80, 443). Test access from another host using `curl` or a web browser.
• Configure Bootloader Menu — Define the boot menu that the client will see. For PXELINUX, edit the default file in `pxelinux.cfg/` (often named `default` or by the client's IP in hex). For GRUB2, edit `grub.cfg`. The configuration must point to the correct kernel and initrd paths (using the network share URL, e.g., `http://pxeserver/os/linux/vmlinuz`) and pass the correct kernel parameters (like `inst.repo=http://pxeserver/os/linux/`).
• Validate File Paths and Permissions — An easily missed item. Walk through the entire path from bootfile to installed. Use `tftp localhost` to test retrieval of `pxelinux.0`. Use `wget` or `curl` to test downloading the kernel and initrd from the network share URL you configured in the bootloader menu. All files must be readable by the unprivileged user context the services run under.
• Test with a Known-Good Client — Conduct a controlled test. Configure a virtual machine or a physical machine to boot from the network (NIC). Monitor the server logs (`/var/log/syslog`, `journalctl -u dhcpd -u tftpd -f`) in real-time. Observe the client's DHCP request, the TFTP file transfers, and the subsequent HTTP requests for the kernel. Failure at the DHCP stage indicates network/DHCP issues. TFTP timeouts point to firewall or file permission problems. Kernel panics often point to incorrect initrd or kernel parameters.
• Document the Configuration — Record all critical parameters: DHCP scope and options, TFTP root path, network share paths, bootloader configuration snippets, and any client-specific exceptions. This is vital for disaster recovery and team knowledge sharing.

Key Reminders

Dual-Stack Environments (BIOS/UEFI): Modern environments must support both legacy BIOS and UEFI clients. This often requires two separate sets of boot files and potentially different DHCP configurations (using DHCP options 93 and 94 for client architecture identification). Failure to configure both is a common cause of "PXE-E53: No boot filename received" for UEFI clients.

Firewall is the Primary Suspect: Over 50% of PXE failures are due to host-based or network firewalls blocking UDP 67/68 (DHCP), UDP 69 (TFTP), or the ports for your file sharing service (80, 443, 2049 for NFS). Isolate the firewall as a first troubleshooting step.

Secure Boot with UEFI: If clients have Secure Boot enabled, you must use a signed bootloader chain. This typically means using `shimx64.efi` (signed by Microsoft's 3rd-party CA) and a GRUB binary signed by a key enrolled in shim. Using an unsigned `grubx64.efi` will cause a Secure Boot violation.

--- Checklist End ---
Print this list for your server rack or runbook. Systematizing these steps reduces deployment errors by an estimated 70%.