PXE Boot and Network Installation

PXE — short for Preboot Execution Environment — is one of those tools you don't think much about until you need to reimage a system without plugging anything in. It's been around forever, and if you've worked with physical servers, you've probably used it — even if someone else set it up.

At its core, PXE lets a machine boot over the network. Instead of looking for a local disk or USB drive, the system's NIC takes over during boot, reaches out to a DHCP server, grabs a bootloader over the network, and starts loading an operating system installer. No physical media, no console access, just power and a network cable. This is especially valuable in bare metal environments.

It's not flashy, and it hasn't changed much in years — but that's kind of the point. It works reliably, it's built into just about every server NIC, and it fits neatly into everything from one-off installs to fully automated provisioning pipelines.

How PXE Works — and Why It's Still the Backbone of Provisioning

When a PXE-capable server powers on, it doesn't immediately boot from disk. If set to use PXE, the network interface steps in first. Using firmware baked into the NIC, it sends out a DHCP request — but not just for an IP address. It's also asking: “Where do I get my boot instructions?”

The DHCP server (or a proxy like dnsmasq) replies with the usual IP configuration and, crucially, a pointer to a bootloader file. That might be something like pxelinux.0 or an iPXE binary. The server grabs that file over TFTP or HTTP, runs it, and from there it can pull in a Linux kernel, an initrd, and kick off an installer.

From power-on to OS install, the whole thing runs over the network — with no USB stick, no console access, and no human intervention.

So why is PXE still the go-to tool for provisioning physical infrastructure?

Because it's dead simple. And it's universal. PXE is built into practically every server-grade NIC on the market. It doesn't need an OS. It doesn't need local storage. And once you've set up your PXE environment — DHCP, TFTP, maybe an HTTP server — you can provision dozens or hundreds of machines without ever leaving your desk.

Whether you're spinning up new nodes in a rack, building golden images in CI, or resetting a testbed between jobs, PXE gives you a clean slate — fast.

It's not the newest tech, and it won't win any points for elegance. But when it comes to getting bare metal ready to work, it's still the thing everything else builds on.

Where iPXE Fits Into the Picture

If you've been around PXE setups recently, you've probably come across iPXE. It's not a replacement for PXE — at least not directly — but more of a smarter bootloader that sits downstream of it.

In most modern workflows, PXE is just the first step: it gets the machine powered on and talking to the network. Then, instead of launching a basic bootloader like pxelinux.0, you hand control off to iPXE.

Why? Because iPXE gives you way more flexibility. It can pull boot files over HTTP (instead of the slower TFTP protocol PXE relies on), show you menus, run scripts, and even load kernels directly from a URL.

You can do things like:

• Pull a kernel and initrd over HTTPS from a remote URL
• Use scripting to choose an OS installer based on the MAC address
• Mount a root filesystem via iSCSI or NFS
• Chain into a live OS image or provisioning agent automatically

In setups like Cycle.io or MAAS, PXE is often just the handshake — the part that says “hey, I'm here.” iPXE is where the real provisioning logic lives.

So when someone says they're using PXE provisioning, they usually mean “we start with PXE, then use iPXE to actually do the work.”

If you're just getting started, that may sound like an extra layer — and it is — but once you've used iPXE for anything dynamic, you'll never go back.

PXE vs iPXE: What's the Difference?

What Makes It Tricky the First Time

The hard part with PXE isn't the idea — it's the wiring. You need DHCP to hand out not just an IP, but also a boot file path. You need TFTP (or HTTP if you're using iPXE) to serve the bootloader. And you need the right bootloader that matches your firmware mode — BIOS or UEFI.

Get one of those pieces wrong, and things break in silent, confusing ways. A machine might sit there doing nothing. Or it might try to boot and then hang mid-install. The error messages, if you get any, aren't always helpful.

That said, once you've set it up once — especially if you template your configuration — it's remarkably stable. PXE will happily serve up OS installs to dozens of machines in parallel with almost no supervision.

Compared to USB or Imaging?

You can always fall back on USB drives or disk imaging, but those approaches come with trade-offs. USB is fine when you're standing next to the machine. Imaging is great for duplicating a known-good config — but less ideal when each machine needs slightly different behavior or disk layouts.

PXE sits in the sweet spot: automated like imaging, but flexible like a fresh install. And because it uses standard protocols, it fits into almost any environment.

The Gotchas You'll Run Into Eventually

Sooner or later, PXE will throw you a curveball. Maybe the NIC doesn't support PXE in UEFI mode. Maybe your DHCP server isn't passing the right options. Maybe your bootloader expects a kernel that isn't there.

And sometimes the problem is embarrassingly simple: you're trying to PXE boot over the wrong NIC.

When in doubt, double-check:

• BIOS vs UEFI boot mode (they need different bootloaders)
• That your TFTP/HTTP server is reachable on the PXE VLAN
• That your DHCP scope has the right next-server and filename options
• That your kernel and initrd are compatible with the target hardware

Getting it working the first time can take some fiddling, but once it's dialed in, PXE becomes one of those invisible tools you stop thinking about — because it just works.