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, and you intend to use kernel space NFS root (see next two sections), 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.
Recent advances in the Linux kernel (2.4 and above) have made the use of an initrd that does user space autoconfiguration and mounting of a NFS root filesystem, followed by a pivot_root, a more flexible alternative to kernel autoconfiguration and mounting of a NFS root filesystem. 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 will be the recommended way to start up a diskless system.
Until I have time to write detailed instructions on how to construct the initrd, I refer you to the LTSP distribution which uses this technique. Mknbi supports initrds, see the ramdisk argument of mknbi-linux. The Linux kernel documentation describes the 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. If the initrd mounts a NFS root filesystem then it should still have all the needed structure as explained in the next section.
Initrds can also be used for mounting other network filesystems instead of NFS root. Some applications could even run totally out of initrd, e.g. Floppy Firewall, provided you have the memory, of course.
The NFS root filesystem for the diskless computer is typically placed under /tftpboot/<name of computer>, provided your DHCP server sends the hostname in the reply, otherwise it may be under /tftpboot/<ip address of computer>. This NFS root 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 made a copy of the necessary files from an existing Linux filesystem on the server and modify some key files appropriately. You can find a rather dated description in my tutorial and some shell scripts to copy the files. Since distributions have moved on since I wrote the scripts, you will have to adapt it to your needs. 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.
This tutorial does not cover all possible ways of setting up a diskless client's initial filesystem. The initrd method and the NFS root 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.
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.
There is also the follow-on project ENBD, the Enhanced Network Block Driver. I have no experience with this for swapping. Comments welcome.