Network Booting via PXE: the Basics

The majority of computer users are familiar with BIOS options as long as they don’t go further than selecting the main bootable device or ordering that priority list such as HDDs first, then optical drives, and so forth. In the past few years, however, another option has appeared there. It’s called Network Boot or the infamous PXE Boot. In this article we will give a brief overview of the basics of network booting.

Before we begin, let’s find out what networking booting is all about. After that we will explain the theory behind PXE booting in a nutshell without getting into advanced technicalities whatsoever. We will also examine a few ready to run practical solutions. The main purpose of this article is to elucidate what PXE is and to break down the entire process into small applicable steps.

Every so often we see questions and requests on bulletin boards where users are asking for help in order to network boot their computer to back up the files from a system on which the operating system went bad. Network booting wasn’t exactly designed to be "yet another" booting option. Its purpose is different, and we are going to explore that in detail. It differs a great deal from "classic" booting. 

Network booting , as its name suggests, stands for the process that boots up a computer (or device) from the network-not from local disk drives or removable media. This technology is meant to be used in clustered environments where specific nodes (diskless/thin clients) may not have a local drive. It’s also used by system administrators when they are doing unattended multiple simultaneous operating system installations.

PXE is short for Preboot eXecution Environment. It is the environment that allows devices to boot up via their network interface(s). The entire process follows a specific "client-server" model. It was first introduced and designed by Intel; the official document regarding its specifications can be found here .

On the next page we are going to see how PXE works and what the client-server model actually means. What do you really need in order to implement PXE on your network, and take advantage of this fancy technology that sounds oh so great (despite often being pronounced "pixie")? Once you know this, you will no longer confuse Network Booting with any other booting possibility.

{mospagebreak title=Theory of PXE}

PXE is not the only possible way to network boot, but it is one of the most popular. In a nutshell, a PXE server is nothing but a DHCP and TFTP server. You must dedicate one server from your network to be a PXE server. It should have the aforementioned services configured, up and running. Then the PXE server will be able to reply to PXE boot requests and aid the client system during its bootstrap session.

Basically, when you are configuring a client system in BIOS to be allowed to do network booting, right after the POST (Power on Self Test) process, the system executes the PXE bootstrap session. At first, it is going to look for DHCP servers from the network. An appropriately configured Proxy DHCP will reply with the entire list of possible PXE boot servers and deliver their IP addresses, while distributing an IP address to the client as well.

The user is given the possible choices of PXE boot servers (in most cases, there’s only one) during a boot menu. After selecting the required PXE boot server, the bootstrapping process begins and the PXE firmware asks for the exact path of the NBP (Network Bootstrap Program). After receiving this path, the download process begins. This is done via the TFTP; the initials stand for Trivial File Transfer Protocol (UDP, port 69).

As you can already guess from its name, this FTP is really "trivial," thus, simple. That is the main reason it is being used for remote booting, because it is easier to implement, to store and execute from the memory, and so forth. It doesn’t offer advanced functionalities like the generic FTP (TCP, port 21). Each has its own uses.

There is a workaround to avoid the need for a proxy DHCP, if only one NBP is going to be using across the entire network by each PXE client system. In this case, the address of the server, along with the exact path of the NBP, can be specified via the protocol called BOOTP. Even though BOOTP is a simplified minimalist version of DHCP, client computers will still be able to receive their IP address assigned via BOOTP.

The TFTP server is always necessary, because without it the NBP couldn’t be transferred. Once the client receives the chosen NBP, the package is verified, and should the process succeed, it is followed by execution. Up to this point, the entire NBP was stored in the system memory (RAM) of the client.

Intel PXE was created while taking in consideration the following key points: it should not interfere with existing DHCP servers that may be found on the network, it should be easily configurable and implemented on simple networks(even extended later, if need be), and the services should be capable of running from one server but also independently.

On the next page we will show you one of the simplest ways to create a PXE server under Microsoft Windows, say, XP. To do it you need at least two computers, since one is going to become the PXE server, while the other will become the PXE client system. The client system will be assigned its own IP address via Proxy DHCP, and then receive the contact details of the PXE server, download, verify, and execute the NBP. Let’s do it!

{mospagebreak title=Practical Solution}

All right, you have chosen the computer you are going to dedicate to being a PXE server. Now it’s time to download the necessary files, configure everything, and then set up the required services. As a general rule of thumb, you should create a new folder somewhere on the root partition, let’s say C:PXEServer. This directory will contain everything PXE-related on your server computer.

We are going to use the open-source TFTP server called TFTPD32 . This variation of server includes DHCP, TFTP, SNTP, and Syslog services as well, should the need arise. Now we will only use its first two capabilities. It is a tried and proven solution, probably the best freely available TFTP server. It is also provided to run as a Windows service.

Download and extract into C:PXEServer. At the time of writing, the latest version is v3.29. You don’t really need the service variation unless you plan to run the PXE server daemons 24/7 on your dedicated PXE server. Now you can create another folder in your aforementioned C:PXEServer. This should be called  TFTPRoot.

Now the time has come for us to grab us a lightweight boot-loader. For the purpose of this article, we will stick to one of the most popular, which is SYSLINUX . You can download the latest releases from this web directory. You should grab the .zip version. SYSLINUX has the following sub-variations: ISOLINUX, PXELINUX, EXTLINUX, and MEMDISK. Right now, as you can guess, we are going to use the PXELINUX boot-loader.

Extract the contents of the zip archive to a temporary folder and search for the following files: "pxelinux.0 " and "memdisk. " The last one can be found in the memdisk folder. Copy both of these files into your "C:PXEServerTFTPRootBoot" folder. So yes, we have also created a "Boot" folder in your TFTPRoot directory. Now you need another file from the syslinux package, it’s "menu.c32 " and located in com32modules.

Now that those three files have been copied into your Boot folder of TFTPRoot, we just need two more things. First we must grab an image that should be executed as soon as the PXE bootstrapping process finishes running the boot-loader. PXELINUX is not an operating system, it is just a lightweight boot-loader destined to work with PXE environments. We need an image of an operating system with which to boot up.

This is where you can get creative and boot up with utility tools instead of OSes such as Memtest86+, Acronis True/Recovery Expert, Symantec Ghost, Clonezilla-SysRescCD, and whatnot. You can eventually boot into Windows 98SE, or your favorite lightweight Linux distribution such as DSL (Damn Small Linux). Right now this article will feature the quickest and simplest example-booting into MS-DOS.

The following two resources should always be used when you want to download excellent boot disks: AllBootDisks.com and BootDisk.com . Once you download the boot disk of your choice, say, Windows 98 SE, we need to create an image. The image formats supported by SYSLINUX are IMG, IMA, IGZ, ISO, and others. WinImage is a utility that runs under Windows and creates images with the .IMA extension. If you are downloading via AllBootDisks, then you can grab ready-to-run images (.img), like this .

Moving on, there’s one final thing you need to do-create a menu to display for the boot loader. In the C:PXEServerTFTPRootBoot create a new folder and call it PXELINUX.CFG - yes, give an extension to the folder. Now inside that newly created folder, create a new file called "default " without any extension. Be careful with your Windows Explorer settings-it may try to hide the extension, and if you create it as a text file, it becomes .txt.

With Notepad write (copy-paste) the following snippet and change where required.

DEFAULT menu.c32

TIMEOUT 100

ALLOWOPTIONS 0

PROMPT 0

MENU TITLE PXE Boot Menu

LABEL Win98SE

MENU LABEL ^Win98SE BootDisk

kernel memdisk

append initrd=Windows98_SE.img

LABEL StandardBoot

MENU LABEL ^Standard Boot

LOCALBOOT 0

 

Now it’s time to launch TFTPD32 for the first time. First of all, on the configuration menu panel you need to check both the TFTP server and the DHCP server because this utility can provide both services. How you configure it further depends on your network details and its specifics. Moving on, under the DHCP Server menu tab, set the boot file to the "/boot/pxelinux.0 ". The rest of the path isn’t required because it starts with TFTPRoot.

That should sum up everything. But once again, please, do not forget to configure the network settings under the DHCP server tab such as Default Route, WINS/DNS server, IP Pool Starting Address, Size of the Pool, and so forth. And of course, save the settings before launching the server. By doing so, your PXE server is fully configured.

You can now test your PXE environment. Any PXE-compatible client computer will be able to locate the Proxy DHCP Server, which assigns a new IP address from the pool and delivers the PXE server’s information. Then the NBP package is transferred to the client from the server via the TFTPD32 server. Thereafter, the booting process begins.

Everything should work well. If it does not, you should check the firewall configurations.

{mospagebreak title=Closing Thoughts}

As you can see, we have arrived at the end of this article. By now you should be familiar with network booting and know the real deal about PXE. Moreover, should you really need to set up a PXE server to take advantage of this technology, you now know where to look and how to do it all. We’d especially advise implementing network-based booting if you have diskless or thin clients.

Depending on what kind of operating system you are going to bootstrap onto via PXE, there are numerous options, as discussed earlier, in terms of choosing the operating system of the PXE server. Probably one of the easiest is using your favorite Linux distribution. Or if you already have a FTP, NFS, or HTTP server running, then you can set up PXE on that as well. The same goes for Windows Server operating systems, too.

As you surely could guess, system administrators are managing dozens/hundreds of computers with the same specifications. This means they are actually cloning the operating systems (or even the entire main system partition) for back up purposes, but also for easy and quick reinstallation, if necessary. Acronis is a prime example of a disaster recovery commercial suite that also does this. Clonezilla is an open-source alternative.

This article was a brief overview of network booting that presented the basics of PXE. An upcoming article will pick up from where we left off and present a step-by-step process for setting up a PXE server that runs a bootable rescue media, such as the one based on Acronis, or launches Clonezilla to restore some partition images or do any other tasks. You won’t want to miss that!

And finally, we can’t really finish without inviting you to join our helpful forums at DevHardware Forums . We have a strong base of resident professionals, enthusiasts, and tech experts. If you want to hear opinions on some service or ask some clarifications regarding some details just shoot us your questions. We’ll do our best to help. And you should also want to pay a visit to the forums of our sister-site, feel free to drop by DevShed Forums .

Google+ Comments

Google+ Comments