Tutorial: Boot Linux Over A Network

Configure your Linux installation, or get a broken system up and running without the need for optical discs and other hardware.

Posted May 18th, 2009 - 3 comments - Share This

You might think that booting a PC off another machine on the same network is the stuff of 1970s labs and thin-client computing. But there are many reasons why the technique is just as useful today as it was then, even with just two machines.

And don’t forget, if you’re a die hard Linux fan, check out other top tutorials – Build your own distro; Build a cluster computer and Build a portable web browser!

For starters, there are now many computers without optical drives, like netbook PCs or home media centres. The only way to upgrade or install an operating system on these devices, short of removing the hard drive, is to either install from a USB stick or use the network boot method. And if, for whatever reason, your system can't boot from a USB device then you only have one option left. Aside from those cases, network booting is also a technique that can help fix broken installations when hardware refuses to work, or distribute an upgrade across a network of machines without needing you to manually slot a disc in each drive.

The ability of your machine to boot off another network device is determined by what's termed the Preboot Execution Environment (PXE). This is a capability of your system BIOS that enables your machine to grab a network address and look for bootable code without first checking local storage, or for available bootable devices. If there are no such drives on your system, you might notice PXE in operation as it searches the local network for a bootable server candidate. It's this candidate that we're going to install, configure and provide.

Install a DNS Server

When a PXE-enabled machine is first turned on, it will attempt to initialise the network interface and connect to a gateway to get on the network. To do this, it's doing to need an IP address and the ability to find a server. The IP address allocation is handled by DHCP. This doesn't normally require configuration, as our switch or router works out DHCP automatically, but for PXE network booting you will need to install and configure your own DHCP server. Fortunately, there's an excellent Linux tool that also includes DNS capabilities, which makes it an ideal solution for network booting. A DNS server is required here because we need to add our own boot server as a preconfigured network address so that the PXE boot code knows where it should look to find further instructions.

From a standard Ubuntu installation, you need to add two packages - 'dnsmasq' and 'dnsmasq-base' - using the Synaptic package manager. The dnsmasq server is designed specifically for small networks such as those found at home, but it can scale to serve around 1,000 clients. It has built-in support for network booting devices and it is simple to configure, unlike most other DNS servers.

DHCP Configuration

The configuration of dnsmasq is accomplished by editing the '/etc/dnsmasq.conf' file after installing the two packages. You'll need to open this with a text editor using system administrator privileges - to do this we suggest typing either 'sudo nano /etc/dnsmasq.conf' or 'sudo gedit' into the command line. Next add these four lines to the bottom of the file, changing the IP addresses to suit your network's configuration:

dhcp-range=192.168.198.130, 92.168.198.140,12h

dhcp-boot=pxelinux.0,192.168. 198.128

dhcp-option=3,192.168.198.2

dhcp-option=6,192.168.198.2

The first line of this text holds the range of addresses that you want to be served by the DHCP server. In this case, our network is 192.168.198.0 and we've assigned DHCP addresses between 130 and 140 for dynamically allocating clients. The second line requires you to add the IP address of the machine you're using to be the server; normally this machine is the one you're installing the server onto. This entry tells the client to look for 'pxelinux.0' as part of the PXE boot routine in the direction of your IP address. Ours is 192.168.198.128. The last two lines take the IP address of your gateway, which is 192.168.198.2 in this example. If you're having trouble finding the correct numbers, try typing 'ifconfig eth0 | grep inet' on the command line. This will list your server's current network address. Once you have it, you can enter this on the second line of our configuration. For the gateway's address, type 'route'. This will display the IP addresses taken by packets as they traverse your network and the 'default' listing will show an IP address for your gateway, which you can use on the last two lines of the dnsmasq configuration file.

With the configuration complete, you can now kick the dnsmasq server into life by using the following console command: 'sudo /etc/init.d/dnsmasq restart'.

Install the TFTP Server

Since the client machine has been given an IP address and informed that it needs to grab 'pxelinux', the next step is to provide those files using a Trivial File Transfer Protocol (TFTP) server, which is a simple version of the more commonly used FTP protocol. Its simplicity means that it's perfect for low memory situations - exactly what PXE code hiding on a diminutive BIOS needs. The most suitable Linux TFTP server is called 'aTFTP' and this can be installed by searching for the package named 'atftp' in Synaptic. After you've installed it, you'll need to find and edit the configuration file, located in '/etc/default/atftpd.conf'.

You just need to change the 'USE_INETD=true' option on the first line of the configuration file to 'false' and make sure that the last parameter in the 'OPTIONS' string points to a usable location on your file system. It's going to store the boot files needed by PXE and by default this points to '/var/lib/tftpboot' - a directory that currently doesn't exist. Other distributions use '/tftpboot' as a standard location, but it doesn't really matter which one you choose as long as you use the same location to store the PXE boot files, which we'll move on to create in the next step.

If there's a firewall between your PXE booting client and the server running TFTP, you need to make sure that UDP port 69 is open and accessible to the client. The Uncomplicated Firewall that's enabled in most Ubuntu installations can be disabled by typing in the command 'sudo ufw disable', but only execute this if your machine has another firewall to protect itself and you're absolutely sure that there's not going to be any added security risk to your system. With the configuration complete, you can start the aTFTP server by typing 'sudo/etc/init.d/atftpd restart'.

Create the boot files

Now that we've got both the servers that PXE requires to negotiate a connection and find the files it needs to boot, the next task to accomplish is to make those files available. There are many different sources and methods for creating and adding these files, and which one you choose is entirely dependent on what you want your network-booted operating system to do. You could boot to a completely functional Live CD system, for example, but we're opting for a networked Ubuntu installation instead. Earlier versions of Ubuntu included the PXE boot files on the distribution CD, but space restrictions have meant that these files were offloaded into an online repository. Visit www.tinyurl.com/5waq63 to get hold of this file and then place it in the directory that aTFTP is expecting to find it in, which is '/var/lib/tftpboot' by default.

The netboot file comes as a 'tar.gz' archive. This can be opened by a file manager, but for best results, just type 'tar xvf netboot.tar.gz' into the command line. All the files and directories will then be un-archived into the current directory, as required. These files will include the 'pxelinux.0' file that we pointed the dnsmasq configuration file towards earlier. A PXE boot menu is configured through the 'pxelinux.cfg' directory, which contains a file that should look familiar if you've ever edited the Grub bootloader. It includes an entry for each boot menu - which contains the location of the boot kernel and RAM disk - as well as where to find the root file system. It's this file that you'll need to edit if you add your own PXE installations. The 'ubuntu-installer' directory is a cut-down version of the Ubuntu install CD, restricting itself to text and online repositories in order to keep its use of space and network bandwidth to a minimum.

Boot the client

You're now at the stage of the process where a network boot should work, but before you try everything you've done here out, it's worth checking the server to make sure everything is set-up correctly first. Specifically, check that both the dnsmasq and atftp servers are running and that they're awaiting a connection. This can be done using the 'netstat -nulp' command followed by '| grep', which is used to filter the output to the specific server name you require information on. If you were to type in 'netstat -nulp | grep dnsmasq', for instance, netstat would output the three lines that report on the current status of the dnsmasq server - if it's working, that is. If not, restart the server manually, follwing the same proceedure that we used in step two. Repeat the same netstat process for checking the status of the atftp server. If you find that restarting either service still doesn't produce any usable netstat output, it's likely that there's a syntax error in that server's configuration file. You should be able to learn more information about the problem from the system logs: try looking in '/var/log/messages'.

Once you're happy that both services are running, and that any firewall you've got installed isn't getting in the way of the process, it's time to start your client PXE booting machine. If there's no other bootable device on this machine then the PXE booting should automatically kick in. If not, you'll need to enter the BIOS and manually and change the boot order on that machine, pushing the network booting capability to the top of the priority list. The majority of BIOS configuration menus can be entered by pressing either [F2] or [Delete] when the BIOS first appears on your screen. Failing that, some BIOSes will provide a network booting hotkey (usually [F12]) or a manual boot selection menu (usually [F8]). When the network booting attempt is successful, you will see your network device first try to grab an IP address from your new DHCP server before taking the boot file we've placed on the aTFTP server. All of this should happen very quickly. You'll then be presented with the PXE boot menu created by our boot file configuration and from that point onward, installing Ubuntu across the network is a fairly simple matter of following the on-screen prompts until completion.

What no PXE-Enabled BIOS?

If you haven't got a PXE-enabled BIOS then you won't be able to boot off a network device without some form of boot media, which brings you firmly into the world of thin-client computing. Unlike booting from PXE, a thin client needs a rudimentary operating system running off some form of local storage device. The most popular trick is to use a low-capacity USB stick with a very minimal Linux installation to create a simple Linux environment that then boots from a fatter server located on the network. In the past, building a workable Linux distribution onto a USB stick has been problematic, but the latest release of Fedora includes a utility that will create a bootable USB stick with just a couple of clicks on a GUI. There's even an open-source project called UNetBootin that you can use from almost any operating system.

The features you should include on the USB installation are dependent on how you want to use your client. You may simply want to access a remote desktop on a VNC server, for example. For this purpose, all you'll need is the TightVNC client package and a working X Windows configuration. A more ambitious thin client would quickly mount an NFS shared drive to act as the home directory and application server for the client. This has the advantage of letting the hardware run at its native speed, rather than being limited by the bottleneck of a remote desktop connection. Coaxing a workable configuration from NFS can be tricky, though.

Boot into a Live CD

Using PXE network booting to start an Ubuntu installation without any installation media on the client machine is a convenient example of network booting, because the distribution supplies the netboot package. The netboot archive includes all of the binaries and configuration files necessary for the PXE client to boot and that setup isn't trivial to build manually. However, the netboot package is a great place to start if you want to extend this configuration and boot an Ubuntu Live CD. You can even boot a different Linux distribution entirely, although you'll need to stick to a Live CD since these are the only distributions capable of initialising hardware on-the-fly rather than through an installation.

The first step is to download an ISO of the desktop distribution. You then need to copy the contents to a directory on your Linux server and share the contents of that directory using the Network File System. This can be installed through Synaptic, but you'll need to edit the '/etc/exports' file to add the ISO directory you created and copied files to. After this, edit the netboot configuration, copying 'vmlinuz' and 'initrd.gz' from the 'casper' directory to somewhere within the path of the aTFTP server. We used '/var/lib/tftpboot/hardy'. Finally, edit the netboot configuration file and add the following, changing the paths and IP address.

LABEL Hardy-Heron kernel hardy/vmlinuz append boot=casper

netboot=nfs

nfsroot=192.168.198.128:/path/to/nfs/share initrd=hardy/initrd.gz