The versatile networkboot loader iPXE
iPXE simplifies the task of booting images over a network and also lets admins design dynamic boot menus that integrate scripts and boot images via HTTP(S).
Whether you are managing Linux or Windows, most automated provisioning systems depend on booting over the network with the Preboot Execution Environment (PXE). PXE provides the software for a standardized environment before the system actually starts. Within this preboot environment, the admin can influence the startup behavior to respond to special requirements, launch an OS installation process, or take other preliminary steps.
In the Linux world, PXELinux by the SysLinux project  is the de facto standard tool for network booting. In the shadow cast by PXELinux, other PXE bootloaders have emerged that make it easier to solve many tasks.
The iPXE project  provides a full open source PXE implementation. iPXE calls itself "…the leading open source network boot firmware." The project started life as a fork of gPXE and is still under active development. iPXE also inherits some features from the Etherboot project .
The goals for iPXE are to provide the best PXE implementation, make NICS bootable, and support and automate complex scenarios that involve booting from the network.
iPXE directly integrates a full feature set (Figure 1) – without the need for loadable modules. Usage scenarios for an admin implementing iPXE include:
- Displaying dynamic boot menus that differ depending on the boot system or user login
- Booting images via HTTP or HTTPS, also across the Internet
- Launching boot operations via I-SCSI, Fibre Channel over Ethernet (FCoE), or ATA over Ethernet (AoE).
iPXE also boots clients via Tagged VLAN, WiFi, or InfiniBand.
Use the Source!
You can install iPXE through the Debian and Ubuntu package management systems, but the package versions are missing documentation and are not up to date. I recommend building iPXE yourself. (You could also download and burn the ISO image file at the iPXE project website.)
The iPXE build dependencies,
syslinux are quickly installed. It is also a good idea to check out the Git sources so you will benefit from future updates.
The development model for iPXE relies on a stable trunk, whose builds always support use in production environments . iPXE does not have an official release; admins build it in the traditional way, using a Makefile:
git clone git://git.ipxe.org/ipxe.git cd ipxe/src make
The result ends up in the
bin/ subdirectory; depending on your requirements, different files are used to start iPXE (Table 1).
iPXE Image Types
iPXE boot image
Floppy disk image
Image for USB sticks
CD image for CDs or DVDs
A kernel image used by other bootloaders or Qemu
Image for PXE chain loading
For RPM systems, I extended iPXE to include a
SPEC file , which creates a ready-to-use RPM when you call
iPXE is configured using C header files in the
config/local directory. Inspiration for possible configurations is provided by the
.h files in the parent
config directory – each file is responsible for one aspect of iPXE. To edit the entries in
console.h, for example, you need to specify a
config/local/console.h file with the contents of Listing 1.
01 #undef KEYBOARD_MAP 02 #define KEYBOARD_MAP us 03 04 #undef LOG_LEVEL 05 #define LOG_LEVEL LOG_INFO 06 #define CONSOLE_SYSLOG 07 #define CONSOLE_VESAFB
Listing 1 sets a US keyboard layout and enables log output via syslog. With a few additional entries (Listing 2) in
config/local/general.h, you can configure HTTPS support as well as a customized product name, which iPXE displays when booting.
01 #define DOWNLOAD_PROTO_HTTPS 02 #define NSLOOKUP_CMD 03 #define TIME_CMD 04 #define VLAN_CMD 05 #define PXE_CMD 06 #define REBOOT_CMD 07 #define POWEROFF_CMD 08 #define PING_CMD 09 #define CONSOLE_CMD 10 #define IMAGE_PNG 11 #undef PRODUCT_NAME 12 #define PRODUCT_NAME "Schlomo Magic Network Boot"
When you build the iPXE image, you can embed a script, which the PXE bootloader automatically runs. Each iPXE script starts with
#!ipxe and contains some iPXE commands. A simple script to get you started with dynamic boot environments follows:
#!ipxe dhcp chain http://example.com/boot/script.php
You need to save the file – for example, as
script.ipxe, and integrate it into the build process as follows:
The iPXE project describes other ways to integrate scripts into the boot process .
iPXE generally supports two targets for the boot process: You can boot from a block device or directly download a kernel and an initrd and launch them. You will find precompiled images for the examples described in this article at GitHub .
iPXE is the tool of choice for booting a system from an Ethernet storage area network (SAN) ; it also supports I-SCSI, FCoE, and AoE. The
sanboot command is for all boot operations that need a block device.
sanboot goes with the URI of the block device; for example, for the I-SCSI LUN:
sanboot iscsi:boot.ipxe.org::::iqn.2010-04. org.ipxe.boot:public
sanboot also boots from the local hard disk:
sanboot --no-describe --drive 0x80
sanboot works at the BIOS level, the block device must possess a normal bootloader, which in turn loads the kernel and
initrd and specifies a matching root device.
A simple option for trying out this process is booting the live FreeDOS CD off the Internet in a Qemu virtual machine (Figure 2);
ipxe.lkrn must reside in the directory from which you invoke the command:
qemu -kernel ipxe.lkrn -append 'dhcp && \ sanboot http://ftp.gwdg.de/pub/misc/freedos/files/\ distributions/1.0/fdfullcd.iso || shell'
Qemu can start iPXE directly in
lkrn format; it passes the iPXE commands as options. If successful, iPXE does not return a message, because it hands over boot control. If iPXE cannot access the URL, the system starts an interactive shell (Figure 3).
Buy this article as PDF
A major setback for the Linux desktop.
Improved support for GPU in virtualization.
News site for the openSUSE community falls victim to a Wordpress exploit.
The source code is available online.
One out of three virtual machines on Microsoft Azure Cloud run Linux.
The form factor of the board makes it a drop-in replacement for Raspberry Pi.
Makes it easier for customers to move workloads into container-centric applications.
SUSE’s answer to container-centric operating systems.
Linux 4.9 is the biggest release in terms of number of commits.
The latest version of the official RHEL clone is here.