Southern Bread

So, last time around I mentioned that we set up a PXE boot system to allow us to run tools such as SpinRite and Memtest over the network at the office. That post was mostly for people who were generally familiar with the basics of network booting but just might need some help getting a DOS application like SpinRite to work. I want to expand this into a full PXE tutorial this time, so that even those folks who don’t understand it can get up and running if you want to. As is so often the case with just Googling around for info, you’ll tend to get fragments of what you need instead of the whole picture. I’ll do my best to make this clear and step by step.

Network booting has been around for a long time. When I was first getting into network administration, around 1997, network cards came with a socket on board. This socket was so that you could plug in a boot rom chip that you had to buy extra. I don’t remember ever seeing anyone use them, but I’m sure a lot of people used it to boot thin clients for IBM dumb terminal type scenarios. Now days the PXE standard is pretty much universal in PC’s. It’s a great spec that makes the whole process easy. It also helps that PC’s have tons of RAM to be able to handle large boot images. But, enough history though. What exactly happens during the PXE boot process? I’ll quote this from the SpinRite post:

That’s pretty much it in a nutshell. You can think of it the same way as booting from a CDROM or floppy disk, except that the binary being booted is coming from a TFTP(Trivial File Transfer Protocol) server on your network. PXE knows what TFTP server to contact and what boot image to download because you will specify them in every DHCP response packet by configuring your DHCP server to do so. The process really couldn’t be simpler. So, armed with this info, let’s see what you need to get started:

That’s pretty much it. Once you’ve grabbed all the packages, you can now start assembling the pieces. I’m going to use the standard folder locations, but you can put them anywhere you like. Just remember to change my commands to fit your changes. Also, this will all be shown using Ubuntu, so you’ll have to sort out what packages to get on your own if you use another distro. Or just download and compile them from source. It’s easy with a few Google searches. Now then, the first thing to do is make sure your TFTP server is set up right. It can be run standalone, but most people run it from the INETD wrapper daemon. Create a file in “/etc/xinetd.d/” called tftp. Open it and edit as such:

service tftp
{
        disable                 = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

Now, let’s make the TFTP root directory structure and copy the needed files in like this:

dave@localhost$> sudo mkdir -p /var/lib/tftpboot/pxelinux.cfg
dave@localhost$> sudo cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot
dave@localhost$> sudo cp /usr/lib/syslinux/memdisk /var/lib/tftpboot
dave@localhost$> sudo cp /usr/lib/syslinux/vesamenu.c32 /var/lib/tftpboot

At this point your TFTP server and folder structure is ready to go, except for the default configuration file. PXELINUX will look for it’s configuration file in a certain order. It looks for a file in the “pxelinux.cfg” directory named after the mac address of the booting machine first, and then downward in descending order using the hex encoded IP address of the machine minus 1 character, until it falls back finally to a file called default. This allows for grouping of machines based on address. Since we don’t group machines, we’ll put everything in the default file. So create a file in “/var/lib/tftpboot/pxelinux.cfg” called default and put this in it:

DEFAULT vesamenu.c32
PROMPT 0
MENU TITLE Network Boot Menu

TIMEOUT 50

LABEL local
  menu label ^Windows
  localboot 0

LABEL memtest
  menu label ^Memory Scanner
  kernel memtest.x86

LABEL spinrite
  menu label ^Disk Scanner
  kernel memdisk
  append initrd=spinrite.x86

This syntax feels very much like LILO syntax if you are familiar with that. DEFAULT is the file it will download and execute. In our case we are using the graphical menu executable generated by vesamenu.c32. It looks very nice. “PROMPT 0″ tells it to skip the command line type LILO style stuff and go straight to our graphical menu. TIMEOUT is the menu timeout in tenth’s of a second. So 50, here, means 5 seconds. The rest of it is pretty self explanatory. Arrowing down and hitting Enter on the “Memory Scanner” option will cause PXE to download and pass execution to the memtest.x86 executable file. In SpinRite’s case, memdisk is a sort of stub that you can append a boot image to in order to get a mini-environment that some software needs.

Now for phase two. None of this TFTP stuff will do you any good if your DHCP server isn’t handing out the proper information. So let’s edit your DHCP setup. Open the file called “/etc/dhcp3/dhcpd.conf” and find your subnet section. Then add these two directives:

  next-server        pxe.foo.com;
  bootfile           "pxelinux.0";

Now, bounce the DHCPD daemon and the XINETD server to get them active with their new configurations:

dave@localhost$> sudo /etc/init.d/dhcp3-server restart
dave@localhost$> sudo /etc/init.d/xinetd restart

And voila! You now have a functional PXE server. When you boot your desktop computer, go into the BIOS and set the boot priority to make “Network” or “PXE” first in the list. Now restart the machine and you’ll see your beautiful new PXE boot menu. If you’d rather not set PXE as the default boot device, you can usually still boot it at will by hitting a function key during the POST. It’s usually F9 or F12 to bring up a boot menu and select “Network”. And just to finish this off, here is a video of the finished product: