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 [1] 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 [2] 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 [3].

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:

Figure 1: iPXE boots locally or via Ethernet SAN and also supports PXE chaining.

• 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, gcc, binutils, make, perl, and 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  [4]. 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).

For RPM systems, I extended iPXE to include a SPEC file [5], which creates a ready-to-use RPM when you call make rpm.

Configuration

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.

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.

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:

make EMBED=script.ipxe

The iPXE project describes other ways to integrate scripts into the boot process  [6].

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 [7].

Party SAN

iPXE is the tool of choice for booting a system from an Ethernet storage area network (SAN) [8]; 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

If necessary, sanboot also boots from the local hard disk:

sanboot --no-describe --drive 0x80

Because 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:

Figure 2: FreeDOS can boot over the Internet thanks to iPXE.

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).

Figure 3: An error message and an interactive shell appear if iPXE fails to find an image under the URL.