Network booting lets computers start up from a centralized server instead of a local drive. If you manage multiple machines, configuring this capability saves hours of manual work. At the center of this process is the Preboot eXecution Environment, known as PXE.
When a machine powers on, its network interface card interacts with firmware extensions to fetch operating system installers over the local network. Setting this up requires understanding how option ROMs work inside your motherboard's firmware and how to configure your network infrastructure correctly.
Understanding PXE Boot Option ROM
An option ROM is a small piece of executable code stored on a hardware component's flash memory or loaded by system firmware during the Power-On Self-Test. In the context of network booting, the PXE option ROM initializes the network interface controller before the primary operating system loads.
During boot, the system BIOS or Unified Extensible Firmware Interface initializes the PCIe devices. When it detects an Ethernet controller with PXE capabilities, it executes the option ROM code. This firmware extension grabs control of the boot sequence, bypassing local storage devices like NVMe drives or hard disks.
The option ROM initiates a DHCP broadcast request. This broadcast asks the local network for an IP address and instructions on where to find the bootstrap program. Without this firmware routine embedded or injected into the system firmware, modern motherboards wouldn't know how to speak to a network boot server prior to loading an OS.
How the PXE Boot Sequence Works
The network boot process follows a strict sequence of network protocols. Knowing each phase helps you troubleshoot failures when client machines hang during startup.
- Client Broadcast (DHCP Discover): The client machine powers on, loads the option ROM, and broadcasts a DHCP request packet containing a specific PXE vendor class identifier.
- DHCP Offer and Options: The local DHCP server (or a specialized proxy DHCP server) responds with an IP address, subnet mask, and specific boot options. These options include the next-server IP address and the filename of the initial boot file.
- Download Bootstrap (TFTP): Using Trivial File Transfer Protocol, the client downloads the initial boot loader file, such as pxelinux.0 or an equivalent UEFI binary like bootx64.efi, from the specified server.
- Execution and Control: The client executes the downloaded boot loader. This loader then fetches configuration files, kernel images, and root filesystems via TFTP or HTTP to finish booting the operating system installer or live environment.
Configuring PXE Boot in BIOS and UEFI
Setting up client machines to use network booting requires adjusting firmware settings. Depending on the age of your hardware, you'll encounter either legacy Option ROM settings or modern UEFI network stack configurations.
For legacy systems using the older BIOS interface, you must enter the setup utility during startup. Locate the Boot tab or Advanced settings, find the Network Boot or PXE Boot option, and enable it. You must also ensure the option ROM execution policy is set to allow network execution.
For UEFI systems, the procedure changes slightly. UEFI relies on network drivers built directly into the firmware or loaded as drivers. You need to enable the UEFI Network Stack in the BIOS settings. Once enabled, configure the boot priority list so that the IPv4 or IPv6 network stack appears above local hard drives.
If your motherboard lacks an integrated PXE option ROM for a specific add-in network card, you can flash an option ROM image directly to the network card's EEPROM using vendor utilities, or chainload via a USB drive containing a standalone network boot image like iPXE. For official guidance on configuring network stacks and firmware interfaces, consult the UEFI Forum Specifications.
Setting Up Your Network Boot Infrastructure
A successful deployment requires three main server components working together on your local network: a DHCP server, a TFTP server, and a file staging server.
First, ensure your DHCP server can pass boot file parameters. If you run an ISC DHCP server on Linux, your configuration file needs specific directives pointing to your boot server:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.200;
option routers 192.168.1.1;
next-server 192.168.1.50;
filename "pxelinux.0";
}
Second, set up a TFTP daemon on the server hosting your boot files (such as 192.168.1.50). TFTP is connectionless and lightweight, making it ideal for transferring small files before the full TCP/IP stack is initialized on the client. Place your boot menus and kernel files inside the designated TFTP root directory, typically /var/lib/tftpboot on Linux distributions.
Third, for faster transfers in modern environments, configure an HTTP or NFS server alongside TFTP. While TFTP handles the initial tiny bootstrap loader, HTTP handles larger operating system images much faster, preventing frustrating timeouts during heavy enterprise rollouts. For detailed documentation on setting up secure network services, check the Red Hat Enterprise Linux Deployment Guide.
Common Mistakes and Troubleshooting
Network booting involves many moving parts, which means misconfigurations happen frequently. Watch out for these common pitfalls:
- Firewall Blocks: TFTP uses UDP port 69 for initial requests, but it switches to random high ports for data transfer. If your server firewall blocks incoming UDP traffic on high ports, the client will hang indefinitely after downloading the first few bytes.
- Mismatched Architectures: Trying to boot a UEFI client with a legacy BIOS bootloader will fail instantly. Ensure your DHCP server checks the client architecture type and serves the correct binary (pxelinux.0 for legacy, bootx64.efi for 64-bit UEFI).
- Network Switch Issues: Managed switches with Spanning Tree Protocol enabled can delay port initialization. By the time the switch port transitions to forwarding mode, the client's DHCP broadcast has already timed out. Enable PortFast or edge port settings on your switch ports.
- Corrupted Option ROMs: If a motherboard's option ROM is outdated or corrupted due to a failed BIOS update, the network card won't initialize. Flash the motherboard to the latest stable version provided by the manufacturer.
Frequently Asked Questions
Can I use PXE boot over Wi-Fi?
Most hardware implementations do not support PXE booting over wireless networks. Option ROMs for wireless cards rarely include preboot driver support for Wi-Fi authentication protocols like WPA2 or WPA3. Stick to wired Ethernet connections for network booting.
Why does my client freeze at "PXE-M0F: Exiting PXE ROM"?
This error means the network card's option ROM executed successfully and broadcasted a DHCP request, but it received no valid reply from a DHCP server configured with boot options. Check your network cables, ensure the server is running, and verify your DHCP scope settings.
Do I need a dedicated server for network booting?
No. You can run DHCP, TFTP, and deployment tools on existing infrastructure, or use lightweight open-source tools like FOG Project on a spare Linux machine or virtual private server within your local network.
Is PXE booting secure?
Standard PXE booting transmits data in plaintext over the local network using TFTP and DHCP, making it vulnerable to eavesdropping or rogue server spoofing on untrusted networks. For high-security environments, implement secure boot chains, isolate your deployment VLAN, or use authenticated network booting solutions.
