Setting up a netboot server in Fedora/CentOS

I’ve had a request for an explanation on how we use PXE and syslinux in our school. In a previous post, I talked a bit about chain-loading pxe, but didn’t explain much on how our system is set up.

So here goes…

Our primary goal in setting up a PXE environment was to have some way of imaging our computers without having to screw around with an ancient version of Norton Ghost and without having to put a floppy in every computer.

The problem was that we really didn’t want students to be able to reimage the computers whenever they wanted to, and there were other tools we wanted to use that we wanted restricted.

The solution was PXELINUX’s simple menu, and it works beautifully! This post will walk you through the process of setting up PXELINUX (and gPXE while we’re at it).

For this post, I am assuming that you already have a DHCP server and a web server set up.

There are three things we need to set up:

  1. TFTP server
  2. gPXE
  3. Syslinux

The first step is to set up a TFTP server to carry our gPXE images.

  1. Run yum install tftp-server
  2. Edit /etc/xinetd.d/tftp and change the line that says disable = yes to disable = no
  3. If this is the initial installation of xinetd, you may need to run chkconfig --levels 2345 xinetd on service xinetd start at this point. Otherwise, it might be a good idea to run service xinetd reload

Now, for the next step, we need to download our gPXE images. gPXE is an extended version of PXE that allows you to load images over http and https in addition to the usual tftp. As most (all?) network cards don’t come with gPXE drivers, we will be using PXE to download and bootstrap our gPXE drivers.

As mentioned in my previous post, some of our motherboards seem to have issues mixing PXE and their normal PXE UNDI drivers, so I prefer to use gPXE’s native drivers rather than its UNDI driver.

However, we have four computers whose network cards just don’t work with gPXE’s native drivers, so we will direct those four computers to the gPXE UNDI driver.

So let’s grab and setup these drivers:

  1. Go to ROM-o-matic and choose the latest production release
  2. For output format, choose “PXE bootstrap loader image [Unload PXE stack] (.pxe)”
  3. Choose NIC type “all-drivers”
  4. Click on “Customize”
  5. Check the box that says “DOWNLOAD_PROTO_HTTPS”
  6. Click on the button that says “Get Image”
  7. Save file to /tftpboot/gpxe.pxe
  8. Change NIC type to “undionly”
  9. Click on the button that says “Get Image”
  10. Save file to /tftpboot/undi.pxe

I’m assuming you’re running the ISC dhcp server (dhcp package on both Fedora and CentOS). If not, you’ll have to work out these next steps yourself.

You need to edit /etc/dhcpd.conf and add the following lines:

next-server     ip address;

if exists user-class and option user-class = "gPXE" {
    filename "http://webserver/netboot/pxelinux.0";
} else {
    filename "/gpxe.pxe";

Where ip address is the ip address of your TFTP server and webserver is the name/ip address of your web server.

If you have some computers that won’t pxeboot using gPXE’s native drivers (you’ll be able to tell because the computers will show the gPXE loading screen, but won’t be able to get an IP address using DHCP while in gPXE), change the last five lines above to:

if exists user-class and option user-class = "gPXE" {
    filename "http://webserver/netboot
} else {
    if binary-to-ascii(16, 8, ":",
       substring(hardware, 1, 6)) = "mac address 1"
    or binary-to-ascii(16, 8, ":",
       substring(hardware, 1, 6)) = "mac address 2" {
        filename "/undi.pxe";
    } else {
        filename "/gpxe.pxe";

Where “mac address 1” and “mac address 2” are the MAC addresses of the computers that don’t work with gPXE’s native drivers. Please note the MAC address are without leading zeros (i.e. 00:19:d1:3a:0e:4b becomes 0:19:d1:3a:e:4b).

At this point, if you boot any computer on your network off the NIC, you should see something like this:

The next step is to setup PXELINUX, a part of the Syslinux Project. PXELINUX is a small bootloader designed for booting off a network.

  1. On your web server, create a directory called “netboot” in your web root (normally /var/www/html on Fedora/CentOS).

  2. Run

     yum install syslinux

    or, as an alternative, build a newer version of syslinux. I recommend at least 3.75 (the version in Fedora 12), though I’m using 3.82 at the school.

  3. Copy (at minimum) chain.c32, menu.c32, vesamenu.c32 and pxelinux.0 to “netboot” in your web root. (These files will be located in /usr/share/syslinux if you installed the package using yum.) At this point, you’ll probably want to check for other modules that might have some potential. We use ifcpu64.c32 to decide between 32-bit and 64-bit Fedora on the computers.

  4. Run:

     yum install memtest86+
     cp /boot/elf-memtest86+-4.00 \

    (Note that “your_web_root” will most likely be /var/www/html)

  5. Download this picture and save it to your_web_root/netboot

  6. Change directory to your_web_root/netboot

  7. Run

     mkdir pxelinux.cfg
     cd pxelinux.cfg
  8. Create a file called “default” that contains the following:

     default vesamenu.c32
     timeout 40
     prompt 0
     noescape 1
     menu title Boot Options
     menu background menu.png
     menu master passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
     label local
     menu label ^Boot from hard drive
     kernel chain.c32
     append hd0
     label admin
     menu label ^Administrative tools
     kernel vesamenu.c32
     append pxelinux.cfg/admin
     menu passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
  9. Create a file called “admin” that contains the following:

     default vesamenu.c32
     timeout 40
     prompt 0
     noescape 1
     menu title Administrative Tools
     menu background menu.png
     menu master passwd $4$tek7ROr8$xzFCb2QVEWsc2msx3QsErbRuo0Y$
     label memtest
     menu label ^Memory tester
     kernel memtest

If you boot any computer on your network off the NIC, you should see something like this:

Main boot menu
Enter your password for Admin tools
Admin tools

So now you have a double layered menu system with a password required to get to the second layer. For reference’ sake, the current password is “purple”, and you can generate your own password by running sha1pass (included in the syslinux package).

If you wanted to add other administrative tools, you would add them to the file “admin” in netboot. For more information on how to add items to the menu, see this page.

The Nokia N900

I got a Nokia N900 for Christmas. No, to be more accurate, I got a Nokia N900 after Christmas. We had some friends who were spending Christmas in the States, so I ordered one off of Amazon and had it shipped to their home. It was a full $150 cheaper than it would have been here. The bummer was having to wait until they got back to Beirut to open it.

So, I’ve been using it for the last few weeks and there are some seriously cool things, as well as some things that are less cool.

First off, the good:

  1. Root access
  2. Native X Windows, so most programs run on it without having to modify the source
  3. A very sensitive touch screen
  4. Nice effects
  5. SSH server and client
  6. An 800×480 display crammed into 3.5″
  7. Community-run repositories so I can roll and publish my own packages
  8. And finally (just in case I forgot), Root access

But there is some bad:

  1. OpenGL ES 2.0: One of the first things I wanted to do with this was play BZFlag on it. Nope, it’s not in the repositories and can’t be compiled because it requires glBitmap(), glRasterPos3f() and various other functions not available in either OpenGL ES 2.0 or 1.1. I understand the motivation between ES, but surely there is some value in a OpenGL -> ES wrapper. I’ve found one here, but it doesn’t implement the above functions. I’m hoping to do some stuff with this, but I’m no OpenGL expert. So for now I’m stuck playing Supertux (in non-OpenGL mode).
  2. Ovi Maps: Yeah, I got all excited about Ovi Maps 3.0.3 which is supposed to be super cool with voice and turn-by-turn directions, but I’m not able to upgrade from 1.0.1. Apparently the N900 was left out of the first batch of smartphones to get the updates. Having said that, 1.0.1’s Lebanon maps are incredibly useless, so unless 3.0.3 includes better maps, it will all be pointless anyway.
  3. Skype: There’s no video. There’s even a second (crappy) camera on the phone that points towards the user, but video just isn’t available. Unfortunately, I don’t have my family on GoogleTalk yet, so I haven’t been able to test whether that’s any different.

Despite the above flaws, I am extremely happy with this phone. I can hack on it without having to jailbreak it. What more can you ask for? Aside from a reasonable data plan from MTC Touch (my local cell phone service provider)…