5 Practical PXE-Boot Tricks Every Aspiring Sysadmin Should Know

March 15, 2026

5 Practical PXE-Boot Tricks Every Aspiring Sysadmin Should Know

1. Master the DHCP "Next-Server" Option

Think of your network like a postal system. When a new computer (the client) boots up and shouts "Where do I go?", your DHCP server is the friendly postmaster that doesn't just give an address, but also a specific delivery instruction. That instruction is the "next-server" option (option 66 in DHCP terms). This is the single most critical configuration for PXE to work. It tells the client exactly which TFTP server to contact for the boot files. Why it works: It eliminates guesswork. Without this, the client receives an IP but has no idea where to find the bootloader. How to do it: In your DHCP server configuration (like on an ISC DHCP server), simply add the line next-server 192.168.1.10; (using your TFTP server's IP) within the relevant subnet declaration. It's a one-line change with an immediate, massive impact.

2. Tame the TFTP Root with Symlinks

PXE boot files often have long, complex paths embedded in them. Instead of wrestling with your TFTP server's configuration to set a non-standard root directory, use the power of symbolic links (symlinks). It's like creating a shortcut on your desktop that points to a folder buried deep in your documents. Why it works: It keeps your TFTP configuration simple and default, while allowing you to organize your boot files logically elsewhere on your server's filesystem. This makes backups, updates, and management far cleaner. How to do it: Let's say your TFTP root is /var/lib/tftpboot, but you want your boot files in /srv/pxe. Simply run: sudo ln -s /srv/pxe /var/lib/tftpboot/pxe. Now, you can reference files as pxe/ubuntu/22.04/pxelinux.0 in your PXE menu, and the TFTP server will seamlessly find them in /srv/pxe/ubuntu/22.04/.

3. Implement a "Failover" Boot Menu with Local Disk

Always have a Plan B. A common frustration is a machine stuck in a PXE boot loop if the network or server is down. The insider trick is to configure your PXE menu (like pxelinux) to default to booting from the local hard drive after a short timeout. Why it works: It ensures operational resilience. Your infrastructure can be down for maintenance, but workstations and servers can still boot and function, preventing unnecessary downtime. How to do it:

In your pxelinux.cfg/default file, structure your menu with a TIMEOUT directive (e.g., TIMEOUT 100 for 10 seconds) and make the first menu entry the local disk. For syslinux/pxelinux, the entry often looks like:
LABEL local MENU LABEL Boot from Local Disk LOCALBOOT 0 DEFAULT local
This tells the system to try the local disk first (after the timeout) unless the user intervenes.

4. Use Kickstart/Preseed Files for Truly Hands-Off Installation
This is where automation magic happens. Manually installing an OS over PXE defeats half the purpose. The real power is in providing an answer file—Kickstart for Red Hat/CentOS/Fedora, Preseed for Debian/Ubuntu—alongside your boot image. Why it works: It automates the entire installation process: partitioning, user creation, package selection, and post-install scripts. You can deploy 50 identical servers as easily as one. How to do it: First, generate a starter file by doing a manual install on one system; both installers offer to save your answers. Place this file (e.g., ks.cfg or preseed.cfg) in your TFTP root or on a web server. Then, in your PXE kernel append line, simply point to it. For example:
append initrd=ubuntu-installer/amd64/initrd.gz auto=true url=http://192.168.1.10/preseed/ubuntu-2204.cfg quiet ---
The installer will fetch the file and follow its instructions, no questions asked.

5. Leverage iPXE for Modern Network Boot Features
Think of traditional PXE as dial-up and iPXE as broadband. It's an open-source enhanced boot firmware that replaces the initial PXE ROM. Why it works: iPXE supercharges your capabilities. It can boot from HTTP, HTTPS, iSCSI SANs, and even Wi-Fi, not just TFTP. This means faster transfers, more reliable large file downloads (like whole disk images), and secure booting. How to do it: You don't need to burn new ROMs. The easiest gateway is to chainload it. First, serve the undionly.kpxe file from your TFTP server as the initial boot file. Then, in an iPXE script (which is just a text file), you can write simple commands like:
#!ipxe chain http://boot.server/menu.php
This script, served via TFTP, will then tell the client to fetch its real boot menu from a dynamic web server, opening a world of scripting and logging possibilities. It's the first step into advanced, modern network provisioning.