The versatile networkboot loader iPXE

Wakeup Call

© Lead Image © nyul, 123RF.com

© Lead Image © nyul, 123RF.com

Article from Issue 167/2014
Author(s):

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

Table 1

iPXE Image Types

File Name

Function

ipxe.pxe

iPXE boot image

ipxe.dsk

Floppy disk image

ipxe.usb

Image for USB sticks

ipxe.iso

CD image for CDs or DVDs

ipxe.lkrn

A kernel image used by other bootloaders or Qemu

undionly.kpxe

Image for PXE chain loading

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

config/local/console.h

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.

Listing 2

config/local/general.h

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:

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • FAI

    FAI helps you automate the process of installing and configuring new Debian systems.

  • Knoppix 6.3 Exclusive!

    Knoppix creator (and Q&A mastermind) Klaus Knopper shares some insights on the latest release.

  • Upstart

    The slow Linux boot has troubled users for years. Now the Upstart project offers a fresh approach to the problem of booting Linux.

  • Opsi

    Opsi extends Linux's convenient software distribution methods to Windows PCs on heterogeneous networks.

  • USB Multiboot Tools

    MultiBootUSB and MultiSystem tools transfer multiple Live systems to a USB flash drive and even install a matching boot manager automatically.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News