Just moozing

Before you can check your notes, you must make them…

PXE, aka. boot-on-LAN

with 5 comments

PXE boot is a way boot PCs and other devices over the LAN. The common examples are reinstallation of multiple similar machines or having a centralized boot image for an entire classroom or netcafé.

Besides using it for reinstallation or similar non-production tasks, you have two choices: thin and fat clients. Both of them will not use the hard disk (if any) for booting or loading the operating system, but will retrieve the necessary data from the PXE server. The difference is where the processing is done.

Thin clients only handles the presentation layer. They are in essence only sent what to show on the screen. Examples are remote desktop (in Windows or Virtualbox), LTSP and Citrix clients.

Fat clients use the processing power and memory of the client. Normally, this requires for a lot of data to be transferred to the client at boot time for the operating system to be able to function, but using accessible network storage limits the amount of start up data.

On my home network, I have no reason to use PXE to boot thin clients, but the idea of fat clients is appealing. Media-less installation, backup over the net and multiple boot images for the same hardware are my first ideas. The last part would solve a long-standing issue of how to work with kernels on a production machine – a relevant issue when your laptop is too new to be properly supported by Linux and you want to test kernels, modules or programs that may cause unacceptable crashes on a production PC.

Basic Setup

Icons from openclipart and dia

The basic setup for PXE booting

The basic components are the DHCP server, the PXE server and the storage server (in our case, it is running NFS).

DHCP is used in almost any subnet to give clients IP addresses, netmasks, gateway IP and DNS server IP. Besides this information DHCP may convey other information, like the tftpd server and the initial boot file name used by PXE. On my network the DHCP router is on the router.

PXE server runs the tftpd service, that the client tries to access in order to download the specified initial file. Other files, like the kernel to be booted, are also downloaded from the PXE server. On my network, it is running as a virtual machine. I don’t consider this to be smart for performance reasons.

In the diagram I have included a storage server. Some kernels have built-in NFS support to enable them to use network shares for file storage. This may require a lot of hard disk space, and will require I/O activity on the disk – something that Virtual machine are not good at. In my setup, the NFS storage is directories export from the PXE server (which i a virtual machine). It is not the best setup, and it is obvious from the BackTrack installation timing (approx. one hour) that is to be improved.

Specific installation

Debian installation

The guide I used is from debian-administration.org. It is fairly old, but is still useful. Two comments: It is a guide of how to PXE install etch and not the newest Debian. On my PxeServer (running Lenny), /etc/init.d/inetd is now called /etc/init.d/openbsd-inetd.

I chose this guide, also because other guides show how to PXE boot one image, not how to make a boot menu. In the end, you have to type the name of the system you want to boot – it works, but it would be cool to have a selection menu like grub.

I use my router for DHCP, so I had some issues with OpenWrt related to how to get DNSmasq to send the extra DHCP information needed to PXE boot. Wireshark is very informative and useful for debugging DHCP issues.

One very cool part about Debian installation is that, they have made a netboot version that enables you to download a minimal set of files and the rest from repositories. On my PXE server, there are 5.4 Mb of Debian installation files. I use apt-cacher-ng to proxy the packages, and it seems that it will cache the installation files also.

Backtrack installation

A live BackTrack system is possible over PXE, there are even a guide in the BackTrack forums. The guides worked for me, except for two issues. The first is that the nfsroot parameter takes an IP address, not a hostname and the second was that I (stupidly) copied [LOCALSUBNET] instead of replacing it with Apparently, I need to brush up on my knowledge of NFS.

Boot time is about 2 minutes from the time I choose network boot to the command prompt. This will be quicker on dedicated hardware as my pxe boot server is running in virtual box with the BackTrack CD mounted as an ISO. Yes, this setup will be modified later, when I get to updating my non-virtual server.

It is possible to use the system now without touching the hard disk. This is useful for testing if BackTrack works on certain hardware before doing the actual installation, but for my purposes, I use the install.sh script on the desktop to reinstall my Asus Eee.

My Eee has never succeeded as a good and usable laptop for me. The keyboard is too small and I have had strange (temporary) lock-ups of the SSD disc. But as a network tool, I think it has the right size, and so I will use it with BackTrack for teaching puposes.

Installation of BackTrack took about one hour, and was hassle free. The BackTrack installation needs to be modified to start X at boot time and wicd is odd, but otherwise I’m looking forward to use the tools.

Other possibilities

As I would like to have a way of making backups of entire partitions, it seems that Clonezilla is worth looking at. They even have a guide of how to use it with PXE boot (that I have not tried yet).

On of the main reasons for looking into PXE now is that we want to make a system, where the entire class boots our Linux on their laptops. The problem is that we have 20 students in a class running different versions of Windows (and Linux) and different languages. The fat clients case, that I mentioned above, would resolve that with a minimum of extra hardware. I will look into Diskless Remote Boot  in Linux. The alternative, that we have looked at, is the Linux Terminal Server Project, but it was our impression that it was primarily designed for thin clients (and that it was very easy to set up).


Written by moozing

June 21, 2010 at 09:00

Posted in Tech

Tagged with , ,

5 Responses

Subscribe to comments with RSS.

  1. […] to handle the part about the PC that the students use, we are looking into drbl (as mentioned in an earlier post). That should allow us to lock down the system enough to make sure that all the student PCs work […]

  2. […] desktop is an old Fujitsu Siemens desktop PC with most stuff build in. It works nicely with PXE booting and 2gb of RAM.  The graphics […]

  3. […] decided that the command line solution described in an earlier post, could be made to look nicer with menus and I want it to be easier to update the entries with the […]

  4. Thank you for any other magnificent article. Where else may anybody get that kind of information in such a perfect way of writing? I have a presentation next week, and I am on the look for such info.

    diskless caffe

    July 25, 2012 at 13:43

    • Praise is always welcome. Thanks.
      I try to include as many links as possible, so the reader has a chance of relocating the information I have assembled.


      July 25, 2012 at 20:38

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: