PXE Magic: Flexible Network Booting with Menus

Set up a PXE server and then add menus to boot kickstart images, rescue disks and diagnostic tools all from the network.
Add Syslinux

Now that TFTP is set up, all that is left to do is to install the syslinux package (available for most distributions, or you can follow the installation instructions from the project's main Web page), copy the supplied pxelinux.0 file to /var/lib/tftpboot (or your TFTP directory), and then create a /var/lib/tftpboot/pxelinux.cfg directory to hold pxelinux configuration files.

PXE Menu Magic

You can configure pxelinux with or without menus, and many administrators use pxelinux without them. There are compelling reasons to use pxelinux menus, which I discuss below, but first, here's how some pxelinux setups are configured.

When many people configure pxelinux, they create configuration files for a machine or class of machines based on the fact that when pxelinux loads it searches the pxelinux.cfg directory on the TFTP server for configuration files in the following order:

  • Files named 01-MACADDRESS with hyphens in between each hex pair. So, for a server with a MAC address of 88:99:AA:BB:CC:DD, a configuration file that would target only that machine would be named 01-88-99-aa-bb-cc-dd (and I've noticed it does matter that it is lowercase).

  • Files named after the host's IP address in hex. Here, pxelinux will drop a digit from the end of the hex IP and try again as each file search fails. This is often used when an administrator buys a lot of the same brand of machine, which often will have very similar MAC addresses. The administrator then can configure DHCP to assign a certain IP range to those MAC addresses. Then, a boot option can be applied to all of that group.

  • Finally, if no specific files can be found, pxelinux will look for a file named default and use it.

One nice feature of pxelinux is that it uses the same syntax as syslinux, so porting over a configuration from a CD, for instance, can start with the syslinux options and follow with your custom network options. Here is an example configuration for an old CentOS 3.6 kickstart:

default linux
label linux
    kernel vmlinuz-centos-3.6
    append text nofb load_ramdisk=1 initrd=initrd-centos-3.6.img 
    ↪network ks=http://10.0.0.1/kickstart/centos3.cfg

Why Use Menus?

The standard sort of pxelinux setup works fine, and many administrators use it, but one of the annoying aspects of it is that even if you know you want to install, say, CentOS 3.6 on a server, you first have to get the MAC address. So, you either go to the machine and find a sticker that lists the MAC address, boot the machine into the BIOS to read the MAC, or let it get a lease on the network. Then, you need to create either a custom configuration file for that host's MAC or make sure its MAC is part of a group you already have configured. Depending on your infrastructure, this step can add substantial time to each server. Even if you buy servers in batches and group in IP ranges, what happens if you want to install a different OS on one of the servers? You then have to go through the additional work of tracking down the MAC to set up an exclusion.

With pxelinux menus, I can preconfigure any of the different network boot scenarios I need and assign a number to them. Then, when a machine boots, I get an ASCII menu I can customize that lists all of these options and their number. Then, I can select the option I want, press Enter, and the install is off and running. Beyond that, now I have the option of adding non-kickstart images and can make them available to all of my servers, not just certain groups. With this feature, you can make rescue tools like Knoppix and memtest86+ available to any machine on the network that can PXE boot. You even can set a timeout, like with boot CDs, that will select a default option. I use this to select my standard Knoppix rescue mode after 30 seconds.

Configure PXE Menus

Because pxelinux shares the syntax of syslinux, if you have any CDs that have fancy syslinux menus, you can refer to them for examples. Because you want to make this available to all hosts, move any more specific configuration files out of pxelinux.cfg, and create a file named default. When the pxelinux program fails to find any more specific files, it then will load this configuration. Here is a sample menu configuration with two options: the first boots Knoppix over the network, and the second boots a CentOS 4.5 kickstart:

default 1
timeout 300
prompt 1
display f1.msg
F1 f1.msg
F2 f2.msg

label 1
    kernel vmlinuz-knx5.1.1
    append secure nfsdir=10.0.0.1:/mnt/knoppix/5.1.1 
    ↪nodhcp lang=us ramdisk_size=100000 init=/etc/init 
    ↪2 apm=power-off nomce vga=normal
    ↪initrd=miniroot-knx5.1.1.gz quiet BOOT_IMAGE=knoppix
label 2
    kernel vmlinuz-centos-4.5-64
    append text nofb ksdevice=eth0 load_ramdisk=1
    ↪initrd=initrd-centos-4.5-64.img network
    ↪ks=http://10.0.0.1/kickstart/centos4-64.cfg 

Each of these options is documented in the syslinux man page, but I highlight a few here. The default option sets which label to boot when the timeout expires. The timeout is in tenths of a second, so in this example, the timeout is 30 seconds, after which it will boot using the options set under label 1. The display option lists a message if there are any to display by default, so if you want to display a fancy menu for these two options, you could create a file called f1.msg in /var/lib/tftpboot/ that contains something like:


----| Boot Options |-----
|                       |
| 1. Knoppix 5.1.1      |
| 2. CentOS 4.5 64 bit  |
|                       |
-------------------------

<F1> Main | <F2> Help
Default image will boot in 30 seconds...

Notice that I listed F1 and F2 in the menu. You can create multiple files that will be output to the screen when the user presses the function keys. This can be useful if you have more menu options than can fit on a single screen, or if you want to provide extra documentation at boot time (this is handy if you are like me and create custom boot arguments for your kickstart servers). In this example, I could create a /var/lib/tftpboot/f2.msg file and add a short help file.

Although this menu is rather basic, check out the syslinux configuration file and project page for examples of how to jazz it up with color and even custom graphics.

______________________

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Syslinux menus

HPA's picture

In the current version of Syslinux, there is a more natural way to do menus with the module vesamenu.c32. See the documentation file doc/menu.txt in the Syslinux distribution:

http://syslinux.zytor.com/doc/menu.txt

default settings

Marian Marinov's picture

If you don't want to reinstall the machines every time it is a good idea after the installation is finished, the installed machine to tell the PXE server to reset the default option to local.

When you have:
default local

the machine simply boots from its local bootable devices.

I do that by having a simple cgi script in bash which changes the default in the /var/lib/tftpboot/pxelinux.cfg/MAC-ADDRESS to local.

I call this script from the installed machine with wget or curl. This way on the next reboot it will not start to reinstall.

Beware of the wrong miniroot.gz !

fonini's picture

Thanks for this article! I decided to try it out just for the fun of it, but along the way I realized I had needed this for a long time. My job involves training UMTS operators' personnel on the use of their GPRS equipment, and I usually go in with a bunch of Knoppix CDs so the trainees can use the IP tools available or installable there -- from Wireshark, to VLANs and IP tunnels, to mobile phone simulators. While network-booting Knoppix isn't always the most practical solution in this situation, it does help in some cases.

However, I'd like to point out a mistake in the article which could frustrate some other readers' efforts:

The miniroot.gz file located on the /boot/isolinux directory of the Knoppix CD cannot be used for this, because it doesn't support NFS mounting (at least on the Knoppix 5.1.1 and 5.3.1 versions I tested).

You have to use the miniroot.gz file off the /tftpboot directory of a Knoppix Terminal Server. To get that, just boot a Knoppix LiveCD normally (no network boot yet) and start the Terminal Server on the Knoppix Services menu. Wait a few seconds after it is started and the miniroot.gz file will appear under that directory (it is only created when you start the Terminal Server). Now you can copy it to a pendrive or over ssh to your "real" terminal server.

Also, you have to do that with the same Knoppix version you plan to PXE-boot later; files from the recently released 5.3.1 version can't boot a 5.1.1 Knoppix, and vice-versa.

I'll still take in the Knoppix CDs, though. I give them to the trainees after the course, and I have tallied lots of "conversions" this way -- people just didn't know such powerful tools were available for the taking, and this is a real eye-opener for them.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState