The preboot execution environment (PXE) lets you boot computers and virtual machines over a network. In this article, I describe how to set up a PXE server, go into detail about the role of the Dnsmasq service, and describe how to make individual PXE configurations.

BIOS

When a computer, whether physical or virtual, is switched on, a number of programs are executed before the operating system even starts. What the mainframe world refers to as initial program load (IPL) is commonly known in the PC world as booting. Technically speaking, this means that the processor sets the program counter to memory cell 0 and then works its way forward in memory until it finds executable program code. On a regular PC, what the CPU encounters first is the Basic Input Output System (BIOS) or, to be more precise, multiple BIOSs, because every device that is plugged into a PC is allowed to mount its own BIOS in memory. This code then runs before the operating system and initializes the hardware.

In a desktop PC, the graphics card BIOS is extremely important; otherwise, the screen would stay blank. On servers, which can get by without a graphics card if need be, a redundant array of independent disks (RAID) or storage area network (SAN) controller might need to run its BIOS first so that the booting operating system can find a hard disk. As early as in the 1980s, an option was introduced to run the system boot over a local area network (LAN) with a BIOS on the network interface card (NIC). At that time, however, competing NIC manufacturers used proprietary boot code. It wasn't until 1998 that Intel introduced the PXE 2.0 specification, which has been used for all systems ever since.

PXE has evolved in the meantime. Strictly speaking, two different network boot processes are in use: PXE for PCs with BIOS and PXE for systems with (Unified) Extensible Firmware Interface (U)EFI (Figures 1 and 2). In this article, I go into more detail about both processes.

Figure 1: Most PC BIOSs let you choose between UEFI and BIOS (legacy) boot for the system start, which changes the way the PC then boots via PXE.

Figure 2: Hypervisors, such as VMware ESXi shown here, support both UEFI and BIOS boot modes for PXE virtual machine boot.

PXE Basics

Every modern PC or server with a built-in network card can now boot its operating system over the LAN with PXE. Administrators primarily use this function to install new computers, but PXE can do more. Users can use PXE to boot diskless workstations or even computers that use an Internet SCSI (iSCSI) SAN drive as a disk, which naturally gives you an excellent disaster recovery option. Users can simply push continuous backups of their local drive onto an iSCSI volume. If the local disk fails, they simply boot the system by PXE and use the iSCSI copy as the root drive.

The PXE method is based on a number of standard IP protocols, starting with the Dynamic Host Configuration Protocol (DHCP). The client first sends a DHCPDISCOVER message as a Layer 2 broadcast – because it does not yet have an IP address – and waits for the response from a DHCP server. In this first request, the client also transmits its system type (i.e., whether it is booting from BIOS or UEFI). The DHCP server responds to the request with a DHCPOFFER, which contains a good bit of information: the IP address the client is allowed to use and the lease time (i.e., how long it is allowed to keep this address), plus masses of network details relating to the network mask, routes, and DNS servers.

Depending on the services on the LAN, the DHCP server can also provide information about Active Directory (AD), the time servers, or other information. If a boot server for PXE resides on the network, DHCPOFFER sends both the server's IP address and details of the boot code. The PXE boot server can run on a machine other than the DHCP server. In this example, the two services are running together. The client responds to the "offer" with a "request" stating that it wants to keep the offered IP address, and DHCP concludes the process with an "acknowledge."

If the client now wants to boot off the LAN, it first uses the Trivial File Transfer Protocol (TFTP) in both boot methods to fetch the start code from the boot server. TFTP is basically the junior sibling of the well-known File Transfer Protocol (FTP), except that TFTP does not support authentication or any kind of security function (e.g., encryption). Because the protocol uses a very small block size, it limits the transfer size for files to a maximum of 4GB, and it is also quite slow, although this is not a problem, seeing as just a few kilobytes are typically all you need to transfer a kernel or a bootloader. TFTP usually only transfers the first bootloader anyway. Afterward, the procedure can switch to a regular IP protocol such as HTTP, HTTPS, (S)FTP, or even NFS.

Putting the Boot Server into Operation

To leverage the full functionality of PXE and DHCP, you need your own DHCP server that is based on a Linux computer or a Linux virtual machine (VM). Normally, you will already have a DHCP server on the LAN. In smaller networks, the router itself is more likely to handle this role. Of course, you can only have one DHCP server on a LAN. You will need to disable the existing DHCP server, if any, and transfer this task to the new server.

On your system of choice, first install the dnsmasq and syslinux packages. Next, create a directory for the TFTP server, typically in /var/lib/tftpboot. Then, copy the complete content of the Syslinux installation (in /usr/share/syslinux on Fedora) into the tftpboot directory. You only need this step for PXE with BIOS PCs.

Now, install a web server such as Apache or Nginx with the default configuration. In the remainder of this article, I assume that the web server serves up the files from /var/www/html and its subdirectories in the basic configuration.