PXELINUX can be used to boot a diskless Linux device over a network. Matt Butcher, who uses PXELINUX to boot set-top boxes, explains how PXELINUX works and how to use it in this interesting technical “HOWTO” article.

Network Booting of a diskless Linux device with PXE

PXE (Preboot eXecution Environment) is Intel's loosely defined standard for booting PCs over the network. A PXE-capable BIOS or boot ROM can download bootstrapping code and load an operating system over the network. Booting Linux with PXE is a straightforward way of starting a diskless workstation or appliance in a closed network.

Diskless Appliances: When and Why?

Network booting is not the appropriate choice for all. However, in an environment where the appliance will always be operating on a high speed (>=10Mbit) LAN, it is an option worthy of examining. There are two major advantages in opting for network booting over local booting. First, storage is expensive, and solid-state storage solutions (such as M-Systems DiskOnChip) are particularly so, where the cost of 64M of storage may cost as much as a 20G hard drive.

The other advantage comes in the form of administration. In the case of a local storage device, upgrades must be done on every single appliance. Network-based upgrades to local storage are difficult to write, and administering the upgrade process can be a long and tedious process. The alternative for local-storage clients is to visit every client and make changes there. Obviously, this is a time consuming task, and in many cases is not even a possibility. Thus, a simple security update or configuration change may result in hours or days of work to update all of the appliances.

Network booting goes a long way toward solving this problem. Upgrades are done by updating the software on the server and then rebooting the clients. Without the risk of corrupting local storage or the hassle of 'pushing down' new images, administration is vastly simplified. Additionally, there is no special software that must be written on the client to listen for new updates, or have to run checksums against images, etc. Upgrades are only a reboot away.

Setting It Up

This system is what I used to get a set of Allwell set top boxes to boot Linux over the LAN.

• Client — The client in this case is an Allwell STB3036 set top box using a TV as it's display. The STB has an IR keyboard and remote and has a BIOS patch that lets it boot PXE-style.

• Network — The speed of the network is largely dependent on the number of clients and the amount of network traffic each will produce. Though I'm sure it could be run with less, I recommend that the network be at least 10Mbits but preferably, a Switched 100Mbps CAT5 network.

• Server — The server doesn't need to be a big iron. It just needs a decent (read 'Celeron or K6-2') processor and a hearty amount of RAM and disk space. Any Linux distribution should do. NFS is good for storing persistent data for the clients. I used hpa-TFTP, because it is maintained by H. Peter Anvin — the one who wrote PXELINUX. I figured it was a safe bet. ISC DHCP comes with Trustix, which I was already using.

• Client Files — These are stored on the server. TFTP serves them to the client during the course of the boot. PXELINUX handles the network bootstrapping of the kernel. There is nothing special about the kernel used for this. No need for patches, etc. Just make sure that NFS and initrd are built in, which they usually are.

• HOWTO document — a detailed document on how, specifically, to setup PXE for an Allwell STB (which is my test platform) is available here.

PXE defines a method for the BIOS or NIC ROM to fetch a booting code over the network. It does this via standard Internet protocols. When the appliance is powered on, the BIOS or ROM makes a DHCP request. The DHCP server, recognizing the appliance as a network-booting client, returns instructions on the location of a tftp server and the name of the name of the file that it should download from the server. In this case, the file is the PXELINUX network bootloader, 'pxelinux.0'. It also, of course, assigns the appropriate IP information.

The appliance then makes a connection to the TFTP server and requests the 'pxelinux.0' file. When the PXELINUX bootloader is downloaded, it executes. First, it checks it's configuration files (located on the tftp server) and then downloads the Linux kernel, passing it the necessary kernel arguments, including the IP information received from DHCP. When the kernel loads, it uses the IP information provided for it. The kernel can either download an initial ramdisk (initrd) and use that as a root filesystem, or it may just connect to an NFS server.

Once the kernel has gotten the root file system setup, the operating system can complete the boot process, and the system is ready for use.

The Practicality of PXE

If the above sounds simple, that's because in most cases it is. Configuring DHCP is about the hardest part, and it took me (a relatively novice DHCP administrator) only half-an-hour. I hear that in some cases a PXE server is required, and not all network cards support PXE, but in the case above, the setup took me less than a day from start to finish.

With the configuration above, there is a surprising amount of flexibility in administration. For instance, the issue of supporting multiple client versions is conveniently handled by DHCP or PXELINUX. The ISC DHCP server (and most others) will allow parameters to be specified by MAC address or address ranges. Different clients can be directed to different tftp servers. The PXELINUX client will check for a configuration file specific to the MAC address of the particular client, and so each client may have a different setup, including different kernels, initrds, or NFS servers. Once started, the OS can mount home directories via NFS, and each user can access their own files. In short, the system is deceptively powerful.

Conclusion

Using PXE is not appropriate in all situations, but on a high-speed LAN, it may provide the fastest and most flexible environment for diskless clients. By cutting down cost, time to develop, and administration effort, network booting proves a good alternative to local storage.

About the author: Matt Butcher is a systems integration consultant for Aleph-Null, Inc. Recently, his work has been focused on embedded Linux and Mozilla. All of his spare time is consumed with his newborn daughter who is, in his opinion, the most beautiful baby every born.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.