See also LinuxInstallationNotes
I initially used LTSP, but ran into issues - it would boot, mount its NFS root, but couldn't set up a working /tmp directory and so nothing would start. I never bothered fixing it as I came across PXES which does what I want, and uses a ramdisk instead. --
DanielLawson
Once you have a PXE enabled card (either via PXE on disk, or through a boot rom) and have tftp-hpa and dhcp3 installed on your server, read on.
Grab the 
SysLinux package, and put the pxelinux binary (normally called something linux pxelinux.0 under your tftproot somewhere. PXELinux is just like syslinux in terms of its config files, however it places them under a directory called pxelinux.cfg relative to the position of pxelinux.0
For example, when I set up PXES I placed all PXES related stuff into /tftpboot/pxes/ (which has the tftp path of just /pxes/)
You also need to let dhcp know which filename to pass on for pxe booting clients. Its sufficient to put 'filename "....";' in a static lease section of your dhcp.conf: eg
host sulpher {
hardware ethernet 00:60:97:59:e1:d6; fixed-address sulpher.element.meta.net.nz; filename "pxes/pxelinux.0"; vendor-encapsulated-options 01:04:00:00:00:00:ff;
}
This associates the specified MAC address with the fixed IP address of sulpher.element.meta.net.nz, and tells it to boot "pxes/pxelinux.0".
The vendor-encapsulated-options is a string that some (but not all) PXE clients require before they boot. the given string is the minimum legal offering. More information can be found in 
RFC:1048 and/or RFC:1497.
In /tftpboot/pxes/pxelinux.cfg/ I have a default configuration file called 'default'. It contains
default pxes prompt 1 timeout 600 display pxes.msg F1 pxes.msg
label pxes
kernel vmlinuz-2.4.20-4pxes.i586 append ramdisk_size=20480 console=null initrd=pxes-0.5.1.initrd root=/dev/ram
This means it will boot the kernel vmlinuz-2.4.20-4pxes.i586 with an initial ramdisk_size of 20 MB (needed for the pxes initrd), specifies that the rootfs is mounted as /dev/ram (an initrd), and also gives it the filename of an initrd to load (pxes-0.5.1.initrd, which is also placed in /tftpboot/pxes)
From what I've seen of PXE and Etherboot booting, PXE works much better. That is to say, I've yet to get a working etherboot system running, but PXE goes just fine. PXE can start a bootloader - such as PXELinux or GRUB. Therefore it would be possible to specify a bootloader which defaults to booting off /dev/hda, but if you tell it otherwise at boottime it boots off the network
Something I can speak with experience on here is that sometimes diskless workstations can be more trouble than they are worth. Problems I had were:
For the price of a 20GB HDD (100$) these problems disappear. The only issue you have to worry about now is power failure corrupting the drive. With read only and journalling file systems this is less of a problem than it might seem.
These days you can put a >1GHz, 256MB, 20GB workstation together for 700NZD (minus screen). At these prices thin clients make less and less sense. All the administrative benefits of diskless systems can be achived with NFS /home (et al), automount, LDAP, and automatic/scripted package management systems like the RedHat Network, Ximian RedCarpet? Enterprise, or some homegrown system.
This is just my opinion though based on my past experience.
We have a grunty (dual Athlon 1800 MP) server we use for running our desktops on. Until recently, we've used HP Vectra (P2-233) as the clients, with whatever disks were in there, and had a image dd'd onto them. This was fine, in general, except the machines were slowly dying, and maintenance became an issue. Our LazySystemAdministrator wasn't lazy enough to write a decent set of automated update / modification scripts for the 12 machines we used. However, we still saved a lot of money - the price of our server was far less than we would have spent putting decent machines at everyones desktop.
Recently, we upgraded to some nice Compaq Deskpro's (P3-550/ 128 MB ram, 10 GB disk, EEPro 100, Matrox G200's etc). We pulled the harddisks out, and setup NFSRoot linux using the 'diskless' package described elsewhere in the wiki. Maintenance is dead easy - the LazySystemAdministrator chroots to the NFSRoot path, and installs the package. If its the sort of package that requires something in /etc to be updated, then he runs a script that updates all the images at once.
Benefits? Our labs are silent. Really silent. No disk noises. The machines are in good condition, so the PSU, case and CPU fans are also dead quiet. Its great. We've also eliminated dodgy disks as a potential problem with our thin clients. Also, we got hold of 15 machines for very little - cheaper than the price spec'd above, and we know they are good quality components. The money we save on desktops we can spend on dropping a dual Opteron server in instead, or on better displays (like 17" TFTs, which we are considering) and keyboards/mice. They are easy to maintain, they do local auth via pam_ldap off our main server, so we all have local accounts as well, if we wanted to use them, and the administrative overhead has dropped immensely.
5 pages link to DisklessWorkstationNotes:
