Master PXE and iPXE Setup: Configure DHCP, TFTP, UEFI Boot

Introduction

Setting up pxe, ipxe, dhcp, tftp, uefi for automated OS deployment can feel like wiring a digital assembly line for your servers. PXE and iPXE streamline network-based booting by using DHCP for configuration and TFTP for file transfers, while UEFI ensures secure, modern firmware compatibility. This guide walks you through configuring, securing, and optimizing PXE and iPXE environments to automate bare metal provisioning and improve IT performance.

Prerequisites

Alright, before diving into PXE and iPXE setups, let’s get comfy with some basics. You’ll want to really get how IP addressing , DHCP , and TFTP work, because these three are the backbone of PXE boot and iPXE boot operations when you’re setting up bare metal provisioning. Think of them as the teamwork trio that gets your machine talking to the network before an OS is even installed. DHCP , for example, is like the network’s friendly host handing out IP addresses and letting devices know where to grab their boot files. Meanwhile, TFTP (yep, that’s Trivial File Transfer Protocol) is the lightweight courier that delivers those boot files to kick off the startup process.

You’ll also need a good handle on BIOS and UEFI boot systems. These two decide how your machine wakes up and gets going. Older systems rely on BIOS , but most newer ones use UEFI , which is way more flexible and secure. Understanding how BIOS differs from UEFI—especially when it comes to things like handling network cards, verifying boot files, and recognizing different file types—makes a huge difference when troubleshooting. UEFI even adds extra perks like Secure Boot and advanced options that can affect how PXE and iPXE behave.

Now, let’s talk PXE and iPXE a bit more. PXE (you can think of it as the classic network boot method) sets the foundation, while iPXE comes in as its more powerful, modern cousin. PXE helps machines boot from the network, but iPXE takes it up a notch by adding cool features like scripting, HTTP-based transfers, and user authentication. Knowing the differences and how PXE’s server and client talk to each other will make setting things up way smoother and help you spot any compatibility hiccups between your hardware and software early on.

If you’re working with bare metal servers—those dedicated machines without virtualization—understanding automated OS deployment will make your life much easier. In big enterprise or cloud setups, bare metal provisioning lets you use the full power of your hardware without any virtual layers slowing things down. That’s a huge deal for things like AI or ML training, running databases, or handling heavy compute tasks. You’ll also find it handy to know how automation tools like Kickstart , Preseed , or cloud-init scripts fit into the PXE or iPXE workflow. These tools are your secret weapons for cutting down repetitive manual setup work and making deployments faster and cleaner.

Oh, and if you’re serious about troubleshooting, getting comfortable with iPXE commands, the Linux shell, and networking tools like Wireshark is a must. Wireshark is awesome—it lets you peek into network traffic, so you can see if your PXE client isn’t getting its DHCP response or if TFTP transfers are lagging. At the same time, being able to use iPXE’s command line tools gives you hands-on control to test connections, run scripts, or debug boot issues on the spot.

Once you’ve mastered these basics, you’ll have the confidence and know-how to design, configure, and troubleshoot PXE and iPXE environments like a pro. That means smoother, faster, and more reliable automated OS deployments across your infrastructure, whether you’re working with BIOS or UEFI, tinkering with DHCP, or juggling TFTP servers.

Read more about setting up network booting with PXE and iPXE, including dhcp and tftp details, via this guide: The Fundamentals of Network Booting

Setting Up PXE and iPXE for Bare Metal Servers

Alright, now that you’ve got a good idea of how pxe and ipxe work, it’s time to roll up your sleeves and actually set things up. We’re going to build a complete PXE/iPXE environment for bare metal provisioning, step by step, so you’ll know exactly what’s going on and why.

First things first, your network needs to be in top shape. This setup relies heavily on a solid, stable, and well-organized network because every server has to chat smoothly with dhcp , tftp , and http services. You definitely don’t want those communications dropping mid-boot. So before anything else, make sure your network interfaces, routing, and firewall rules all line up nicely with your PXE design.

Let’s talk prerequisites for setting up PXE and iPXE. Before you jump in, start with a strong, well-documented network foundation. The easiest way is to keep all your servers on the same LAN. That way, your PXE clients can talk directly to your PXE server without getting lost in translation. But hey, if your servers are scattered across subnets, no worries—you can set up a dhcp relay (also known as an IP Helper) to pass PXE and DHCP requests across networks.

Using VLANs? Smart move. They help you separate provisioning traffic from everything else—like production or management traffic—so you don’t accidentally send a boot image to the wrong machine or expose sensitive network info.

Once your network’s ready, check your bare metal servers. Make sure PXE boot is enabled in the BIOS or UEFI settings, and put the NIC (network card) at the top of the boot order. If you miss that step, your machine might skip right over network booting, leaving you scratching your head.

Next, set up a DHCP server. It’s what hands out IP addresses and points your servers to the right boot file. Alongside that, you’ll need a TFTP server to handle file transfers for bootloaders and config files. And if you’re going big with iPXE, I recommend throwing in an HTTP server too. It’s much faster and more reliable than TFTP for large-scale or high-speed setups.

Now, gather all your boot files. You’ll need things like pxelinux.0 , bootx64.efi , and ipxe.efi , plus your OS images. Keep them all in one place on your PXE server, ideally one with a static IP address so your clients can always find it.

A quick best practice before you go live—document everything. Write down IP ranges, server IPs, and where your services live. It might sound boring, but trust me, it’ll save you hours later. And don’t forget to test on a single machine before you deploy to production. Catching small mistakes early beats fixing big ones in a panic.

Setting Up a PXE Server

PXE needs two key services: DHCP and TFTP. DHCP gives your client an IP and tells it where to find the boot file, while TFTP actually delivers that file over the network.

Installing and Configuring DHCP with PXE Options

If your network doesn’t already have a DHCP service for PXE, you’ll need to install one. On Debian or Ubuntu, just run:

$ sudo apt update && sudo apt install isc-dhcp-server

On Red Hat-based systems like CentOS or AlmaLinux, use:

$ sudo dnf install dhcp-server

After installing, make sure the DHCP service starts automatically on boot. Now, open your DHCP config file (usually /etc/dhcp/dhcpd.conf ) and set up your subnet, IP range, gateway, and DNS info. Also, don’t forget to include:

allow booting;
allow bootp;

Here’s a quick example:

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.50 192.168.1.100;
    option routers 192.168.1.1;
    option domain-name-servers 192.168.1.1;
    …
}

Then, define PXE-specific options:

next-server 192.168.1.10;

Option 67 defines which boot file to use. For BIOS clients, it’s usually pxelinux.0 . For UEFI clients, use something like bootx64.efi .

If you’ve got both BIOS and UEFI clients, you can use a little conditional magic:

if option arch = 00:07 {
    filename “bootx64.efi”; # UEFI x86-64
} else {
    filename “pxelinux.0”;  # BIOS
}

Architecture codes like 00:07 mean x64 UEFI, 00:06 means x86 UEFI, and 00:00 or 00:09 are for BIOS.

Now, start up the DHCP service:

$ sudo systemctl start isc-dhcp-server

Then check your logs ( /var/log/syslog or /var/log/messages ) to confirm it’s running smoothly.

Installing and Configuring the TFTP Server

Let’s get TFTP up and running. On Ubuntu or Debian, run:

$ sudo apt install tftpd-hpa

For Red Hat systems, use:

$ sudo dnf install tftp-server

Once installed, enable it, and make sure your firewall allows UDP port 69. Now, create the TFTP root directory (usually /var/lib/tftpboot ):

$ sudo mkdir -p /var/lib/tftpboot
$ sudo chmod -R 755 /var/lib/tftpboot

Next, drop in your PXE boot files:

• pxelinux.0
• ldlinux.c32 , libcom32.c32 , libutil.c32 , menu.c32 (or vesamenu.c32 )

Then make a config directory for PXELINUX:

$ mkdir -p /var/lib/tftpboot/pxelinux.cfg

Inside it, create a file called default :

DEFAULT menu.c32
PROMPT 0
TIMEOUT 600
MENU TITLE PXE Boot Menu</p>
<p>LABEL linux
  MENU LABEL Install Linux OS
  KERNEL images/linux/vmlinuz
  APPEND initrd=images/linux/initrd.img ip=dhcp inst.repo=http://192.168.1.10/os_repo/</p>
<p>LABEL memtest
  MENU LABEL Run Memtest86+
  KERNEL images/memtest86+-5.31.bin</p>
<p>LABEL local
  MENU LABEL Boot from local disk
  LOCALBOOT 0

If your OS needs extra files, like a full installer ISO, you can host it over HTTP or NFS. Just mount the ISO and share it using your web or NFS server so clients can grab what they need.

Now, restart TFTP:

$ sudo systemctl restart tftpd-hpa

Installing and Configuring iPXE

Alright, now let’s spice things up with iPXE. It’s like PXE’s cooler big sibling that can handle HTTPS, scripting, and even booting straight from the cloud.

You can grab iPXE binaries two ways:

• Precompiled Binaries: Great for quick testing—use files like undionly.kpxe or ipxe.efi .
• Compile from Source: Perfect if you want to customize, add HTTPS, or embed scripts.

$ sudo apt install -y git make gcc binutils perl liblzma-dev mtools
$ git clone https://github.com/ipxe/ipxe.git
$ cd ipxe/src
# Build BIOS PXE binary
$ make bin/undionly.kpxe
# Build UEFI PXE binary (x86_64)
$ make bin-x86_64-efi/ipxe.efi

If you want to add a startup script, include EMBED=script.ipxe in your make command.

Now tweak your DHCP config to load iPXE next. For BIOS, set the filename to undionly.kpxe ; for UEFI, use ipxe.efi .

To stop infinite boot loops, tell DHCP how to recognize iPXE clients:

if exists user-class and option user-class = “iPXE” {
    filename “http://192.168.1.10/”;
} else {
    filename “undionly.kpxe”;
}

Next, install an HTTP server for iPXE. On Ubuntu, it’s simple:

$ sudo apt install apache2

Then, create an iPXE script under /var/www/html/ to tell clients what to do:

#!ipxe
kernel http://192.168.1.10/os_install/vmlinuz initrd=initrd.img nomodeset ro
initrd http://192.168.1.10/os_install/initrd.img
boot

Finally, copy your OS install files (like vmlinuz and initrd.img ) into /var/www/html/os_install/ . You can even add big files like Linux ISOs or Windows PE images here for direct network booting.

Before wrapping up, test your web server with curl or a browser to confirm everything’s reachable.

Once that’s done, your PXE and iPXE setup is fully ready to roll. You’ll be deploying operating systems over the network like a pro—fast, automated, and completely hands-free.

Learn how to configure bare metal provisioning with Foreman’s Bare Metal Provisioning Guide: PXE and iPXE workflows

Creating iPXE Boot Scripts

You know how sometimes you wish the whole boot process could just run itself? Well, that’s exactly where iPXE scripts come in. One of the coolest and most powerful things about iPXE is its scripting capability. These iPXE scripts let you, as an admin, build dynamic and automated boot setups that make provisioning servers way smoother. Basically, they take what’s normally a rigid, step-by-step boot process and turn it into something smart, flexible, and programmable. You can add conditions, build menus, and even automate full operating system installations without needing to sit there and babysit the process.

Here’s how it works: writing an iPXE script is like creating a small story for your machine to follow. You make a simple text file packed with iPXE commands, and it always starts with a shebang line— #!ipxe . That line tells iPXE, “Hey, what follows are your instructions!” From there, you can build menus, tweak kernel parameters, choose operating systems, or automate installs however you like. This setup is a lifesaver when you’re managing lots of servers, since automation slashes setup time and saves you from doing the same steps over and over again.

Core iPXE Commands

Let’s talk about the basics of iPXE scripting. There are a few key commands you’ll see all the time, and they’re like the backbone of every script:

• kernel – This tells iPXE which kernel or boot loader to grab and run. It’s basically the GPS for finding the boot image on the server.
• initrd – This command loads the initial ramdisk (the temporary storage space used during boot). It’s what helps your hardware start up and mount the system before the real OS takes over.
• boot – Think of this as the “go” button. Once iPXE has the kernel and initrd, this command actually starts the boot process and hands control to the kernel.
• chain – This is for the clever folks who want to layer configurations. It hands control over to another script or bootloader, letting you build flexible, multi-stage boot setups.

But that’s just scratching the surface. iPXE scripting also includes flow control commands like goto and ifopen , along with interactive menu commands such as menu , item , and choose . These make it possible to design scripts that don’t just boot blindly—they make choices, display menus, and react to user input. It’s like giving your servers a little personality.

Another neat trick is embedding a small iPXE script that uses the chain command to load a remote file like boot.ipxe from a web server. This means all your boot configurations can live in one central place, so when you update that one file, every server automatically gets the new setup. No need to touch each machine.

Example: Interactive Boot Menu

Here’s a fun example: say you want an interactive boot menu. You can make a script file called menu.ipxe and drop it on your web server—or even embed it directly in the iPXE firmware. Check this out:

#!ipxe
console –x 1024 –y 768  # set console resolution (optional)
menu iPXE Boot Menu
item –key u ubuntu Install Ubuntu 22.04
item –key m memtest Run Memtest86+
choose –timeout 5000 target || goto cancel</p>
<p>:ubuntu
kernel http://192.168.1.10/boot/ubuntu/vmlinuz initrd=initrd.img autoinstall ds=nocloud-net;s=http://192.168.1.10/ubuntu-seed/
initrd http://192.168.1.10/boot/ubuntu/initrd.img
boot</p>
<p>:memtest
kernel http://192.168.1.10/boot/memtest86+
boot</p>
<p>:cancel
echo Boot canceled or timed out. Rebooting…
reboot

Pretty cool, right? This script sets up a simple, easy-to-read menu that pops up during boot. You get two main choices here:

• Ubuntu Installation: If you hit “u,” the script grabs the kernel and initrd from an HTTP server, then kicks off an automated Ubuntu installation. It uses cloud-init and the nocloud-net method to fetch all its configuration info. Translation: it installs everything by itself, no clicks required. Perfect for data centers or anyone managing dozens (or hundreds) of servers.
• Memory Diagnostics: If you hit “m,” iPXE downloads and boots Memtest86+ right from the server. That way, you can test your machine’s RAM instantly without having to burn a CD or plug in a USB stick.

If you don’t make a selection in 5 seconds (that’s set by the choose --timeout command), the script jumps to the :cancel section. It politely lets you know the boot was canceled or timed out, and then reboots automatically.

This example really shows how iPXE makes booting faster and smarter. Instead of relying on old-school tftp file transfers like regular PXE, iPXE can pull files via HTTP, which is quicker and more reliable. It also supports web-based automation tools, so you can build complex setups that still feel seamless. Using options like autoinstall and ds=nocloud-net , iPXE can talk to cloud-init and dynamically inject setup data during the OS install—making everything truly hands-free.

And don’t underestimate how powerful it is as a diagnostic tool. The Memtest option shows how you can use iPXE for hardware testing, letting you spot issues with system memory or other hardware before you even install the OS.

At the end of the day, this little script captures what makes iPXE so awesome. It’s flexible, fast, and smart. You can manage boot operations remotely, automate all the tough stuff, and get your machines running with zero physical interaction. Whether you’re working with dhcp , tftp , or uefi systems, iPXE helps bring automation and control right to your fingertips.

Want to dive deeper into creating scripts for iPXE and all the nitty-gritty details of network booting? Check out this guide on iPXE scripting and command reference

Security Implications of Network Booting and Mitigations

Let’s be honest, network booting is awesome, but if it’s not set up right, it can open some pretty scary holes in your infrastructure. Since pxe and ipxe both rely on the network and start before your operating system or security tools even kick in, bad actors can take advantage of that. For example, someone could pretend to be your dhcp or tftp server and sneak in a malicious boot image. That fake image might install backdoors or mess with firmware settings, and before you know it, they’ve got access across your entire network.

To stop that from happening, you’ve got to build solid, layered defenses and make sure your provisioning setup is completely separated from your production traffic. Here are a few ways to make your PXE and iPXE setups safer:

Use Separate VLANs

Always keep your provisioning network apart from your main one. The easiest way to do this is by creating a dedicated VLAN or subnet just for PXE and iPXE boot traffic. That way, random users or infected machines on your production network won’t be able to snoop on or interfere with provisioning data. Plus, when your boot traffic is isolated, you can apply stricter firewall rules and keep a closer eye on things.

Use iPXE with HTTPS

If you can, have ipxe use HTTPS instead of plain HTTP or tftp when it’s fetching images or scripts. HTTPS encrypts the traffic so no one can tamper with it or spy on what’s being sent. It also helps verify that the client is talking to the real server, not a fake one pretending to be it. That’s a big win against man-in-the-middle attacks.

Enable Client Authentication

You can even have ipxe ask for authentication before letting systems start provisioning. It supports options like username and password logins, tokens, or even certificates. That way, only approved systems get access to boot files. And if you’re working in a high-security place, go one step further and use mutual TLS, where both the client and server verify each other before sharing anything sensitive.

Configure Secure Boot

If your servers use uefi , you should definitely turn on Secure Boot. It checks the digital signatures of your bootloaders and kernels before running them, which helps make sure only trusted files start up. Sure, it might make setup a bit trickier—especially if you’re working with custom or unsigned kernels—but the protection it gives is absolutely worth it.

Implement DHCP Snooping

In setups that use dhcp , you can protect against fake DHCP servers by enabling DHCP snooping on your switches. It basically tells the switch to only accept DHCP offers from trusted ports. That stops attackers from setting up rogue DHCP servers that could mislead clients or point them to bad tftp or http servers.

When you put all these safeguards together, you build a pretty tough defense for network booting. Keeping things segmented, encrypted, and authenticated makes it way harder for attackers to get in. By checking every step of the boot process—from dhcp assignment all the way to bootloader execution—you can be confident that your PXE and iPXE setup is secure, trustworthy, and ready for safe automated deployments.

For a deeper dive into securing network-boot environments and how to mitigate risks in PXE/iPXE setups, check out this resource: Best Security Practices for PXE and Pre-boot OS Deployment

Common Issues and Troubleshooting Tips

When you are working with PXE and iPXE setups, it is pretty common to hit technical snags that pause or slow the boot process. Because PXE booting depends on several parts talking to each other properly, such as DHCP , TFTP , HTTP , and the device’s firmware, the best way to fix problems is to check each step of the conversation and each file transfer carefully, one by one. The list below calls out the issues people see most often and shares practical tips that can help you spot what is wrong and get it fixed quickly.

Fixing PXE related problems can feel tricky because the boot flow depends on several services that all need to line up, so the best plan is to narrow things down in steps. To find the real cause quickly, work through the issue in stages, and keep notes as you go so you do not miss anything.

Troubleshooting Workflow

• Network Layer Verification: Check if the client gets an IP address at all, and make sure DHCP broadcasts and offers are flowing both ways without getting blocked.
• File Transfer Validation: Confirm that the boot file actually downloads using TFTP , HTTP , or HTTPS , whichever your setup uses right now.
• Execution Stage: Make sure the bootloader runs as expected and that the next steps, like loading the kernel, keep going without getting stuck.

Tools that watch the network, like Wireshark, can be a huge help when you need to dig deeper. By capturing DHCP and TFTP traffic, you can see each message in order, spot dropped packets, and check that every response looks right. In more complex builds, comparing DHCP logs, general system logs, and iPXE command outputs side by side will point you straight to the failing step.

By following these step by step checks and confirming each part of the flow, admins can sort out PXE and iPXE boot problems with confidence, and that helps keep bare metal provisioning reliable and consistent across the whole environment.

For a comprehensive walkthrough on resolving network-boot issues such as dhcp failures, tftp timeouts, architecture mismatches, and VLAN mis-configuration in pxe/iPXE environments, see this detailed resource: Advanced Troubleshooting for PXE Boot Issues – Microsoft Learn

FAQ SECTION

How to install a bare metal server?

To install a bare metal server, you first set up a pxe server or an ipxe boot setup that lets you install an operating system over the network in a clean and reliable way.

This process starts when you go into the target server’s BIOS or UEFI settings and move network boot to the top so it is the first thing the machine tries. Once the system powers on, it asks for the installer across the network, usually by using DHCP to get an IP address and then using TFTP , HTTP , or HTTPS to grab the files it needs.

• Fully hands-off mode using tools like preseed , Kickstart , or cloud-init .
• Blended approach that mixes automation with a bit of manual input where it makes sense.

This setup helps admins roll out many servers quickly with the same settings, which is a big help in large environments.

What is iPXE vs PXE?

PXE , short for Preboot eXecution Environment, is the classic network boot method that relies on tftp to send boot files from a server to a client. iPXE , on the other hand, is a more capable open-source take on pxe that adds modern protocol support like HTTP , HTTPS , iSCSI , and NFS , and it also brings in scripting so you can automate steps, add simple logic, and do flexible provisioning you cannot do with plain pxe .

What is an iPXE file?

An ipxe file can be either a script or a built binary that comes from the ipxe project, and both are used during network boot. In script form, it holds the step by step instructions that tell the client where to fetch kernel images, initrd files, or boot settings from network locations. In binary form, ipxe works as a standalone or a chainloaded bootloader, which can replace or extend a standard pxe firmware on a network card, and these binaries can be built from source with extras like embedded scripts or HTTPS support.

What does PXE boot stand for?

PXE stands for Preboot eXecution Environment, and it describes a standard way to boot a computer right from its network card without needing local storage. PXE makes this happen by downloading a bootloader from a remote server, using dhcp to hand out IP addresses and tftp to move the needed boot files, which is why it is popular for big rollouts and automated installs.

What is the difference between PXE and gPXE?

gPXE came along as an improved version of the original pxe idea and grew out of an older effort named Etherboot, and it added more ways to boot over the network plus friendlier setup options. However, gPXE was later replaced by ipxe , which went even further by bringing in HTTP and HTTPS , iSCSI , and scripting, and ipxe is now the go to choice that people keep updating and improving.

What does PXE stand for in IT?

In IT terms, pxe refers to the Preboot eXecution Environment spec that was first laid out by Intel, and it standardizes how a machine boots over the network by pairing dhcp and tftp to send boot files to the client. PXE makes it possible to manage and install operating systems from a central spot, which is why it is a core tool for data center builds and large fleets.

Is iPXE a bootloader?

Yes, ipxe is a bootloader, and it can load OS kernels, initrd images, and even full disk images by using many network protocols when needed. Unlike basic pxe loaders, ipxe supports handy features like HTTP and HTTPS transfers, simple interactive menus, and custom scripts, which makes it a great fit when you want flexible, automated, and remote friendly provisioning.

What is the iPXE command line?

After it starts, ipxe offers a powerful command line that lets admins run commands for setup, testing, and provisioning in real time. Common commands include, dhcp , which asks a dhcp server for an IP address, ifstat , which shows network stats, chain , which loads another script or boot file from a URL, and boot , which starts the boot with the loaded kernel and initrd. The ipxe command line is also useful for live debugging, script trials, and on the fly control of network boot behavior, which gives teams a lot of flexibility.

What is the difference between PXE and UEFI?

PXE is the network boot method that handles downloading and running a bootloader over the network, while uefi is the modern firmware that replaces older BIOS systems and provides the environment where pxe can run. Uefi includes built in support for network boot with pxe and HTTP and adds features like Secure Boot that checks the trust of bootloaders and operating systems before they run, so you get better security, quicker starts, and nicer hardware support.

What is PXE, and how does it work?

PXE is a standard network boot setup that lets client machines load their operating system from a central server instead of local media. The flow starts when a client set for pxe boot sends a dhcp broadcast asking for an IP address, the dhcp server replies with the IP and the details about the tftp server and the bootloader filename, the client then connects to the tftp server, downloads the named bootloader, like pxelinux.0 or ipxe.efi , and runs it to kick off the OS install or recovery, which removes the need for USB drives or DVDs and suits large rollouts.

How is iPXE different from PXE?

iPXE adds a lot on top of pxe by bringing in modern network protocols like HTTP , HTTPS , iSCSI , and NFS , plus scripting and smarter automation that can react to choices and inputs. While pxe only uses tftp for file transfers, which can be limited for speed and reliability, ipxe supports faster and safer TCP based downloads, and it allows script driven choices, user prompts, and ties into cloud APIs, which makes it ideal for big, flexible setups.

What are the benefits of using iPXE scripts?

• Automation: Put complex steps into code so you do not have to click through installs by hand.
• Dynamic Boot Choices: Pick which OS or image to load based on hardware, MAC addresses, or values you set.
• Security: HTTPS and login options help lock down transfers and verify who is who before any boot work happens, which is a strong pattern for mixed and fast changing environments.

Can PXE and iPXE be used in hybrid cloud environments?

Yes, both pxe and ipxe fit well in hybrid and multi cloud builds, and they let teams roll out on premises bare metal and plug into cloud systems for quick and automated provisioning. For example, ipxe can reach HTTP endpoints that live in the cloud, which makes it simple to tie private gear to cloud based boot services while keeping control in one place.

How do I troubleshoot PXE boot issues?

When you are fixing pxe boot problems, it helps to check a few key spots in order so you do not miss anything important.

• DHCP: Make sure the dhcp server is up and set to hand out addresses and point to the right boot server.
• TFTP Logs: Check that the tftp service has the right paths and permissions to serve boot files.
• Firewall Configuration: Confirm the needed ports, usually UDP 67 , 68 , and 69 for dhcp and tftp , are open.
• UEFI vs BIOS Compatibility: Match the boot files to the client firmware, so uefi clients use EFI files and BIOS clients use legacy pxe files.

By walking through each step of the pxe boot flow in a steady way, admins can spot whether the failure is in dhcp , in tftp .

For a complete FAQ-style overview of network booting topics including pxe, ipxe, dhcp, tftp, and uefi, check out this guide: Comparing iPXE and PXE: Which Network Booting Protocol Is Right for You?

What is Network Booting

Network booting is basically when a computer or server loads its operating system and startup stuff straight from a network instead of using a local drive like a hard disk, SSD, or even a USB stick. You know, it’s like skipping the line and grabbing your files directly from the network instead of carrying them around on a flash drive. This is a big deal in modern IT setups, especially when you’re managing a lot of machines because doing manual installs on every single one would be a total time sink.

In a typical pxe or ipxe setup, the client machine starts its boot process over the network by talking to a special boot server. That server holds the operating system images, kernel files, and config data it needs to get going. Using standard protocols like dhcp (Dynamic Host Configuration Protocol) and tftp (Trivial File Transfer Protocol), the client automatically grabs these files, loads them into memory, and kicks off the operating system.

For companies running tons of bare metal servers, network booting is a lifesaver. It lets IT teams install, update, or rebuild systems remotely without touching the hardware. This really comes in handy in data centers and cloud environments where you might have thousands of systems to manage and need everything automated and consistent.

It’s also great for fixing things fast. If a system’s local disk dies or the OS gets corrupted, admins can simply reload a clean image from the network and have the server back up without lifting a finger. On top of that, it helps keep everything standardized and secure since all systems boot from one central, up-to-date image instead of random local installs.

Nowadays, network booting gets even better with modern tools like pxe and ipxe . These go beyond basic file transfers by supporting faster and smarter protocols like HTTP and HTTPS , and they let you use scripting to automate the entire boot process. So, instead of just booting, you’re basically orchestrating your deployments like a pro.

In short, network booting is the unsung hero behind automated provisioning pipelines in both data centers and cloud setups. By freeing the boot process from local storage and keeping everything centralized, it gives you scalability, control, and a smooth, efficient way to manage servers across your whole infrastructure.

For a detailed overview of how network booting works with protocols like pxe, dhcp, tftp, and uefi check out this guide The Fundamentals of Network Booting

What is PXE

PXE, short for Preboot eXecution Environment , is a neat little network boot trick that lets a computer start up straight from the network instead of depending on a hard drive, SSD, or even a USB stick. Think of it like skipping the USB shuffle and pulling what you need right off the network. PXE runs on a client-server setup, where a computer with PXE support talks to a PXE server to grab the files and settings it needs to kick off the operating system’s boot process.

Intel came up with PXE back in 1998, and it quickly became the go-to method for booting over a network in big IT setups, data centers, and even cloud systems. The main idea behind PXE is to make system installation and provisioning super easy, especially when you’re working with bare metal servers that don’t have anything pre-installed. You can basically boot and install an entire system without touching a USB stick or inserting a disk—everything happens over the network.

PXE teams up with dhcp (Dynamic Host Configuration Protocol) and tftp (Trivial File Transfer Protocol) to make the booting magic happen. When a PXE-enabled machine powers on, its network card sends out a dhcp broadcast , asking for network details and the location of the boot server. The DHCP server replies with an IP address, gateway, and info about the PXE server that’s holding the boot files. Then, the client downloads the bootloader (usually through TFTP) and runs it, which starts the OS installation or deployment over the network automatically.

The best part about PXE is how it makes rolling out operating systems a breeze. In a big data center or enterprise environment, admins can configure hundreds or even thousands of machines to boot and install OSes all at once over the network. That means less waiting around, fewer mistakes, and a ton of saved time. PXE has become a backbone for automated provisioning systems where consistency and speed are everything.

It also makes handling hardware problems or broken systems easier. Instead of reimaging a machine manually, you can just trigger a PXE boot and have it reinstall the OS or run a diagnostic utility remotely. It’s like giving your server a quick reset button over the network, which saves time and keeps everything running smoothly.

So, when you think about it, PXE really bridges the gap between manual setups and full-blown automation. By using network connections to handle the whole boot and install process, it gives you a hands-free, streamlined way to keep large-scale and high-performance environments running efficiently.

For a deeper dive into how PXE really works with DHCP, TFTP and UEFI environments, check out this guide: PXE (Preboot eXecution Environment) — OSDev Wiki

What is iPXE

iPXE is like the cool, open-source upgrade to the standard pxe (Preboot eXecution Environment) protocol. It takes what pxe does and gives it superpowers. Originally, it evolved from gPXE , which itself came out of an older project called Etherboot. The whole idea behind ipxe is to give you more flexibility, speed, and control when booting computers over a network, especially in places where you’ve got lots of machines and need fast, automated provisioning.

Traditional pxe setups only speak the basic languages of dhcp and tftp , but ipxe steps things up with support for modern protocols like HTTP, HTTPS, iSCSI, NFS, and FTP. That means faster file transfers and more reliable connections, since it doesn’t rely just on tftp ’s slower UDP-based system. With ipxe , you can boot directly from web servers, cloud storage, or local network shares, which makes deployment workflows way simpler and smoother.

If you check out the ipxe GitHub page, you’ll find the full source code, documentation, and setup examples ready to go. Since ipxe is so customizable, you can build it into different formats—like EFI (Extensible Firmware Interface) applications, old-school pxe images, or even bootable ISOs and USBs. You can also embed it directly into your network card’s ROM (Read-Only Memory), which means your system can use ipxe right from startup without needing to chainload from a separate pxe environment.

Embedding ipxe into the NIC ROM has some clear benefits. It cuts out the middle steps, removing the need to depend on other pxe servers and giving you instant access to advanced boot features as soon as your hardware powers on. This setup works great in enterprise gear or data centers where uptime and automation are everything.

Let’s talk about that NIC ROM for a second. It’s a small chip sitting on your network card that holds low-level firmware instructions and drivers. Basically, it’s what lets your computer talk to the network before the operating system even loads. In a network boot, the NIC ROM handles reaching out to the boot server and pulling down the right bootloader or OS files. When ipxe lives in that ROM, it takes over this job and does it better—with more speed, customization options, and reliability than the older pxe firmware ever could.

And here’s where it gets even more powerful. iPXE supports scripting and automation, so you can write ipxe scripts that include conditional logic, authentication, and dynamic configuration retrieval. This means you can create setups where machines boot automatically, grab the right OS, and configure themselves—perfect for zero-touch provisioning, cloud integrations, or multi-OS deployments.

In short, ipxe is the modern, flexible replacement for legacy pxe . It’s open-source, highly adaptable, and packed with features that make it ideal for system admins, DevOps teams, and anyone managing large-scale or hybrid infrastructures. Whether you’re booting bare metal or virtual machines, ipxe gives you the speed, control, and automation that modern IT environments demand.

For a detailed look into how iPXE extends PXE’s capabilities for network booting with advanced protocols and scriptin

Core Components of PXE/iPXE Boot

Both pxe and ipxe have a few key parts that work hand-in-hand to make network booting smooth and automated. Each piece plays a specific role in helping your computer talk to the network, grab the right boot files, and start loading or installing the operating system. Let’s walk through each part one by one.

Dynamic Host Configuration Protocol (DHCP)

The dhcp server is the one handing out IP addresses to computers asking to join the network. During a pxe or ipxe boot, it also gives extra info, like where to find the boot server and which boot file to download. This whole automatic setup saves you from manually assigning IPs and speeds things up a lot when you’re deploying lots of systems at once.

Boot Loader

The boot loader is the first piece of software your system loads into memory when starting up. Its main job is to get things ready for the operating system to start. In older pxe setups, you’d typically see something like pxelinux.0 from the Syslinux project. For ipxe , you might use fancier loaders like ipxe.lkrn (for kernel-based images) or undionly.kpxe (for chainloading). Once the boot loader is running, it fetches the kernel and configuration files it needs to keep the process moving.

Boot Configuration Files

These are the “recipe cards” for your boot process. They tell the system which kernel to load, which initramfs (initial RAM disk) to use, and what command-line options are needed to start up. They can also include environment settings, network details, and where to find installation media or scripts. Having these files set up right helps keep all your machines consistent, which is a big deal in data centers or automated provisioning environments.

Operating System Images / Installation Media

These are the actual files that put an operating system onto your hardware. They usually include the kernel, initrd (initial RAM disk), and whatever else is needed to start up. The OS images might live on a web server or a network storage system and get transferred during the boot. Depending on how you’ve set things up, the image might boot live, do a full install, or even handle system recovery.

PXE Server

The pxe server is basically the boss of the whole network boot operation. It coordinates everything, sends out the right configuration files, and makes sure each client gets the correct boot setup. In more advanced setups, this server might also handle tftp , HTTP , or NFS services to send out boot files and operating system images. It keeps everything centralized, which helps admins stay in control and keep things uniform.

Trivial File Transfer Protocol (TFTP)

tftp is a super lightweight file transfer system built for simple, no-fuss data transfers during the boot phase. When a pxe or ipxe boot kicks off, the client uses tftp to grab important files like the boot loader, config files, and kernel images. It doesn’t have fancy features like encryption or authentication, but it’s quick and resource-friendly, which is exactly what you need at this stage. Modern ipxe setups often mix in faster, safer options like HTTP or HTTPS for added performance.

Network Boot Program (NBP)

The Network Boot Program, or NBP, is the small executable that the client downloads and runs to get the boot sequence rolling. Once it’s downloaded—usually through tftp or HTTP —it takes charge from the firmware and starts loading the kernel or installing the OS. Common examples include pxelinux.0 for pxe and ipxe.lkrn or ipxe.efi for ipxe setups.

When all these components are configured properly and working together, managing large-scale provisioning becomes surprisingly easy. With pxe and ipxe , admins can roll out OS installs, push firmware updates, and recover systems without breaking a sweat. The whole process is fast, reliable, and repeatable, making it a core part of any serious IT automation or data center strategy.

For a complete breakdown of all the components behind PXE and iPXE booting—from dhcp and tftp to network boot programs—check out this detailed overview: The Fundamentals of Network Booting

How PXE Works

The PXE (Preboot eXecution Environment) boot process is like a team project where a few key players—the client’s firmware, a dhcp server, a tftp server, and sometimes other servers holding operating system files—all work together to boot a computer straight from the network. This setup means you don’t have to rely on local storage devices like hard drives or USB sticks. Let’s break down what happens, step by step.

Client PXE Request

When a machine set up for network booting starts up, its Network Interface Card (NIC) firmware jumps in right away. Inside that firmware, there’s something called the pxe ROM, and it takes charge early in the boot process. Its job is to reach out to the network and find a boot server.

So, it sends a dhcp DISCOVER message across the network that includes special PXE options saying, “Hey, I can do a PXE boot and I need some help finding my boot files.” Basically, it’s asking both for an IP address and for directions to where it can get the boot files it needs to start up.

DHCP Offer + PXE Information

Once that message goes out, the dhcp server (or sometimes a proxy DHCP service) replies with a DHCP OFFER. This reply includes the important stuff, like the IP address for the client, subnet mask, gateway, and DNS info, plus some PXE-specific details. Those details usually tell the client which server holds the boot files (often the tftp server) and what file to download first, called the Network Bootstrap Program (NBP).

For instance, the response might say:

IP address 11.1.1.5 assigned.
Boot file pxelinux.0 is available from boot server 11.1.1.1.

Now, the client knows how to get online and where to grab its boot file.

Client Downloads NBP via TFTP

Next, the client uses tftp , which is a lightweight and simple file transfer protocol, to download the NBP file from the server. tftp works perfectly here because it’s small and reliable—just what you need when your system hasn’t even fully booted yet.

The NBP file might be something like PXELINUX (from Syslinux), an iPXE image for more advanced setups, or a Windows Deployment Services (WDS) file in a Windows environment. At this point, the computer is still running under firmware control, not a full operating system, so keeping the process simple and stable is key.

Execute NBP

After the Network Bootstrap Program finishes downloading, the PXE firmware hands control over to it. This little program then takes the next steps: initializing hardware, grabbing more configuration files, and loading either the OS installer or the kernel itself.

If PXELINUX is the NBP, it will grab a PXELINUX configuration file using tftp . That file might set up a boot menu, list multiple operating systems to install, or even load the kernel and initrd directly. Depending on the setup, the user might see a menu to pick from—like an installer or recovery tool—or the system could just jump straight into loading a preselected operating system image.

OS Load

The final stage depends on which NBP and OS you’re using. Here, the NBP (or its second-stage loader) loads the OS kernel into memory, followed by the initrd (initial RAM disk) that contains necessary drivers and startup scripts. Once that’s done, the operating system takes over, fires up the hardware, mounts the file systems, and completes the boot process. This is the point where the PXE phase ends and your system becomes fully operational.

Overall, PXE booting is a smart and efficient way to get systems up and running over the network, especially for bare metal provisioning or mass server deployments. By working with dhcp and tftp in a well-organized sequence, PXE makes it possible to install, repair, or update operating systems remotely—no USB drives, no manual setup, and no need to even touch the machine.

For a clear step-by-step explanation of how the PXE boot process works in a modern infrastructure—including the roles of DHCP, TFTP a

How iPXE Improves on PXE

You know how pxe (Preboot eXecution Environment) is already a handy way to boot computers over a network? Well, ipxe takes that idea and gives it a serious upgrade. It turns basic network booting into something faster, smarter, and more flexible. While pxe is great for getting things started, ipxe adds new tricks like better networking protocols, automation, and scripting that make it perfect for today’s IT setups.

There are basically two main ways you can set up ipxe , depending on how much control you want and how your infrastructure is built.

Native iPXE Configuration

In this setup, you actually replace the original firmware or ROM on the computer’s Network Interface Card (NIC) with ipxe firmware. Once ipxe is built into the NIC’s ROM, it becomes part of the hardware itself, ready to go every time the system boots. This is perfect for places where network booting happens all the time and where administrators need consistent, reliable performance. The big win here is that ipxe starts automatically at every boot without depending on another boot process.

Chain-Loading iPXE

Now, if swapping firmware sounds like too much, there’s another way. With chain-loading, ipxe is loaded as a second step from your existing pxe setup. So first, the regular pxe firmware on the NIC starts the boot, and then it loads ipxe as an extension. Once ipxe is up, it takes control and gives you all the advanced options without having to mess with hardware. This method is great when you’re working in production environments where you can’t modify firmware or where different systems need to stay compatible.

Once ipxe kicks in, it brings a whole bunch of cool new features that leave regular pxe in the dust.

Expanded Protocol Support

While pxe mainly relies on the old-school tftp (Trivial File Transfer Protocol), which can be slow, ipxe works with modern protocols like HTTP , HTTPS , FTP , NFS , iSCSI , and FCoE (Fibre Channel over Ethernet). These are faster, more reliable, and even more secure. For example, HTTPS ensures your boot process is encrypted, which keeps your data safe from snooping or tampering during network transfers.

Advanced Scripting Engine

One of ipxe ’s best superpowers is its scripting engine. It lets you write scripts that automate and customize the boot process. You can make it boot differently based on the hardware, MAC address, or environment variables. You can even build menus, pull configurations on the fly, or connect to web APIs for real-time setup decisions. Basically, you can automate your whole OS deployment process and tie it right into your DevOps or cloud tools.

Embedded Boot Scripts

You can also bake scripts straight into the ipxe binary itself, which means your bootloader can run specific commands automatically, without needing extra config files. That’s super handy in big deployments where you want everything to stay consistent. You could have systems automatically download kernels, load initrd files, or start OS installs right after they power up—even if there’s no access to a network config server.

Security and Authentication

ipxe is much more security-conscious than the old pxe setup. It supports HTTPS to encrypt traffic, 802.1x authentication for identity checks, and cryptographic signatures to verify boot files. This makes it perfect for environments that need strict data security, like banks, government setups, or healthcare systems.

Direct Boot from Cloud or Remote Storage

Traditional pxe depends on tftp servers, but ipxe takes it further. It can pull operating system images or kernels directly from cloud storage, web servers, or NAS devices using HTTP , HTTPS , or iSCSI . This makes it way easier to integrate with modern automation tools and to boot physical or virtual machines across multiple locations.

Enhanced Debugging and Command Utilities

ipxe also gives you a built-in command-line interface with tools for control and troubleshooting. Commands like chain , imgfetch , and autoboot let you test things in real time. You can grab images, run scripts, and troubleshoot network problems without rebooting. It’s a huge time-saver when you’re trying to figure out why a boot isn’t working or when you need to check file access paths.

In short, ipxe isn’t just a small upgrade to pxe —it’s a complete evolution built for modern infrastructure. It gives you speed, automation, security, and flexibility all in one.

Example

Here’s a quick look at how you might use ipxe to boot a custom Linux setup:

#!ipxe
dhcp  # get network config
kernel http://192.168.1.10/boot/vmlinuz initrd=initrd.img ro console=ttyS0
initrd http://192.168.1.10/boot/initrd.img
boot

In this example, the ipxe script gets a dhcp lease to set up the network, then grabs the kernel and initrd files over HTTP from a remote server, and starts the boot. It works a lot like a pxe boot, but with HTTP instead of tftp , which makes it faster and more reliable. You can even add kernel arguments like console=ttyS0 to send console output to a serial port, which is super helpful when you’re managing headless servers or remote machines.

By combining speed, automation, and modern security, ipxe gives you a future-ready way to handle network booting and provisioning. It’s the kind of upgrade that makes life easier for anyone managing large-scale or automated IT systems.

For a deeper look at how iPXE upgrades traditional pxe with scripting, modern protocols, and uefi-ready booting check out this resource: Comparing iPXE and PXE: Which Network Booting Protocol Is Right for You?

PXE vs. iPXE – What’s the Difference?

When you look at pxe and ipxe , they both do the same basic job, which is letting you boot an operating system or installer over the network. But here’s the thing—they’re not created equal. ipxe takes the simple, reliable foundation of pxe and turns it into something far more flexible, faster, and modern. Let’s go through what makes them different, one piece at a time.

Traditional pxe is great when you just need something simple, like setting up small operating system images or running straightforward installs. It’s steady and reliable, especially in static or older environments where you don’t need much automation. But it’s limited—no scripting, no fast protocols, and no flexibility.

ipxe , on the other hand, really shines when you’re working at scale or dealing with modern infrastructure. It’s built for automation, cloud environments, and advanced provisioning. Thanks to its scripting engine, you can create intelligent boot workflows that change depending on hardware, fetch configurations on the fly, or show menus for users to pick what they want to boot.

For instance, with ipxe scripting, you can write logic that detects specific network interfaces, grabs boot files from a central server, or checks authentication before it even loads an OS image. That means it’s not just booting—it’s thinking ahead and making decisions automatically.

Because of this flexibility, ipxe fits perfectly into cloud orchestration systems, bare-metal provisioning setups, and hybrid environments where remote automation is key. It’s basically the evolution of pxe —smarter, faster, and way more customizable for today’s ever-
For a detailed breakdown of the key differences between PXE and iPXE in network-boot environments, see this comparison: Comparing iPXE and PXE: Which Network Booting Protocol Is Right for You?

Interaction with Modern Hardware and UEFI

The move from the old-school BIOS firmware to the more modern Unified Extensible Firmware Interface (UEFI) completely changed how systems handle booting and getting hardware ready. This upgrade brought a bunch of benefits—faster startups, stronger security, and better flexibility when it comes to handling boot devices. Both pxe (Preboot eXecution Environment) and ipxe play nicely with uefi , but the way they work with it is a bit different, and that’s something you really want to keep in mind when setting up network booting.

UEFI PXE Boot

Unlike older BIOS setups that rely on files like .pxe or .kpxe to kick off a network boot, uefi systems need .efi files instead. These are special executables built for uefi , letting them work directly with its networking stack. UEFI PXE booting has native support for 64-bit addressing and can handle booting over both IPv4 and IPv6, which makes it perfect for larger enterprise setups or big data centers. The use of .efi files helps make sure boot images load securely, quickly, and consistently across modern hardware setups.

Chainloading Between PXE and iPXE

Sometimes you’ll see setups that use both pxe and ipxe together in something called chainloading. Basically, pxe gets the boot process started, and then it hands things off to ipxe for the rest. Picture this: the system first boots using uefi pxe , loads a simple boot environment, and then switches over to ipxe .

This trick lets you use ipxe ’s more advanced features—like HTTPS booting, scripting, and dynamic configuration—without having to change your NIC firmware. Chainloading is super useful in mixed or hybrid setups where the hardware can’t directly run ipxe or where vendors have their own restrictions.

Native iPXE EFI Binaries

In setups that are fully uefi -based, ipxe has you covered with its own EFI-compatible binaries like ipxe.efi . These let systems boot ipxe directly under uefi without using pxe first. That means no chainloading, fewer steps, and a faster, simpler boot process.

Using the native EFI binary gives admins access to everything ipxe can do—HTTP and HTTPS support, built-in scripting, secure boot authentication—all while staying fully compatible with uefi ’s framework.

Configuration and Compatibility

When you’re setting up uefi -based pxe or ipxe booting, you need to make sure your network cards (NICs) and firmware versions actually support the boot method you’re planning to use. Older or inconsistent uefi firmware can sometimes cause compatibility problems.

Also, double-check that the BIOS or uefi settings on the machine have “Network Boot” or “PXE Boot” turned on under uefi mode. Many servers let you toggle between Legacy and UEFI booting, and getting that setting right makes a big difference.

Application in GPU-Accelerated Bare Metal Server Environments

In places like data centers where bare metal servers are used for GPU-heavy workloads—think AI, machine learning, or HPC (high-performance computing)— uefi booting really shines. Its modular design helps initialize modern GPUs more smoothly, integrates better with hardware, and supports the massive performance needs of these systems.

Organizations running GPU-based bare metal servers often rely on ipxe automation to make their provisioning super efficient. They can use ipxe scripts with HTTPS authentication to deploy prebuilt AI environments or install drivers right over the network. This makes scaling up GPU nodes much faster and way more secure.

These capabilities not only speed up deployment but also keep systems secure and stable. Caasify makes this even easier by offering flexible cloud infrastructure tailored for GPU-powered bare metal servers. Their systems make it simple to set up, manage, and scale high-performance workloads used for AI, ML, and data processing.

Understanding how uefi and ipxe work together helps administrators make the most of secure, automated, and lightning-fast network provisioning across complex environments.

For a detailed walkthrough on how modern hardware works with UEFI and network booting including pxe and ipxe integration, check out this comprehensive guide: Network Boot for UEFI Devices with iPXE

Conclusion

Mastering pxe, ipxe, dhcp, tftp, and uefi setup gives IT professionals a powerful foundation for automated OS deployment. By understanding how PXE handles network-based provisioning and how iPXE expands it with scripting, secure protocols, and UEFI compatibility, administrators can streamline bare metal installation workflows and boost operational efficiency. These technologies not only simplify infrastructure management but also lay the groundwork for scalable, cloud-ready environments. As network booting continues to evolve, future innovations in iPXE scripting, Secure Boot integration, and dynamic provisioning will further enhance the speed, security, and flexibility of automated system deployment.

Master Bare Metal Provisioning with PXE and iPXE for Network Booting (2025)