PXE

What It Is

PXE (Preboot eXecution Environment, pronounced "pixie") is a standard for booting a computer from a network server instead of a local disk. Developed by Intel as part of the "Wired for Management" framework, the current version (2.1) dates from 1999 and is now incorporated into the UEFI specification.

PXE is how data centers provision machines, how enterprise IT deploys OS images at scale, and how FortrOS bootstraps new nodes onto the org.

Why It Matters

Without PXE, installing an OS on a new machine requires physical interaction: plug in a USB stick, insert a CD, or pre-write a disk image. PXE eliminates this for any machine connected to a network. Power on the machine, and it finds a boot server automatically.

This is essential for:

Data centers: Provisioning hundreds of servers without physical access
Self-organizing clusters: New hardware joins the cluster by booting from existing members
Recovery: A machine with a corrupted local disk can still boot from the network

How It Works

The Boot Sequence

PXE requires three things on the network: a DHCP server (to assign IP addresses and tell clients where to find boot files), a TFTP server (to serve the boot files), and the boot files themselves.

Step 1 -- DHCP Discovery: The NIC's built-in PXE firmware sends a DHCP request with PXE-specific options (vendor class identifier "PXEClient"). A PXE-aware DHCP server responds with:

An IP address for the client
The TFTP server's IP address (option 66 or "next-server")
The filename of the Network Bootstrap Program (option 67)

Step 2 -- TFTP Download: The client downloads the NBP (Network Bootstrap Program) from the TFTP server into RAM. TFTP is a deliberately simple protocol: UDP-based, no authentication, no encryption, block-by-block transfer with stop-and-wait acknowledgment. This simplicity is why every NIC can implement it in firmware.

Step 3 -- NBP Execution: The NBP runs in the UEFI (or BIOS) environment. It's the first link in a chain. Typically the NBP downloads additional files (a Linux kernel + initramfs) via TFTP, then hands off to the kernel. From there, the booted OS uses its own network stack for everything else.

The Network Stack in Firmware

PXE works because the NIC has a small firmware component (historically called an "option ROM," now typically a UEFI driver) that provides:

UNDI -- Universal Network Device Interface (hardware abstraction for the NIC)
UDP/IP stack -- Minimal networking
DHCP client -- IP address acquisition
TFTP client -- File download

This stack is intentionally minimal. It's designed to work reliably on thousands of different NIC models with a tiny code footprint. Once the OS kernel is loaded and has its own network drivers, the PXE firmware stack is discarded.

TFTP Limitations

TFTP (Trivial File Transfer Protocol, RFC 1350, 1981) has significant limitations that are features in context:

No authentication: Anyone on the network can request any file. Fine for LAN provisioning; terrible for anything internet-facing.
No encryption: Transfers are plaintext. The boot image must be integrity-verified by other means (Secure Boot, hash checking).
Slow: Stop-and-wait per block (default 512 bytes, negotiable up to 65535). No windowing, no pipelining. Large files transfer slowly.
UDP only: No connection state, no reliable delivery. Lost packets are retransmitted per-block.

These limitations mean PXE is a LAN-only technology. You don't PXE boot over the internet.

iPXE: PXE With Features

iPXE is an open-source network boot firmware that extends PXE with modern capabilities:

Feature	PXE	iPXE
TFTP	Yes	Yes
HTTP/HTTPS	No	Yes
DNS resolution	No	Yes
Scripting	No	Yes (embedded scripts, menus)
iSCSI / AoE	No	Yes (boot from SAN)
Wi-Fi	No	Limited (some drivers)
TLS	No	Yes

iPXE can be deployed two ways:

Chainloaded: The stock PXE ROM loads iPXE via TFTP, then iPXE takes over with its richer protocol stack. This is the most common approach.
Reflashed: iPXE firmware is written directly to the NIC's ROM, replacing the stock PXE implementation.

UEFI HTTP Boot

UEFI specification 2.5 (2015) added native HTTP boot support. The firmware fetches boot images directly over HTTP/HTTPS using TCP -- no TFTP, no iPXE needed. Advantages over PXE/TFTP:

TCP windowing (fast transfers, not stop-and-wait)
Works over routed networks and the internet (DNS-based URLs)
TLS for secure transport
Standard HTTP caching

HTTP boot uses DHCP options to discover the boot URL. It can coexist with traditional PXE on the same network.

How FortrOS Uses It

FortrOS uses PXE for two purposes:

Bootstrap (first-ever boot): A new machine PXE boots from an existing FortrOS node running the provisioner service. The provisioner serves a minimal bootstrap image via TFTP (or HTTP boot where supported). The bootstrap image connects to the org over TLS, downloads the real preboot UKI, writes it to the local ESP, and reboots. After this, the machine boots from local disk and never needs PXE again.

Recovery: If a node's ESP is corrupted, it can PXE boot from any other org node to re-provision. Since every FortrOS node has the org's boot images in shard storage, any node can serve as a recovery PXE server.

PXE is not used for normal boot. Normal boot is always from the local ESP. This is important: PXE depends on network availability and a functioning PXE server. Local boot depends on local hardware and TLS authentication to the org (the preboot connects to the org gateway to get generation materials and verify authorization).

Alternatives

USB boot: Physical media instead of network. Works without any network infrastructure. Requires physical access to the machine.

UEFI HTTP Boot: The modern successor to PXE/TFTP for network provisioning. Faster, works over the internet, supports TLS. Not all firmware implementations support it yet.

Cloud-init / metadata services: For VPS and cloud deployments, the hypervisor delivers the OS image out-of-band (written to virtual disk before the VM starts). No PXE needed because the infrastructure provider handles delivery.

Ignition (Flatcar/Fedora CoreOS): A first-boot provisioning system that reads config from a cloud metadata service or URL. Not a boot method itself (still needs PXE, ISO, or disk image to boot initially), but handles the "configure this machine" step that PXE alone doesn't address.

PXE