Bare Metal Provisioning with PXE and iPXE: A Step-by-Step Guide

Introduction

Physical server provisioning and maintenance are fundamental elements in modern IT infrastructure. Organizations running large-scale web services or specialized AI/ML workloads that require high performance benefit from server deployment automation to enhance operational efficiency. Network booting through PXE and enhanced iPXE boot are popular approaches in these scenarios.

This guide explains PXE and iPXE technologies, including their operational mechanism and essential role in bare metal provisioning. This article will further explain the differences between PXE and iPXE while exploring configuration and scripting aspects. We will address security concerns and provide step-by-step setup instructions for automated OS deployments. After reading this article, you will understand how to implement PXE or iPXE booting within your infrastructure.

Prerequisites

• Understanding IP addressing, DHCP, and TFTP protocols is essential to understanding PXE boot and iPXE boot operations in bare metal provisioning.
• A foundational knowledge of BIOS, UEFI boot mechanisms, and network boot protocols for remote operating system deployments should be familiar to readers.
• Understanding PXE and iPXE differences and PXE server-client interactions will provide essential insights for mastering the configuration process.
• Knowledge of bare metal dedicated servers, automated OS deployment, and their role in large-scale infrastructure management will be beneficial.
• Proficiency in iPXE commands, the Linux shell, and networking tools like Wireshark will help resolve PXE/iPXE configuration issues.

What is Network Booting

Network booting enables a computer to load its operating system and essential components from a network instead of local storage devices. Companies operating extensive server fleets, especially bare metal dedicated servers, can use network booting to deploy or reconfigure operating systems.

What is PXE

PXE stands for Preboot eXecution Environment. This network boot protocol operates in a client-server model, enabling clients to fetch their boot loaders and additional files over the network. Intel introduced PXE as an industry-standard technology in 1998**.** It allows a computer to start its boot process through the network card before accessing local storage devices where operating systems are installed. This capability benefits data centers and bare metal server environments by allowing server provisioning without manual CD or USB drive deployment.

What is iPXE

iPXE is an open-source network boot firmware solution that delivers substantial improvements beyond standard PXE capabilities. It evolved from gPXE, which originated as a fork of Etherboot. iPXE offers advanced features that are lacking in traditional PXE implementations. The iPXE GitHub repository contains its source code and documentation. Its high configurability allows developers to compile it into multiple formats, including EFI(Extensible Firmware Interface) applications and PXE images. They can also embed it within network interface card (NIC) ROMs.

Note: NIC ROM(Network Interface Card Read-Only Memory) consists of a small memory chip on the network interface card, which holds firmware that drives the card’s operation. It is an important component during the system boot process and proves especially important for network boot operations such as PXE.

Core Components of PXE/iPXE Boot

Both PXE and iPXE share some fundamental components. Let’s consider some of them:

• Dynamic Host Configuration Protocol(DHCP): The DHCP Server assigns IP addresses and indicates where to find the boot files.
• Boot Loader: The initial piece of software that the client loads when booting. It can include pxelinux.0 for PXE systems and either ipxe.lkrn or undionly.kpxe for iPXE systems.
• Boot Configuration Files: These configuration files specify the kernel and initramfs (initial RAM disk) to load along with necessary boot options and environmental variables.
• OS Images / Installation Media: These are essential files required for operating system installation on bare metal hardware.
• PXE Server: The PXE Server provides the boot configuration file to the client.
• Trivial File Transfer Protocol (TFTP): TFTP represents a minimal file transfer protocol designed for booting purposes.
• Network Boot Program (NBP): The client-side software initiates booting.

With these components established, you can manage complex provisioning processes that require minimal human interaction. Hence, it allows you to maintain efficient, reliable, bare metal dedicated server configurations.

How PXE Works

PXE booting requires synchronized collaboration between client firmware, a DHCP server, a TFTP server, and other servers for the actual OS files. Here’s the typical PXE boot workflow step-by-step:

Client PXE Request
When the network boot-configured machine powers on, its NIC firmware (PXE ROM) takes over. The NIC transmits a DHCP DISCOVER broadcast message that shows it supports PXE boot capability( this is done by embedding PXE-specific DHCP options to indicate a PXE request). The client requests network configuration services and intends to initiate PXE boot.

DHCP Offer + PXE Info
Upon receiving a request, the network DHCP server (or proxy DHCP service) replies with a DHCP OFFER message containing network details and an allocated IP address. It also includes PXE boot information: The network details include the PXE boot server name (which usually matches the TFTP server address) and bootfile identification (commonly known as NBP or Network Bootstrap Program). For example, the DHCP reply says: “IP address 11.1.1.5 is assigned with boot file pxelinux.0 from server 11.1.1.1.”

Client Downloads NBP via TFTP Once the client determines the correct boot file location, it retrieves the file using the Trivial File Transfer Protocol (TFTP) from the boot server. The NBP file may be a lightweight bootloader such as PXELINUX(from Syslinux), an iPXE image, or act as a Windows WDS(Windows Deployment Services), etc.

Execute NBP The PXE firmware hands off control to the NBP after the client downloads it into memory. The NBP progresses by loading the actual operating system or installer. If PXELINUX serves as the NBP, it will retrieve a PXELINUX configuration file through TFTP to display a boot menu or directly start loading the Linux kernel using an initrd image.

OS Load The specifics of this ultimate stage depend entirely on the nature of the Network Boot Program (NBP). The primary goal is to load the target operating system (OS) kernel into memory for execution, along with an initial RAM disk (initrd) if necessary. The PXE boot process typically requires the NBP, or a second-stage bootloader, to download the OS kernel and initrd files via TFTP. Once the operating system takes over, the network boot process is considered complete.

How iPXE Improves on PXE

iPXE enhances the basic PXE concept, providing a stronger and more user-friendly solution. There are two primary ways to use iPXE.

The native iPXE configuration involves replacing the firmware or ROM of your network interface card (NIC) with iPXE. In contrast, chain-loading iPXE utilizes the original PXE firmware to load iPXE as a secondary stage. Once iPXE begins operating on the client device, it offers several capabilities:

• Expanded Protocol Support: Besides TFTP, iPXE supports protocols like HTTP, FTP, iSCSI, FCoE, etc.
• Advanced Scripting: PXE’s scripting engine allows users to write boot scripts for complex tasks like conditional booting, menu systems, and dynamic configuration file retrieval.
• Embedded Boot Scripts: Embedding a script within the iPXE binary allows you to implement fully automated boot procedures without relying on additional configuration files.
• Security and Authentication: The combination of HTTPS support, 802.1x authentication, and cryptographic check allows for secure boot operations in high-security environments.
• Direct Boot from Cloud Storage: iPXE enables kernel loading or OS image from remote resources through various communication protocols.
• Enhanced Debugging and Commands: Built-in commands (like chain, imgfetch, autoboot, etc.) enable advanced control over the booting process.

In short, iPXE is a modern, more powerful replacement for PXE when you need advanced network boot options.

Example: To boot a custom Linux environment, you can utilize iPXE.

It allows the creation of a script as shown below:

#!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

The script instructs iPXE to get a DHCP address and download kernel and initramfs files through HTTP from a server before initiating the boot process. The process works like PXE boot but uses HTTP instead with enhanced control capabilities and allows easy inclusion of kernel command line arguments such as *console=ttyS0 (*The console output directs to the serial port.ttyS0)

PXE vs. iPXE – What’s the Difference?

While PXE and iPXE serve similar goals (network-based booting), there are significant differences in features and capabilities. Below is a comparison:

PXE works well for straightforward PXE boot processes involving small images. iPXE stands out for large-scale deployment or cloud integration needs and users dependent on advanced scripting features.
Using iPXE scripting**,** you can automate boot decisions by integrating scripts to detect hardware types**,** select the correct OS installer**,** or display boot menus.

Interaction with Modern Hardware and UEFI

The transition from traditional BIOS to UEFI enhances security and modular design. While both PXE (Preboot Execution Environment) and iPXE are compatible with UEFI, there are a few key differences to consider:

• UEFI PXE Boot: Unlike legacy BIOS**,** which uses .pxe or .kpxe files for network booting**,** UEFI requires a .efi application.
• Chainloading: Some configurations enable PXE boot through UEFI and then proceed to chainload iPXE for extended functionality.
• Native iPXE EFI Binaries: Users can boot iPXE directly in UEFI environments because it provides UEFI-compatible binaries such as ipxe.efi, eliminating the need for chain loading.

It is essential to check that hardware systems support UEFI PXE or iPXE boot. In GPU-accelerated bare metal server environments, running specialized AI/ML workloads and optimized booting solutions enhances provisioning efficiency. Organizations that allocate investments to bare metal hardware for GPU-intensive tasks must prioritize UEFI support to access all modern server motherboard features.

DigitalOcean provides a quick start guide for organizations that want to provision bare metal GPUs. Explore what Bare Metal GPUs are to discover products featuring bare metal GPUs, learn about bare metal GPU offerings, and gain further GPU-related insights.

Setting Up PXE and iPXE for Bare Metal Servers

Now that we understand how PXE and iPXE work, it’s time to configure the PXE/iPXE environment for bare metal provisioning. We will configure a PXE server followed by iPXE integration for advanced network booting.

Prerequisites to set up PXE/iPXE environment

• To set up a PXE/iPXE environment, start with a solid network infrastructure. Keep all your servers on the same LAN, or set up a DHCP relay if you’re booting across different subnets. Using VLANs can help with security.
• Check that bare metal servers can handle PXE in the BIOS/UEFI settings and that network booting is enabled.
• Configure a DHCP server to assign IP addresses and point to the boot file location, while a TFTP server will transfer those boot files.
• For iPXE, an HTTP server will efficiently serve scripts and OS images.
• Gather the necessary boot files, such as pxelinux.0, bootx64.efi, and ipxe.efi, along with your OS installation images.
• To keep things running smoothly, use a dedicated PXE server machine with a static IP to host the DHCP, TFTP, and HTTP services for network booting.

Best practice: Document your network environment (like IP ranges and server IPs). Using a test machine to experiment with the PXE setup before deploying it to the production servers is also a good idea.

Setting Up a PXE Server

Setting up a PXE server involves two key players:

• DHCP responds to boot requests with the necessary network details and specifies the boot file.
• TFTP is responsible for sending that boot file to the client.

Here’s a straightforward guide on how to get these pieces in place:

Install and Configure DHCP with PXE Options

Install a DHCP Server If you don’t have a DHCP service configured for PXE, it’s time to install one. For instance, if you’re using a Debian or Ubuntu Linux server, you can go ahead and install the ISC DHCP server:

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

On Red Hat-based systems, dhcp-server can be installed via dnf or yum. Ensure the DHCP service is enabled and will start on boot.

Basic DHCP Configuration: Start by editing the configuration file—e.g., /etc/DHCP/dhcpd.conf for ISC DHCP. You must define the network’s subnet, the IP range, the gateway, DNS settings, and anything specific to your configuration. To support booting via Bootstrap Protocol (BOOTP) or PXE, check if the DHCP server requires lines like allow booting; allow bootp; to be added. For 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;
    ...
}

Configure PXE-specific Options
In the DHCP configuration for your subnet, include the PXE boot file and the TFTP server.

• Option 66 (Next-Server): The TFTP server’s IP address is specified here. It is often the same as the PXE server. With ISC DHCP, you can do this using next-server 192.168.1.10 (Just replace it with your TFTP server’s IP).
• Option 67 (Boot File Name): Here, you’ll provide the file name the client will download from the TFTP server. For PXELINUX clients using BIOS, you might use pxelinux.0. For UEFI clients, it could be an EFI loader (such as bootx64.efi for x86_64 UEFI). In your ISC DHCP config. Use the filename pxelinux.0; it is defined within the subnet or host group.

If you have clients using BIOS and UEFI, the best thing to do is to differentiate them based on the DHCP architecture type. For instance, you might implement conditional statements for this purpose.

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

This ensures that each client gets the correct bootloader. (For architecture codes, 00:07 refers to x64 UEFI, 00:06 is for x86 UEFI, and 00:00 or 00:09 indicates BIOS, etc.)

Start the DHCP Service After saving the configuration, go ahead and start the DHCP service. For example, you can use sudo systemctl to start isc-dhcp-server. Then, check the system logs (like /var/log/syslog or /var/log/messages) to confirm it started smoothly without errors.

Install and Configure the TFTP Server

Install TFTP Service You’ll want to install a TFTP service on the PXE server (or whatever you’ve set up as a TFTP server). If using Ubuntu or Debian, just run this command:

sudo apt install tftpd-hpa

If you’re on RHEL or CentOS, try this instead:

sudo dnf install tftp-server

Ensure the TFTP service (or xinetd if using xinetd) is enabled. Modify your firewall settings to allow TFTP traffic through (UDP port 69, just in case!).

TFTP Root Directory Now, you must identify the TFTP root directory.

Depending on the system configuration, you’ll usually find the TFTP root directory at /var/lib/tftpboot or /tftpboot. You can easily create it if it’s missing by running the command:

sudo mkdir -p /var/lib/tftpboot.

Just remember to set the correct permissions so everyone can read it. TFTP clients need to access the files without specific user accounts. You can handle the permissions using the command:

sudo chmod -R 755 /var/lib/tftpboot.

This way, the TFTP server, which often operates as the user nobody, will have access to the directory.

Obtain PXE Boot Files Next, copy the bootloader files into the TFTP root. If you’re working with PXELINUX from the Syslinux project, you’ll need a few essentials:

• pxelinux.0 – this is the primary PXE bootloader for BIOS clients.
• Other important files include ldlinux.c32, libcom32.c32, libutil.c32, and several menu modules such as menu.c32 or vesamenu.c32 if you prefer a menu interface. These files typically come with the Syslinux package. When you install the syslinux or syslinux-common package on most Linux distributions, these files are usually located in the /usr/lib/PXELINUX/ directory. Simply copy them to the tftpboot directory. If you’re using Red Hat, you can extract them directly from the Syslinux RPM.
• If you need a UEFI bootloader, get syslinux.efi or an iPXE EFI binary, especially if you plan to use iPXE for UEFI from the beginning.
• Optionally, other tools like undionly.kpxe (a BIOS binary for chainloading) or wimboot for Windows PE booting. This will depend on the use case.

Set Up PXELINUX Configuration:

PXELINUX looks for a configuration in the pxelinux.cfg directory under the TFTP root. let’s create that directory:

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

Next, create a default config file, like this: /var/lib/tftpboot/pxelinux.cfg/default. In this file, you’ll lay out the PXE boot menu or any necessary settings. For example:

DEFAULT menu.c32
PROMPT 0
TIMEOUT 600
MENU TITLE PXE Boot Menu

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/

LABEL memtest
  MENU LABEL Run Memtest86+
  KERNEL images/memtest86+-5.31.bin

LABEL local
  MENU LABEL Boot from local disk
  LOCALBOOT 0

The PXE boot menu setup to boot from the network with multiple options using Syslinux (menu.c32). You’ll have a 600-second countdown before it automatically selects the default choice. The menu features three options:

• Installing Linux, which will load the kernel (vmlinuz) and the initial RAM disk (initrd.img) while downloading installation files from an HTTP repository (inst.repo).
• Memtest86+ for checking memory using memtest86±5.31.bin.
• Booting from the local disk (LOCALBOOT 0) exits PXE and launches the operating system already installed on your machine.

Make sure to adjust the paths according to your environment (for instance, you might store the kernel and initrd in the images folder under tftpboot while keeping an HTTP repo for the OS files). The KERNEL line points to the network boot kernel. Additionally, the APPEND line contains the initrd and any necessary kernel parameters, such as the location for the installer or the Kickstart file.

Note: The paths for KERNEL and INITRD (using APPEND) are based on TFTP root unless you’ve specified a different protocol like http://. Just ensure those files are in the TFTP directory or accessible as indicated. For example, images/linux/vmlinuz, actually point to /var/lib/tftpboot/images/linux/vmlinuz on the server.

NFS or HTTP Setup for OS Files (if required) If your OS installer requires a repository—like a complete distro tree or an ISO, you should serve it through NFS or HTTP. For example, you can mount an ISO and share it over HTTP, allowing the installer to access and retrieve the necessary packages.

Start/Restart TFTP Service Once you’ve uploaded files, restart the TFTP service to ensure it recognizes the new files. For instance, you can run:

sudo systemctl restart tftpd-hpa

Typically, TFTP does not require a restart for new files since it retrieves them directly from the disk with each request. However, it is wise to confirm that the service is operational.

At this point, you have a basic PXE server configuration. When a client starts using PXE, the DHCP server will hand out an IP address and specify the boot file (like pxelinux.0). The client will fetch this file from the TFTP server and load the PXELINUX bootloader. From there, it will read the configuration, show the menu options, and proceed with the OS installation.

Installing and Configuring iPXE

We’ll examine chain loading iPXE via PXE, which works well with the setup we discussed earlier.

Download or Compile iPXE

You can get iPXE binaries through these methods**:**

• Precompiled Binaries: For quick experimentation, the iPXE project offers a pre-built ISO image that can be easily accessed. Additionally, binaries like undionly.kpxe and ipxe.efi can be built from the source code.
• Compile from Source: To get the latest features or adhere to the customization process(like embedding scripts or enabling HTTPS), compile iPXE from the source. First, you’ll need to install some build tools (like make, gcc, Perl, etc.).

For example, on a Debian/Ubuntu system:

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

After a successful build, you’ll find the binaries in the bin/ or bin-x86_64-efi/ directories. If you want to include a startup script in the binary, add EMBED=script.ipxe to your make command.

Configure DHCP for Chainloading iPXE

Now, to use iPXE during the boot process, you’ll configure the DHCP settings as explained in the section above:

• BIOS clients will first download undionly.kpxe (that’s the iPXE firmware for BIOS) through TFTP instead of jumping straight to PXELINUX. For UEFI clients, they can directly load ipxe.efi.
• Update the DHCP filename and related options:
  • For BIOS, set the filename to “undionly.kpxe” (ensure the next server still directs to the TFTP server hosting this file).
  • For UEFI, set the filename to “ipxe.efi”; for x86_64 UEFI (you can change the architecture according to your need).

Avoiding Loops One of the challenges is to avoid getting stuck in a loop where iPXE keeps loading itself repeatedly. When iPXE initiates, it sends its own DHCP request. Suppose the DHCP server responds with undionly.kpxe or ipxe.efi, you’ll be trapped in a never-ending cycle.

Configure the DHCP server to recognize an iPXE client to break this loop.

By default, iPXE uses the user-class identifier “iPXE.” If you’re using ISC DHCP, use this to differentiate the second-stage requests. For example:

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

In the above piece, we’re dealing with a client called “iPXE.” Instead of getting another boot file through TFTP, it will be sent straight to an HTTP URL, specifically **, a custom iPXE script you’ll set up. Clients that haven’t switched to iPXE yet (the initial BIOS PXE boot) will receive the undionly.kpxe for chain loading. If you’re working with UEFI, follow a similar method: serve ipxe.efi and configure it to load the script via HTTP.

Make sure to update the DHCP settings and restart the service. Don’t forget to place the new undionly.kpxe and ipxe.efi files into the TFTP root folder. The process now goes like this:

• BIOS client initiates PXE boot.
• It downloads undionly.kpxe from TFTP.
• iPXE takes it from here.
• A second DHCP request that supplies the ** URL is made by iPXE.
• iPXE performs an HTTP GET on that URL to fetch the boot script.

Set Up an HTTP Server for iPXE

Now that we’re getting iPXE to fetch a boot script (and maybe some other files) over HTTP let’s configure an HTTP server:

Install HTTP Server
You can do this on the PXE server or any other machine, but we’ll stick with the PXE server for simplicity. Install a web server like Apache or Nginx. For instance, when using Ubuntu, you can run:

sudo apt install apache2

Ensure the server is running and reachable from your target network. If necessary, open port 80 in the firewall.

Create iPXE Script File This will be the file you reference in the DHCP configuration. Create a file, such as /var/www/html/, where you’ll write the iPXE commands. At a minimum, this file can chain to another script or load an OS installer directly. A basic configuration might prompt iPXE to display a menu or start an installer.

#!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

This example (not interactive) tells iPXE to download a kernel and initrd over HTTP and boot them.

Host OS Installation Files (if needed) Before proceeding, ensure that iPXE can access the necessary OS installation files, such as the kernel, initrd, or the complete ISO repository. iPXE can retrieve both the kernel and initrd files. These essential files should be in the main directory or the web server’s subdirectory.
For example, copy your Linux distribution installer files vmlinuz and initrd.img to the directory /var/www/html/os_install/. iPXE can retrieve large files such as Windows PE images or Linux ISOs through HTTP to load them into memory or pass them to the bootloader.

Test HTTP Access
Run a retrieval test for the ** file from another machine or by using the curl command. This helps verify that the web server is functioning correctly.

Creating iPXE Boot Scripts

The scripting capability stands out as one of iPXE’s most powerful features. The iPXE scripting process involves writing a text file that contains a sequence of iPXE commands that begins with the shebang line #!ipxe Using scripts, you can create menus, automate operating system selection, and pass kernel parameters to completely automate deployment processes.

Basics of iPXE Scripting
The following commands can be implemented within an iPXE script:

• kernel – Select a kernel or boot loader that should be downloaded and executed.
• initrd – It allows you to define the initial ramdisk for download purposes.
• boot – Use it to launch the loaded kernel using the specified initrd.
• chain – It allows a script to transfer boot control to another script or bootloader.
• Flow control commands such as goto, ifopen, and menu-related commands line menu, item, and choose to enable the creation of interactive decisions.

An embedded iPXE script can use the chain command to load boot.ipxe by specifying the appropriate server URL.

Example: Interactive Boot Menu Script Create a script file such as menu.ipxe on your web server or directly embed it into iPXE. For example:

#!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

: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
:memtest
kernel http://192.168.1.10/boot/memtest86+
boot
:cancel
echo Boot canceled or timed out. Rebooting...
reboot

The iPXE script builds a boot menu that allows users to start an Ubuntu installation or perform diagnostics using Memtest.
The script configures console resolution while displaying options that enable the user to initiate Ubuntu installation by pressing “u” and start Memtest by pressing “m.”

The system will cancel the process and restart if the user does not make a selection within 5 seconds. The Ubuntu boot option initiates kernel and initrd loading through HTTP, enabling automated installation through cloud-init using nocloud-net. The Memtest option loads a tool for memory testing from the same server. This entire networking operation runs remotely without physical interaction with the machine. This is the essence of bare metal provisioning.

Security Implications of Network Booting and Mitigations

Improper configuration of network booting can create potential security vulnerabilities. Attackers might fake DHCP or TFTP server identities to send harmful images to clients. Here are some best practices:

• Use Separate VLANs: Ensure your production network remains isolated from your provisioning network.
• Use iPXE with HTTPS: iPXE enables network booting from servers that use HTTPS to maintain traffic encryption.
• Enable Client Authentication: iPXE scripts allow integration with security protocols such as username/password authentication or certificate-based validation.
• Configure Secure Boot: Enable secure boot on systems using UEFI firmware. It creates additional challenges but blocks unauthorized boot loaders from running.
• DHCP Snooping: In some environments, network switches that implement DHCP snooping can block unauthorized DHCP servers from distributing addresses and harmful boot instructions.

Common Issues and Troubleshooting Tips

When using PXE/iPXE, you will experience typical issues. The table below displays issues and tips to troubleshoot them:

Troubleshooting PXE is complex because it relies on several interconnected systems, including the client, DHCP server, and TFTP server. You can usually isolate the issue by checking each stage (Did I get an IP? Did I download the file? Did it execute?).
Microsoft’s documentation on debugging PXE issues and tools such as Wireshark for capturing DHCP/TFTP exchanges prove useful for advanced troubleshooting.

FAQ SECTION

How to install a bare metal server?
You need to set up a PXE server or iPXE boot environment and set the server’s BIOS or UEFI to network boot while pulling the operating system installer from network resources. The operating system installation continues with either full automation or a combination of manual and automatic approaches.

What is iPXE vs PXE?
PXE is the traditional network booting standard PXE that operates under the TFTP protocol. As an enhanced open-source network boot solution, iPXE supports modern protocols such as HTTP/HTTPS, iSCSI, and scripting capabilities.

What is an iPXE file?
The iPXE file is a script or the compiled boot loader binary from the iPXE GitHub repository. The script represents a set of instructions for fetching and booting images from the network. In binary form, iPXE usually functions as either a standalone or chainloadable version of iPXE.

What does PXE boot stand for?
Preboot eXecution Environment (PXE) represents a booting technique that allows computers to boot through their network interface without depending on local storage or installed operating systems.

What is the difference between PXE and gPXE?
gPXE emerged from Etherboot to enhance PXE through additional network boot protocols. iPXE is a further evolution of gPXE. It has replaced gPXE while maintaining ongoing development work.

What does PXE stand for in IT?
The acronym PXE in IT refers to the Preboot eXecution Environment specification created by Intel to enable network-based booting.

Is iPXE a bootloader?
iPXE operates as a bootloader. It can load kernels*, initrds*, and disk images through multiple network protocols.

What is the iPXE command line?
Once iPXE is launched, it gives you access to a command line interface, enabling you to execute commands such as dhcp, ifstat, chain, boot, etc. The interface delivers extensive capabilities for real-time debugging purposes and advanced provisioning tasks.

What is the difference between PXE and UEFI?
PXE represents a network booting protocol, and UEFI stands for Universal Extensible Firmware Interface, which serves as modern firmware replacing legacy BIOS. UEFI incorporates built-in network stack capabilities to support network boots through PXE and HTTP protocols.

What is PXE, and how does it work?
PXE is a network boot protocol that enables clients to load their operating system from a server using DHCP to assign IP addresses and TFTP to download the bootloader. The boot process begins with a DHCP broadcast, which guides the request to a TFTP server, which then downloads the boot loader to proceed with OS installation or loading.

How is iPXE different from PXE?
iPXE extends PXE capabilities by supporting new protocols (HTTP, HTTPS, iSCSI, etc.), a scripting engine, and better performance.

What are the benefits of using iPXE scripts?

• Automation: Complex logic can be implemented to reduce the need for manual intervention.
• Dynamic Boot Choices: The system can automatically select which OS images to load based on the detected hardware specifications, MAC address information, or user input.
• Security: Use HTTPS integration to ensure secure downloads of images and authenticate users.

Can PXE and iPXE be used in hybrid cloud environments? PXE and iPXE technologies are utilized in hybrid cloud and multi-cloud environments. Organizations commonly use them to quickly deploy on-premise bare metal servers and manage cloud-based auto-scaling groups that address temporary workload spikes.

How do I troubleshoot PXE boot issues?

• Check DHCP: The DHCP server should be operational and properly assigning IP addresses.
• Review TFTP Logs: TFTP requires careful configuration as it needs accurate file paths and appropriate permissions to operate correctly.
• Firewall Configuration: Ensure necessary TFTP and DHCP ports remain open.
• UEFI vs BIOS: Before proceeding, check that the boot files correspond to the firmware type.

Conclusion

Network booting is fundamental to modern IT systems, especially when provisioning bare metal servers and deploying dedicated infrastructure. Using PXE and iPXE boot, organizations can achieve automated operating system deployments, optimize server provisioning, and efficiently manage their infrastructures.

Network booting for bare metal servers requires IT professionals to understand the differences between PXE and iPXE, PXE server configuration, and automated OS deployment implementation. This guide details setup procedures and security implications while providing troubleshooting methods to help organizations implement scalable and secure network boot solutions. Through proper PXE/iPXE configuration, businesses can achieve efficient bare metal provisioning while improving their IT operational performance.

References and Resources

• Preparing a PXE installation source
• PXE Booting and Kickstart Technology
• Network-Based Deployment Using Preboot Execution Environment
• Understand PXE boot in Configuration Manager
• iPXE - open-source boot firmware
• iPXE - open-source boot firmware
• What are the most significant security concerns on PXE?
• Security and privacy for OS deployment in Configuration Manager
• Attacks Against Windows PXE Boot Images