iPXE
iPXE is an open-source network boot firmware that implements the Preboot Execution Environment (PXE) standard, enabling computers to load operating systems and bootloaders directly from a network server without requiring local storage media.[1] It serves as a client for PXE, the industry-standard protocol for network booting defined by Intel, but extends beyond basic PXE capabilities to support advanced networking protocols and automation.[2] Developed as the official successor to gPXE, iPXE originated in 2010 as a fork of the gPXE project, which itself evolved from the earlier Etherboot initiative aimed at open-source PXE implementations.[3] The project is maintained by a community of developers under the GNU General Public License (GPL) version 2 or later, with some components using compatible licenses, ensuring broad accessibility and integration into various hardware and software ecosystems, and remains actively maintained with recent updates as of 2025.[1][4] Its development emphasizes reliability, as evidenced by automated build testing via GitHub Actions and static analysis through Coverity Scan.[5] Key features of iPXE include support for booting over diverse protocols such as HTTP, iSCSI, Fibre Channel over Ethernet (FCoE), and InfiniBand, in addition to traditional TFTP used in standard PXE.[1] It offers a powerful scripting language for automating boot processes, native menu systems for user interaction, and options for chainloading other bootloaders or embedding directly into ROM firmware on network interface cards.[1] These enhancements make iPXE particularly valuable in enterprise environments for bare-metal provisioning, as seen in deployments with Red Hat Satellite for reducing provisioning times through HTTP-based image transfers and in OpenStack Ironic for cloud infrastructure orchestration.[2][6] Widely adopted, iPXE is bundled in products from network card manufacturers and used in virtualized setups like QEMU and VMware.[1]Introduction
Overview
iPXE is an open-source implementation of network boot firmware and a bootloader that extends the Preboot Execution Environment (PXE) standard, providing enhanced capabilities for booting systems over a network.[1][7] It serves as a versatile tool for initializing hardware and loading operating systems or other boot images directly from remote servers, bypassing the need for local storage media.[1] The primary use cases of iPXE include enabling network booting of operating systems in enterprise settings, such as server provisioning in data centers, where it facilitates rapid deployment across large-scale environments.[8] It also supports diagnostics by allowing the loading of troubleshooting tools over the network and automation in cloud provisioning workflows, such as those used in virtual machine orchestration on platforms like Amazon EC2.[9][2] Compared to standard PXE, iPXE offers key advantages including support for modern network protocols beyond traditional TFTP, such as HTTP and iSCSI, which enable faster and more flexible boot processes.[1] It also incorporates scripting for customized boot behaviors and the ability to chainload other bootloaders, allowing seamless integration with diverse systems.[1] In terms of basic architecture, iPXE operates as firmware within BIOS or UEFI environments, where it initializes network hardware, performs DHCP discovery, and retrieves boot images from specified servers.[1][7]History and Development
iPXE traces its roots to the Etherboot project, an open-source initiative started in 1995 to enable network booting on x86 systems, but its modern form emerged from the gPXE rewrite initiated in 2005 by Marty Connor and Michael Brown to provide a more robust, PXE-compliant alternative with modular design and enhanced protocol support.[10] In 2007, Michael Brown led significant rewrites to gPXE, addressing limitations in the original Etherboot codebase, such as improving driver modularity and adding advanced features like SAN booting capabilities. This evolution addressed the need for a flexible, open-source bootloader in environments constrained by proprietary PXE implementations from vendors, particularly in large-scale deployments like cloud infrastructure and high-performance computing (HPC) clusters where scriptable and multi-protocol booting is essential. The transition to iPXE occurred in April 2010 when Michael Brown forked and renamed gPXE to iPXE, marking a deliberate shift to accelerate development on scripting, HTTP support, and other extensions while maintaining backward compatibility.[11] HTTP booting, which allows faster and more reliable image transfers over modern networks compared to traditional TFTP, was integrated into gPXE around 2009 and carried forward into iPXE, alongside initial scripting capabilities enhanced through community efforts like Google Summer of Code projects.[12] These features provided a scriptable alternative to rigid vendor PXE stacks, enabling automated provisioning in dynamic settings such as OpenStack's Ironic service for bare-metal management and HPC node orchestration.[13] gPXE version 1.0.0 was released on February 3, 2010, introducing a stable API and solidifying its foundation for ongoing enhancements that continued into iPXE.[14] The project moved to GitHub in 2010, fostering community-driven contributions focused on expanding protocol support (e.g., iSCSI, FCoE), hardware compatibility, and integration with emerging standards.[4] As of November 2025, development continues actively, with updates emphasizing UEFI compatibility for modern firmware environments and security fixes, such as improved handling of network protocols to mitigate vulnerabilities in boot processes.[15] This sustained evolution has positioned iPXE as a key tool in scalable computing infrastructures, supported by a global community of developers contributing to its repository.[16]Core Implementation
PXE Client Firmware
iPXE serves as an enhanced PXE 2.1-compliant client firmware, providing a complete implementation of the Preboot Execution Environment (PXE) protocol stack while introducing extensions for improved reliability and functionality.[1] At its core, iPXE initializes the network interface card (NIC) using the Universal Network Device Interface (UNDI) driver, which allows it to interface with a wide range of Ethernet hardware without requiring vendor-specific code during the initial boot phase.[17] Once the NIC is active, iPXE performs DHCP discovery to obtain an IP address and boot server information, followed by the download of the Network Bootstrap Program (NBP) via TFTP, adhering strictly to PXE 2.1 specifications for compatibility with existing infrastructure.[18] These steps enable seamless integration into standard network boot environments, where iPXE acts as the initial client firmware to locate and load subsequent bootloaders or operating system images. As firmware, iPXE is designed for direct embedding into system ROMs, such as option ROMs on network cards, or deployment via USB devices for portable booting solutions.[19] It supports loading in both legacy BIOS and modern UEFI environments, with build targets like bin-i386-pcbios.rom for BIOS ROM integration and bin-x86_64-efi.efirom for UEFI-compatible ROMs, allowing it to replace or supplement vendor-provided PXE ROMs.[20] Additionally, iPXE includes native support for iSCSI, enabling direct booting from storage area networks (SANs) by treating remote block devices as local disks during the firmware execution phase.[1] In contrast to standard PXE implementations, which are limited to basic TFTP-based transfers and lack robustness in unreliable networks, iPXE incorporates advanced error recovery mechanisms, such as automatic retries and packet reassembly, to handle transient network failures without user intervention.[21][22] It also provides multi-protocol fallback capabilities, allowing seamless transitions from TFTP to alternatives like HTTP if the primary method fails, and integrates DNS resolution directly within the firmware to resolve hostnames for boot resources without relying on external proxies.[21] iPXE's hardware compatibility extends to most Ethernet controllers through its built-in driver suite or by leveraging external drivers, ensuring broad support across PCI, PCIe, and virtualized environments.[23] For UEFI systems, it utilizes the Simple Network Protocol (SNP) to interface with the platform's network stack, providing a standardized abstraction layer that simplifies integration with UEFI-compliant hardware.[24] Unique to its firmware-level operation, iPXE includes security features tailored for trusted boot environments, such as Option ROM signing using digital certificates to verify the integrity of embedded images against tampering.[25] In UEFI mode, it supports secure boot chains by generating signed PE/COFF executables that can be enrolled in the platform's key database, ensuring that only authorized firmware components execute during the boot process.[26]Network Boot Mechanism
The network boot mechanism in iPXE extends the standard Preboot Execution Environment (PXE) process by providing enhanced scripting and protocol support, enabling more flexible and robust booting over the network. Upon system power-on, the firmware loads the iPXE binary, typically as a PXE client embedded in the network interface card (NIC) or chainloaded from an initial bootloader. iPXE then initializes the network interface and broadcasts a DHCP DISCOVER packet to obtain an IP address, subnet mask, gateway, and details of the boot server. The DHCP server responds with an OFFER containing the IP configuration and specifies the boot server address (via DHCP option 66) and boot file name (via option 67, such as "undionly.kpxe" for BIOS or "ipxe.efi" for UEFI). iPXE downloads the specified boot file—often an iPXE script or image—via TFTP, executes it, and proceeds to load the operating system kernel or further chainload components.[27][28] Chainloading allows iPXE to serve as a secondary bootloader, loading additional firmware or images without replacing the primary PXE ROM. For instance, after initial PXE loads iPXE via TFTP, iPXE can chainload bootloaders like GRUB or Windows PE by issuing commands such aschain tftp://[server](/page/Server)/boot/[grub](/page/Chain).core or chain http://[server](/page/Server)/winpe.wim, transferring control to the secondary loader while maintaining network connectivity. This mechanism supports seamless transitions to diverse boot environments, including multiboot configurations.[27]
iPXE incorporates fallback mechanisms to handle boot failures gracefully, including built-in retry logic for network operations and dual-stack IPv4/IPv6 support. If a DHCP request or file download fails, iPXE retries the operation a configurable number of times (defaulting to four attempts for DHCP) before falling back to alternatives like local disk boot via the exit command or rebooting the system. IPv6 support enables PXE booting over IPv6 networks, with iPXE attempting both protocols in dual-stack environments to ensure compatibility across modern infrastructures. Scripts can implement custom fallbacks, such as prompting for manual input after timeouts or redirecting to a secondary server.[30][31][32][21]
Integration with DHCP options enhances iPXE's boot process by allowing dynamic configuration without embedded scripts. iPXE parses standard PXE options like 66 (boot server host name) and 67 (boot file name), as well as vendor-specific options (e.g., option 43 for encapsulated PXE menus or custom parameters). In proxyDHCP setups, where a separate server provides PXE options without altering IP assignments, iPXE listens on UDP port 4011 for proxy responses, enabling deployment in environments with existing DHCP infrastructure. This allows fine-grained control, such as architecture-specific boot files using option 93.[33][28][34]
Common troubleshooting issues in iPXE network booting include network timeouts, VLAN tagging mismatches, and proxyDHCP conflicts. Timeouts during TFTP downloads can be mitigated by switching to HTTP for faster transfers or adjusting script timeouts (e.g., #!ipxe timeout 5000 for 5-second menu waits), as TFTP is prone to packet loss on congested networks. For VLAN-tagged environments, iPXE supports 802.1Q tagging via the vcreate command (e.g., vcreate --tag 100 net0), but mismatches between NIC BIOS settings and server VLANs often cause discovery failures; verifying trunk port configurations and using Wireshark for packet captures resolves most cases. ProxyDHCP usage requires careful avoidance of loops, achieved by configuring the proxy to respond only to PXE requests and redirecting iPXE to non-TFTP protocols post-load.[35][33][28]
Features and Capabilities
Boot Management
iPXE functions as an interactive boot manager once loaded over the network, presenting users with options to select and boot various operating systems or images. The interactive menu system is built using themenu command to create a titled menu, followed by item commands to define selectable options, and the choose command to handle user input via keyboard navigation and selection.[36][37] These menus can be populated dynamically from DHCP-provided filenames, such as a menu.ipxe script, or embedded directly into the iPXE binary, enabling flexible boot option displays without additional network fetches.[27]
Hotkey support enhances usability by allowing quick access to management functions during the boot process. Pressing Ctrl-B interrupts the automatic boot sequence to drop into the iPXE command shell for manual intervention, while embedded scripts can define custom hotkeys, such as Ctrl-R to trigger a reboot command.[38] This feature ensures users can override defaults or troubleshoot interactively without restarting the firmware load.
For multi-image support, iPXE enables chainloading, where the chain command downloads and executes another boot image, such as an OS kernel or ISO, directly from a URI without reloading the underlying firmware. This allows seamless transitions between multiple boot targets, like chaining from a diagnostic tool to a full OS installer, maintaining network connectivity throughout.[27]
Embedded images address scenarios with limited or unreliable network access by pre-compiling boot files, scripts, or even full images into the iPXE binary during build time using the EMBED option in the makefile.[39] For instance, compiling with make bin/ipxe.efi EMBED=bootscript.ipxe integrates the script, making it available offline for air-gapped environments or slow connections.[27]
Customization options allow tailoring the boot experience for specific environments. Menus support styling via the colour command to set foreground and background colors, while the choose command includes --timeout and --retimeout parameters to enforce selection deadlines in milliseconds, defaulting to indefinite if set to zero.[37] For security, the login command can precede menu presentation to require username and password authentication, protecting access in shared or sensitive deployments.
Scripting and Configuration
iPXE features an embedded scripting language that enables automation of boot processes through plain text files containing sequences of commands. Scripts begin with the shebang line#!ipxe, which identifies the file as an iPXE script and supports legacy compatibility with #!gpxe. This allows for declarative configuration of network booting behaviors, such as downloading and executing images from remote servers. Key commands include chain <url>, which downloads and boots an executable image from a specified URL, such as chain http://boot.ipxe.org/demo/boot.img; imgfetch <url>, used to download files like kernels or initrds without immediately booting them, for example imgfetch http://example.com/[kernel](/page/Kernel); and sanboot <url>, which initiates a boot from a SAN device, particularly iSCSI targets, as in sanboot iscsi:192.168.0.20::::iqn.2010-04.org.ipxe:winxp.[21]
Configuration files, often named menu.ipxe, define dynamic boot menus and can be embedded directly into iPXE binaries like bin/iPXE.efi during compilation or downloaded dynamically over the network. For instance, a script might be fetched via chain http://192.168.0.1/boot.php?mac=${net0/mac}, allowing server-side generation of customized menus based on client hardware details. These files support menu creation with commands like [menu](/page/Menu) to start a new menu, item to add selectable options (e.g., item --key x [Boot](/page/Boot) Linux), and choose to present the menu and capture user selection, emulating advanced features of tools like PXELinux.[40][36][41]
Variables in iPXE scripts provide dynamic adaptability, with built-in options such as ${net0/ip} for the IP address of the first network interface and ${net0/mac} for its MAC address. The set command assigns custom values, like set [server](/page/Server) http://boot.ipxe.org, enabling reuse across the script. Conditionals enhance flexibility through if/else structures, which evaluate expressions for flow control; for example, if isset ${[server](/page/Server)}; then [echo](/page/Echo) Server found; else [echo](/page/Echo) No [server](/page/Server); fi checks variable existence, while protocol fallbacks can be implemented as dhcp || [exit](/page/Exit) to handle network failures gracefully.[21][42][43]
Automation examples leverage these elements for secure and tailored booting. Password-protected menus use the login command to prompt for credentials, storing them in ${username} and ${password} variables, which can then gate access to options like chain http://${username:uristring}:${password:uristring}@my.web.server/boot.ipxe for authenticated HTTP boots or sanboot with CHAP for iSCSI. Integration with provisioning tools like Foreman involves configuring iPXE to chainload scripts generated by the server, reducing provisioning times via HTTP over TFTP; this requires installing iPXE boot images and setting DHCP filenames to point to Foreman-generated unattended scripts, such as http://satellite.example.com/unattended/iPXE?bootstrap=1. Dynamic menus can also incorporate conditionals for basic client detection, though advanced OS-specific logic often relies on server-side processing of client variables like MAC addresses sent in HTTP requests.[44][34]
Debugging iPXE scripts utilizes verbose output and error handling mechanisms. Scripts can employ the echo command for informational messages, and error continuation is achieved with operators like || after commands (e.g., dhcp || echo DHCP failed). Build-time configuration sets log levels via LOG_LEVEL in config/console.h, ranging from LOG_EMERG for system-unusable emergencies to LOG_DEBUG for detailed tracing, with LOG_ALL enabling comprehensive output to consoles or syslog. Common error codes, derived from PXE standards, include 0x0000 for success, 0x0001 for general failure, 0x0051 for DHCP timeout, and 0x003b for TFTP file not found, aiding in troubleshooting network or file access issues during script execution.[21][45][46]