Network Boot and Exotic Root HOWTO

Brieuc Jeunhomme



Logilab S.A.

Revision History
Revision 0.32002-04-28Revised by: bej
Many feedback inclusions, added links to several projects
Revision 0.2.22001-12-08Revised by: dcm
Licensed GFDL
Revision 0.2.12001-05-21Revised by: logilab
Fixed bibliography and artheader
Revision 0.22001-05-19Revised by: bej
Many improvements and included Ken Yap's feedback.
Revision 0.1.12001-04-09Revised by: logilab
First public draft.
Revision 0.12000-12-09Revised by: bej
Initial draft.

Table of Contents
1. Introduction
1.1. What is this all about?
1.2. Thanks
1.3. Diskless booting advocacy
1.4. Requirements
1.5. Acknowledgements and related documentation
1.6. Feedback
1.7. Copyright Information
2. Diskless booting operation overview
2.1. Obtaining IP parameters
2.2. Loading the kernel
2.3. Mounting the root filesystem
2.4. Terminating the boot process
3. Building the kernel
3.1. When the root filesystem is on a ramdisk
4. Daemons setup
4.1. NFS daemon
4.2. BOOTP daemon
4.3. TFTP
5. Clients setup, creation of the root filesystem
5.1. Creating the first files and directories
5.2. The /var and /etc directories
5.3. Last details
5.4. Trial...
5.5. And Error!
6. Several ways of obtaining the kernel
6.1. BOOTP or DHCP capable NICs
6.2. Kernel on a local floppy or hard drive
6.3. Bootloader without kernel on a local floppy or hard drive
6.4. Creating ROMs for the clients
6.5. Local CDROM
7. How to create diskless MS-Windows stations?
8. Troubleshooting, tips, tricks, and useful links
8.1. Transparently handling workstations'specific files
8.2. Reducing diskless workstations'memory usage
8.3. Swapping over NFS
8.4. Swapping over network block devices
8.5. Getting rid of error messages about /etc/mtab or unmounted directories on shutdown
8.6. Installing new packages on workstations
A. Non-Volatile Memory chips
B. Determining the size and speed of EPROMs to plug in a NIC
C. Companies selling diskless computers

1. Introduction

1.2. Thanks

Logilab sponsored this HOWTO. Check their website for new versions of this document. I also thank the etherboot, netboot, plume and linux terminal server project developers and webmasters, who made it really possible to boot a Linux worstation over a network.

Very special thanks go to Ken Yap, member of the etherboot project, whose comments greatly helped to improve the quality of this document.

I also thank Jerome Warnier, main developer of the plume project, Pierre Mondié, Kyle Bateman, Peter T. Breuer, Charles Howes, and Thomas Marteau for their comments and contributions.

1.3. Diskless booting advocacy

1.3.2. Advantages of diskless computers

Diskless computers will become more and more popular in the next years. They will be very successful because of the availability of very high-speed network cards at very low prices. Today 100 Megabit per second (12.5 MB per sec transfer rate) network cards are common and in about 1 to 2 years 1000 MBit (125 MB per sec transfer rate) network cards will become very cheap and will be the standard.

In near future, monitor manufacturers will place the CPU, NIC, RAM right inside the monitor to form a diskless computer. This eliminates the diskless computer box and saves space. The monitor will have outlet for mouse, keyboard, network RJ45 and power supply.

The following are benefits of using diskless computers:

1.4. Requirements

1.4.1. Hardware requirements

The most important thing in order to boot from network is to have an equipment which enables the stations to execute a bootloader, which will get the kernel on the server and launch it. Another solution is to use a device which will load a local kernel, which will mount the root filesystem on the server. There are several solutions: home made eproms containing the first instructions to execute when booting the station, boot with BOOTP/DHCP capable network adapters, or a local floppy, a tiny hard drive, or a cdrom to load the kernel. Note that some vendors also sell network booting capable stations: for instance, some Sun stations implement the BOOTP protocol.

Other hardware requirements depend on the configuration you plan to use: on some sites, every application run by the stations is executed remotely on the server, this implies that a very high-performance server is required, but only light stations are required: depending on what they will have to do, 80486 CPUs with 16 MB of RAM may be enough. On the other side, if application programs are really executed locally on the stations, the requirements for the stations depend completely on these applications. In that case, only a small server is required. A 80486 CPU with 32 MB of RAM will be sufficient for a small number of stations, but more memory will be necessary in very large installations with hundreds or thousands of machines. Note the server's CPU does not really matter for such an installation.

2. Diskless booting operation overview

Hey, you think it's time to start with the real stuff, right? Here we go.

3. Building the kernel

First of all, build a kernel for the clients. I suggest you build it on the server, this will be useful later for modules installation. Use a zImage to reduce its size. Include everything you need, but try to use as many modules as possible, because many BOOTP client implementations are unable to load very large kernels (at least on intel x86 architectures). Also include iramdisk support, NFS protocol support, root filesystem on NFS support, support for your NIC, kernel level IP autoconfiguration via BOOTP; do not use modules for these! Then, if you plan to use the same remote root filesystem for several clients, add support for ext2fs or some other filesystem and ramdisks (16 Megabytes ramdisks will do fine on most systems). You can then modify the kernel arguments as usual (see the BootPrompt-HOWTO for information on this topic), but you will have another opportunity to modify kernel arguments later.

Then, if you plan to use BOOTP, copy the kernel zImage on the server. We will assume it resides in /tftpboot, its name is zImage, the name of the image you want to create from this zImage for BOOTP operation is kernel, and the nfs root filesystem will reside in /nfsroot.

Issue the following commands on the server (the mknbi package should be installed):
      # cd /tftpboot
      # chmod 0555 zImage
      # chown root:root zImage
      # mknbi-linux zImage --output=kernel --rootdir=/nfsroot

If you are using LanWorks EPROMs, also issue the following commands (you need the imggen utility):
      # mv -f kernel tmpkernel
      # imggen -a tmpkernel kernel
      # rm -f tmpkernel

Your kernel is ready for BOOTP/DHCP/ROM operation. You of course don't need to do this if you plan to use a local drive.

3.1. When the root filesystem is on a ramdisk

It is possible to use a ramdisk for the root filesystem. In this case, the command used to modify the kernel's binary image is slightly different. If you choose to do so, you have to enable support for initial ramdisk (initrd), and you probably don't need NFS support, or you probably can compile it as a module.

Its time to give an overview of what happens when you use initrd. The full documentation for this is in your kernel source tree, in the Documentation/initrd.txt file. I have to warn you I did never try this :).

When initrd is enabled, the boot loader first loads the kernel and the inital ramdisk into memory. Then, the ramdisk is mounted read-write as root filesystem. The kernel looks for a /linuxrc file (a binary executable or a script beginning with #!). When /linuxrc terminates, the traditionnal root filesystem is mounted as /, and the usual boot sequence is performed. So, if you want to run your box entirely from ramdisk, you just have to create a link from /linuxrc to /sbin/init, or to write there a shell script to perform any action you like, and then shutdown the computer.

After the kernel has been compiled, you have to build a root filesystem for your installation. This is explained in the "Clients setup, creation of the root filesystem" section. I will assume here that this is already done and that the root filesystem for your clients temporarily resides in /tmp/rootfs. You now have to create a ramdisk image. A simple way to do so is the following:

What was toled above about LanWorks PROMs is also true if you use initrd.

Then, you have to modify the kernel image, as was told above, with the mknbi-linux utility. Its invocation will slightly differ from the above, though (I will assume your just compiled zImage resides in /tftpboot/zImage and your initial ramdisk image resides in /tmp/initrd):
        # cd /tftpboot
        # chmod 0555 zImage
        # chown root:root zImage
	# rdev zImage /dev/ram0
        # mknbi-linux zImage --output=kernel --rootdir=/dev/ram0 /tmp/initrd

4. Daemons setup

4.2. BOOTP daemon

I assume you have installed the bootpd package. The default configuration file is /etc/bootptab, and its syntax is detailed in the bootptab manpage. Let's create it.

First, open as root your favourite text editor. It is vim. Yes, it is. If it is not, it has to become. Now, enter the following lines (they are the default attributes). All the attributes you give here and do not override in a machine's specific attributes list will be given to clients):
                :sm=your subnet mask\
                :ds=the IP address of your DNS server\
                :dn=your domain name\
                :gw=the IP address of your gateway\
                :sa=the IP address of the TFTP server\
                :bf=path to find the kernel image\
                :rp=path of the root filesystem\
Of course, not all these parameters are required, this depends on your network configuration and BOOTP implementations, but these will work in most cases.

Then, add an entry per client in your network. An entry should look like this:
        dns of the client\
                :ha=MAC address of the client\
                :ip=IP address of the client
The MAC address above is the hexadecimal hardware address of the client without the ':' characters.

Here is a sample /etc/bootptab file:



Then, run the bootpd daemon with the bootpd -s command (it is also a good idea to add it to your startup scripts), or add the following line to your /etc/inetd.conf:
        bootps dgram udp wait root /usr/sbin/tcpd bootpd -i -t 120

If you want to test the BOOTP server, add an entry to your /etc/bootptab and use the bootptest program.

5. Clients setup, creation of the root filesystem

Tired? No you're not. Remember you're a hero. Here comes the tricky part. We will (err... you will) build the client's root filesystem. This shouldn't be very hard, but you probably will have to use trial and error.

The simplest way to create a root filesystem is to use an already working filesystem and customize it for the needs of diskless operation. Of course, you can also build one by hand (like in the good old times) if you like:=), but I won't explain this here.

5.1. Creating the first files and directories

First, cd to your future station's root directory. You can safely create the future /home directory with the mkdir command, or by copying it from anywhere you want (you can use cp -a to do a recursive copy preserving owners, groups, symlinks, and permissions). Same thing for the future /mnt, /root, /tmp (don't forget to chmod 0 it, this is only a mount point for the actual /tmp we will use, because each workstation needs to have its own /tmp). Then, copy some existing /bin, /sbin, /boot, and /usr into this future root directory (use cp -a). You can create the /proc directory with mkdir, and chmod 0 it. Note some applications need write access to their user's home directory.

The /lib directory can be safely copied from somewhere else, but you will have to put the proper modules in it. To do so, use the following commands (assuming you have compiled the kernel for your clients on the server in /usr/src/linux, and the root filesystem will reside in /nfsroot):
        # cd /usr/src/linux
        # make modules_install INSTALL_MOD_PATH=/nfsroot

Don't forget to put the file in /nfsroot/boot. A first problem we will have to fix is that, depending on your configuration, your system may try to run fsck on the root filesystem at boot time. It shouldn't if there is no hard drive in the box. Most distributions will also skip this fsck if they find a fastboot file in the root directory. So, issue the following commands if you do not plan to mount any hard drive:
        # cd /nfsroot
        # touch fastboot
        # chmod 0 fastboot
Another method is tell fsck that checking a NFS filesystem always succeeds:
      # cd /nfsroot/sbin
      # ln -s ../bin/true fsck.nfs

The /dev directory can also be safely copied from another place into /nfsroot. But permissions and symlinks have to be preserved, so use cp -a. Another solution is to use kernel 2.2.x devfs feature, which will reduce memory consumption and improve performance, but the drawback of this method is that all symlinks created in /dev will be lost. The point to remember is that each workstation needs to have its own /dev, so you will have to copy it on a ramdisk if you plan to use several clients and not to use devfs.

5.2. The /var and /etc directories

We will use ramdisks for these directories, because each client needs to have its own one. But we still need them at the beginning to create their standard structure. Note you are not required to do so if you use a single client. So copy these directories (cp -a) from another place into /nfsroot. Then you can make some cleanup in /var: you can remove everything in /nfsroot/var/log and /nfsroot/var/run. You also probably can remove everything in /nfsroot/var/spool/mail, if you plan to export it via NFS. You also will have to remove the files containing host specific information in /nfsroot/etc to build them on the fly during the boot process.

The startup scripts will have to be customized in order to mount some parts of the filesystem: the /dev directory, if you don't use devfs, the /tmp, the /var, and the /etc directories. Here is some code which will achieve this:
        # this part only if you don't use devfs
        mke2fs -q -i 1024 /dev/ram0 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram0 /dev
        # this part for everyone
        mke2fs -q -i 1024 /dev/ram1 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram1 /tmp
        chmod 1777 /tmp
        cp -a /etc /tmp
        mke2fs -q -i 1024 /dev/ram2 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram2 /etc
        find /tmp/etc -maxdepth 1 -exec cp -a '{}' /etc ';'
        mount -f -t ext2 -o rw,suid,dev,exec, \
            async,nocheck,remount /dev/ram2 /etc
        mount -f -o remount /
        cp -a /var /tmp
        mke2fs -q -i 1024 /dev/ram3 16384
        mount -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram3 /var
        find /tmp/var -maxdepth 1 -exec cp -a '{}' /var ';'

If you plan to use more than a single client, you will also have to change files dynamically at boot time in /etc: the files which contain the IP and hostname of the client. These files depend on your distribution, but you will easily find them with a few greps. Just remove client-specific information from them, and add code into your startup files to generate this information again at boot time but only once the new /etc has been mounted on the ramdisk! A way to obtain your IP address and hostname at bootup is the following (if you have the bootpc package installed on the workstations'filesystem):
        IPADDR="$(bootpc | awk '/IPADDR/ \
                                  print substr(s,RSTART,RLENGTH)

        HOST="$(bootpc | awk '/HOSTNAME/ \
                                print substr(s,RSTART,RLENGTH)

        DOMAIN="$(bootpc | awk '/DOMAIN/ \
                                  print substr(s,RSTART,RLENGTH)
This is a complicated solution, but I guess it should work on most sites. The IP address can alternatively be obtained with the output of ifconfig and the hostname can be obtained from the output of the host command, but this is not portable, because these outputs differ from system to system depending on the distribution you are using, and the locales settings.

Then, the hostname should be set with the hostname $HOSTNAME command. When this is done, it is time to generate on the fly the configuration files which contain the IP address or the hostname of the client.

5.3. Last details

Now, it's time to do the fine tuning of the client. As /var will be mounted on a ramdisk (unless you have a single client), you will have to send the logs to a logs server if you want to keep them. One way to do that is to delete the /nfsroot/etc/syslog.conf file and replacing it by the following file (see man syslog.conf for details):
        *.*     /dev/tty12
        *.*     @dns or IP of the logs server
If you do so, the logs server will have to run syslogd with the -r option (see the syslogd manual page).

If you use logrotate and you have done the preceding operation, you should replace the logrotate configuration file (/etc/logrotate.conf on most boxes) by an empty file:
        # rm -f /etc/logrotate.conf
        # touch /etc/logrotate.conf
If you don't use it, just remove the logs rotation scripts from the crontab, and as you no longer have log files in /var/log, put an exit 0 at the beginning of your logs rotation scripts.

In the /nfsroot/etc/fstab file, remove anything related to the hard drive, floppy disk reader, or cdrom if you don't have such devices on your workstations. Add an entry for the /var/spool/mail directory, which should be exported by the server through NFS or any other network filesystem. You probably also want to put an entry for the /home directory in this file.

You can also comment the lines running newaliases, activating swap, and running depmod -a and remove the /nfsroot/etc/mtab file. Comment out the line(s) removing /fastboot, /fsckoptions, and /forcefsck in your startup scripts. Also remove or comment any line in the startup scripts that would try to write on the root filesystem except for really necessary writes, which should all be redirected to some ramdisk location if you use several clients.

6. Several ways of obtaining the kernel

We have spoken so far about the client and server's configuration for operation after the BOOTP request has been issued by the client, but the first problem is that most computers are not able to behave as BOOTP clients by default. We will see in this section how to fix this.

6.4. Creating ROMs for the clients

Many network cards include a slot in which one can insert an EPROM with additional BIOS code. This enables one to add, for instance, BOOTP capabilities to the BI0S. To do so, you will first have to find how to enable the EPROM socket. You may need a jumper or a special software to do so. Some cards like the 3Com 905B have slots for EEPROMs which enable one to change the software in the EEPROM in place. In appendix, you'll find the information about EPROM and various types of memory chips.

For a list of EPROM burner manufacturers visit the Yahoo site and go to economy->company->Hardware->Peripherals->Device programmers or check out the old Diskless-HOWTO List of EPROM burner manufacturers section.

If you choose to create your own ROMS, you will have to load a BOOTP or DHCP capable software in the ROM, and then, you will be in the case of BOOTP or DHCP capable NICs described above.

You will also need to find the proper EPROM size and speed for your NIC. Some methods to do so are provided in appendix, because the NICs manufacturers often do not provide this information.

6.5. Local CDROM

This section was originally written by Hans de Goede for the Diskless-root-NFS-HOWTO. I modified it slightly in order to reflect some differences between this document and the Diskless-root-NFS-HOWTO.

Much of the above also goes for booting from cdrom. Why would one want to boot a machine from cdrom? Booting from cdrom is interesting everywhere one wants to run a very specific application, like a kiosk, a library database program or an internet cafe, and one doesn't have a network or a server to use a root over nfs setup.

6.5.1. Creating a test setup

Now that we know what we want to do and how, it's time to create a test setup:

6.5.2. Creating the CD

If you need more information than you can find below, please refer to the CD-Writing-HOWTO.

7. How to create diskless MS-Windows stations?

Since MS-Windows does not support diskless booting, a simple workaround is presented here: the solution is to use software like VMWare or its free alternative, plex86. Although the plex86 seems to have been abandonned, one can still boot certain versions of MS-Windows using this software. These enable MS-Windows to be executed transparently on the linux box.

8. Troubleshooting, tips, tricks, and useful links

8.3. Swapping over NFS

If your stations do not have enough memory and do not have local drives, you may want to swap over NFS. You have to be warned the cod eto do so is still under development and this method is generally quite slow. The full documentation for this can be found at

The first thing to do if you want to apply this solution is to patch your kernel (you need a kernel version 2.2 or above). First download the patch at the above url, and cd to /usr/src/linux. I assume the patch is in /usr/src/patch. Then issue the following command:
        # cat ../patch | patch -p1 -l -s
Then, compile your kernel normally and enable the Swapping via network sockets (EXPERIMENTAL) and Swapping via NFS (EXPERIMENTAL) options.

Then export a directory read-write and no_root_squash from the NFS server. Setup the clients so that they will mount it somewhere (say on /mnt/swap). It should be mounted with a rsize and wsize smaller than the page size used by the kernel (ie. 4 kilobytes on Intel architectures), otherwise your machine may run out of memory due to memory fragmentation; see the nfs manual page for details about rsize and wsize. Now, to create a 20 MB swap file, issue the following commands (which should be placed in the clients'initialization scripts):
        # dd if=/dev/zero of=/mnt/swap/swapfile bs=1k count=20480
	# mkswap /mnt/swap/swapfile
	# swapon /mnt/swap/swapfile
Of course, this was just for an example, because if you have several workstations, you will have to change the swap file name or directory, or all your workstations will use the same swap file for their swap...

Let's say a word about the drawbacks of NFS swapping: the first drawback is that it is generally slow, except you have specially fast network cards. Then, this possibility has not been very well tested yet. At last, this is not secure at all: anyone on the network is able to read the swapped data.

8.4. Swapping over network block devices

Although I have never tried it personally, I got report that the trick described below works, at least with recent kernels.

The general principle for swapping over network block devices is the same than to swap over NFS. The good point is you won't have to patch the kernel. But most of the same drawbacks also apply to the NBD method.

To create a 20 MB swap file, you will have to first create it on the server, export it to the client, and do an mkswap on the file. Note that the mkswap must be done on the server, because mkswap uses system calls which are not handled by NBD. Moreover, this command must be issued after the server starts exporting the file, because the data on the file may be destroyed when the server starts exporting it. If we assume the server's name is NBDserver, the client's name is NBDclient, and the TCP port used for the export is 1024, the commands to issue on the server are the following:
        # dd if=/dev/zero of=/swap/swapfile bs=1k count=20480
	# nbd-server NBDclient 1024 /swap/swapfile
	# mkswap /swap/swapfile
Now, the client should use the following command:
        # swapon /dev/nd0

Again, this was just to show the general principle. The files'names should also be dependant on the workstations'names or IPs.

Another solution to swap over a network block device is to create an ext2 filesystem on the NBD, then create a regular file on this filesystem, and at last, use mkswap and swapon to start swapping on this file. This second method method is closer to the swap over NFS method than the first solution.

A. Non-Volatile Memory chips

Here is a brief descriptions of memory chips and their types:

B. Determining the size and speed of EPROMs to plug in a NIC

This section comes from the etherboot project's documentation version 5.0. It provides tips to determine the size and speed of EPROMs to use with a particular NIC

The smallest EPROM that is accepted by network cards is an 8k EPROM (2764). 16 kB (27128) or 32 kB (27256) are the norm. Some cards will even go up to 64 kB EPROMs (27512). (You will often see a C after the 27, e.g. 27C256. This indicates a CMOS EPROM, which is equivalent to the non-C version and is a good thing because of lower power consumption.) You want to use the smallest EPROM you can so that you don't take up more of the upper memory area than needed as other extensions BIOSes may need the space. However you also want to get a good price for the EPROM. Currently the 32 kB and 64 kB EPROMs (27256 and 27512) seem to be the cheapest per unit. Smaller EPROMs appear to be more expensive because they are out of mainstream production.

If you cannot find out from the documentation what capacity of EPROM your card takes, for ISA NICs only, you could do it by trial and error. (PCI NICs do not enable the EPROM until the BIOS tells the NIC to.) Take a ROM with some data on it (say a character generator ROM) and plug it into the socket. Be careful not to use an extension BIOS for this test because it may be detected and activated and prevent you from booting your computer. Using the debug program under DOS, dump various regions of the memory space. Say you discover that you can see the data in a memory window from CC00:0 to CC00:3FFF (= 4000 hex = 16384 decimal locations). This indicates that a 16 kB EPROM is needed. However if you see an alias in parts of the memory space, say the region from CC00:0 to CC00:1FFF is duplicated in CC00:2000 to CC00:3FFF, then you have put an 8 kB EPROM into a 16 kB slot and you need to try a larger EPROM.

Note that because pinouts for 28 pin EPROMs are upward compatible after a fashion, you can probably use a larger capacity EPROM in a slot intended for a smaller one. The higher address lines will probably be held high so you will need to program the image in the upper half or upper quarter of the larger EPROM, as the case may be. However you should double check the voltages on the pins armed with data sheet and a meter because CMOS EPROMs don't like floating pins.

If the ROM is larger than the size of the image, for example, a 32 kB ROM containing a 16 kB image, then you can put the image in either half of the ROM. You will sometimes see advice to put two copies of the image in the ROM. This will work but is not recommended because the ROM will be activated twice if it's a legacy ROM and may not work at all if it's a PCI/PnP ROM. It is tolerated by Etherboot because the code checks to see if it's been activated already and the second activation will do nothing. The recommended method is to fill the unused half with blank data. All ones data is recommended because it is the natural state of the EPROM and involves less work for the PROM programmer. Here is a Unix command line that will generate 16384 bytes of 0xFF and combine it with a 16 kB ROM into a 32 kB image for your PROM programmer.
      # (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage

The speed of the EPROM needed depends on how it is connected to the computer bus. If the EPROM is directly connected to the computer bus, as in the case of many cheap NE2000 clones, then you will probably have to get an EPROM that is at least as fast as the ROMs used for the main BIOS. This is typically 120-150 ns. Some network cards mediate access to the EPROM via circuitry and this may insert wait states so that slower EPROMs can be used. Incidentally the slowness of the EPROM doesn't affect Etherboot execution speed much because Etherboot copies itself to RAM before executing. I'm told Netboot does the same thing.

If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities at The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site at You may alternatively use the objcopy utility, included in the binutils package:
      # objcopy --input-target binary --output-target ihex binary.file intelhex.file
      # objcopy --input-target ihex --output-target binary intelhex.file binary.file

Etherboot is believed to make PnP compliant ROMs for PCI NICs. A long-standing bug in the headers has been tracked down. However some faulty old BIOSes are out there so I have written a Perl script to switch the header around if necessary. You'll have to experiment with it both ways to find out which works. Or you could dump a ROM image that works (e.g. RPL, PXE ROM) using the Perl script The fields to look at are Device (base, sub, interface) Type. It should be 02 00 00, but some BIOSes want 00 00 02 due to ambiguity in the original specification.

C. Companies selling diskless computers

The original Diskless-HOWTO mentions the names of the following vendors of diskless computers:


[Diskless-HOWTO] Diskless-HOWTO.

[Diskless-root-NFS-HOWTO] Diskless-root-NFS-HOWTO.

[Bootdisk-HOWTO] Boot-disk-HOWTO.

[ltsp] linux terminal server project.

A set of utilities and documentation for diskless stations, based on the red hat distribution.

[plume] plume.

A beginning project whose goal is to provide a set of utilities for diskless stations and associated servers, based on the debian distribution.

[logilab] web site.

[PowerUp2Bash] From-PowerUp-to-bash-prompt-HOWTO.

[ThinClient] Thin-Client-HOWTO.

[cdwriting] CD-Writing-HOWTO.

[etb] etherboot project.

[VMWare] VMWare.

A non free virtual machine software.

[plex86] plex86.

A free virtual machine software.