Chain Booting with PXE

In a real network boot environment, you still need a DHCP server configuration. Admins are faced with the question of how to deliver the boot configuration to the booting iPXE. One approach is to embed the initial script into iPXE, but this option is not very flexible. For each change, you need to build a new iPXE image, and all systems must use the same script.

A more elegant approach relies on a little trick: In PXE chainloading, the client actually retrieves the IP address twice. On first access, the PXE ROM on the network card is assigned an IP address via DHCP; it downloads the specified file using TFTP and executes it as a PXE-program (Figure 1). The response to the first request is typically undionly.kpxe, which uses the PXE-ROM Undi interface on the network card because it does not have native network drivers. The second time, the PXE program – iPXE in this case – initializes the network card and again receives an IP address, together with the additional configuration options, via DHCP.

Along with this second query, iPXE identifies itself through the user-class option. The DHCP server can then respond with a different configuration for iPXE. The configuration in Listing 3 works well with the ISC DHCPD DHCP server. The PXE ROM responds to the filename option. When iPXE then sends a DHCP request, ISC DHCPD transfers the root-path option with the URL for the sanboot command. In this case, the path leads to an ISO image.

As an alternative to PXE chainloading, iPXE can also be embedded as PXE-ROM in popular network cards, thus replacing the vendor's PXE firmware – the key word is ROM Burning [9]. On many network cards, you can permanently store the configuration (IP settings, SAN-URL) in NVRAM via the config menu so that a server can boot from the Ethernet SAN even without DHCP.

iPXE Automation

The second iPXE mode provides a good basis for automation. You need to change the BIOS settings of all systems so that they first load a script over the network and only then boot from the local disk. This means intervening at another point in the system, because the system startup is preceded by centrally managed scripts.

The scripting language is quite simple:

• :label defines a jump target
• goto label jumps to a jump target
• && and || let you create logical conditions
• iseq compares values.

With these language constructs and the iPXE commands, an admin can create amazingly versatile scripts. The iPXE website [10] lists examples that reveal more details.

Useful Helpers

Inventorying is a simple example of a feature you can add through iPXE. The script in Listing 4 collects the necessary data in a Google form, which is available for testing.

In the example (Listing 5), Qemu sets inventory data itself at startup and loads Listing 4 from a server; the results are available online [11].

Another useful scenario is a login that calls an installation menu. If the login attempt fails, the user can only boot from the local disk. The script in Listing 6 combines a menu and simple control structures. Again, Qemu helps with development and testing.

qemu -kernel ipxe.lkrn -append 'dhcp && chain http://goo.gl/j8MbXI'

The sample PHP script in Listing 7 verifies that the password matches the user name written backward and then redirects to the specified URL. In real life, the web server would deliver different content depending on the application.

Finally, the fourth demo script (Listing  8) offers a menu that lets the user choose between Ubuntu and Fedora. To keep things simple, the URL for the distribution is stored in a variable so that you can replace Fedora 20 with 21 by changing one line.

Thanks to exit, iPXE jumps back to the previous menu. In this way, you can assign the components of nested menu structures to separate scripts, thus keeping things simple.

For production use, you need to provide the iPXE script via DHCP. Follow the Sanboot example and use a selective PXE boot in the DHCP configuration (Listing 9). The difference in the filename option is the URL for the iPXE script. The powerful iPXE only transfers undionly.kpxe via TFTP, and a web server delivers all the other resources.