Next Previous Contents

5. Testing the network booting

Now when you start up Etherboot, it should obtain an IP address and print out what it received. If you do not get this to work, turn on debugging in bootpd and see if any query was received. You may also wish to use the tcpdump or ethereal utilities to watch the network for bootp packets (port bootps). If not, check your network hardware (cables, etc). If a query was received, check if bootpd/dhcpd was able to give an answer. If not, then the Ethernet address was not found in /etc/bootptab or /etc/dhcp.conf. If a reply was sent, then only faulty hardware or a bug in Etherboot would prevent it being received by Etherboot.

Assuming an IP address was received, the next thing Etherboot tries to do is load a file using tftp. Check your system logs to see if a tftp daemon was started up and a file requested. Generally if you run tftpd under tcpwrapper security, a log entry will be generated. If not, it could be a path problem or file permission problem (the file needs to be readable by tftpd). Another problem could be that tftpd needs to reverse map the IP address to a name for security checking, and you don't have the client's details in /etc/hosts or in DNS, or your tcpwrapper config files (/etc/hosts.deny, /etc/hosts/allow) do not allow the access. Fix the problem.

After the tagged image is loaded, Etherboot will jump to it. If it crashes here, check that the image is a tagged image. If it executes and stops at the point where it's trying to mount the NFS root, then you need to check that you have the "root on NFS" option compiled in and that you have compiled in the network card driver.

5.1 Setting up a NFS root filesystem

Now you need to set up a NFS root filesystem for the diskless computer. Typically this is under /tftpboot/<ip address of computer>. In 2.1 and higher kernels, this should be /tftpboot/<name of computer in bootptab>. This needs to contain a complete root filesystem that will make the kernel boot happily. This means, for most kernels, it should contain /dev, /proc, /etc, /sbin, /bin, /tmp and /var. The details vary from distribution to distribution. Once you have got the initial filesystem mounted, you can mount additional network filesystems such as /usr or /opt to give you a full execution environment.

See the FAQ section for various methods of constructing a NFS root filesystem. There is no one true method. In the method I use I was lazy so I just make a copy of the necessary files from an existing Linux filesystem on the server and modify some key files appropriately. You can find a description in my tutorial and some shell scripts to copy the files. Since the amount of disk space needed is relatively small in these days of large disks, I don't bother to throw out things that may not be needed.

One thing to be aware of is that when you host the root filesystem on a NFS server that is not Linux, the major and minor numbers of device files will be different from what Linux is expecting, so the init process will probably break just after it mounts the root NFS, maybe when it tries to open the console device. You must create the root filesystem so that it is Linux compatible, even though it is hosted on a different Unix. One way might be to use cpio to capture a Linux root FS and then to unpack on the target Unix system.

Warning: Do not attempt to reuse the root filesystem of your server, whether by exporting it directly or by making hard links (symbolic links will not work). First of all, the configuration files will contain information pertaining to the server, not the client, so your client will get the wrong information. Secondly, this is a security risk. NFS is already not totally safe, but this way you are directly exposing your server root to clients. Even if you make hard links, the clients could (maliciously or accidentally) overwrite key binaries, making the server unusable. Don't try to save a few megabytes of disk space this way. You can however share some directories between clients, typically /sbin, /bin and /lib. The sample scripts in the tutorial show you how.

The root filesystem should be exported rw and no_root_squash because the various processes need to be root and need to write to log files in the root partition. You may wish to export /usr and /home filesystems to the diskless computer also. These do not need no_root_squash permission, and in the case of /usr probably only needs to be ro. Otherwise you will be opening up a security hole for hacking the server from the client. Be aware that practically all Linux distributions have a few "bugs" relating to symlinks and so forth for diskless booting. These are mentioned in the tutorial.

5.2 Initial ramdisk

It is possible to use initial ramdisk (initrd) in addition to, or in place of an NFS root. See the ramdisk argument of mknbi-linux. You will also need to read the Linux kernel documentation to see what extra arguments should be passed to the kernel to make it use an initrd, and how to arrange the initrd so that the startup script within it is called when it's mounted.

Initrds are useful for loading modules before the NFS root is mounted, or to use some other network filesystem instead of NFS root, for example. Some applications could even run totally out of initrd, e.g. Floppy Firewall, provided you have the memory, of course. Also postings on the kernel mailing lists indicate that at some point in the future, kernel level autoconfiguration (BOOTP/DHCP from the kernel) may be removed from the Linux kernel and initrds may be the way to start up a diskless system that can acquire an identity using a userland DHCP client program.

5.3 Other filesystem setups

This tutorial does not cover all possible ways of setting up a diskless client's initial filesystem. The NFS root method and the initrd method described above are two ways. You could even mount a conventional hard disk. Why would you want to boot "diskless" if you have a hard disk? Reasons might be: you do not wish to adminster the local disk; you want the assurance that a system is running a kernel from a central server; or you like the speed of network booting. Network booting is one technique in a toolbox. Techniques can be combined to do what you want. If you are interested in running the diskless client as an X-terminal, a very common use, you may wish to investigate the Linux Terminal Server Project.

5.4 Swap over NFS

Swap over NFS can be arranged but you have to patch the kernel source. See here.

Be aware that opinions are divided on NFS swap. Some people think it's a bad thing because it just kills the network if you have lots of diskless computers and that you shouldn't be running into a swap regime on a diskless computer anyway. Some other people like having a bit of insurance.

Also have a look at the NBD Network Block Device web page for swapping over that. This requires a 2.1 or 2.2 kernel.


Next Previous Contents