home   articles   archive   forum   masthead  
Published at 3.10.2000
Author: Ronny Ziegler
Translator: Andy Ziegler
Languages: de nl
Printer printer-version
Support Us!

Diskless Linux

Network-booting A PC which completely boots via the network (i.e. without a floppy, CD-ROM or hard disk) sounds strange but can be achieved with some effort.


After turning on a PC, the BIOS tries to find a connected hard disk, CD-ROM or floppy which can be used to boot an OS.
If none of these components exist, you would not be able to start any OS in general.
However, there is a way it can even work without a local storage device. If the PC has a network card, the OS can be downloaded via the network from a properly configured server.

The question remains: What advantages does this kind of PC have?
In larger networks, the administration is clearly easier because the data are placed on a single server and therefore always accessible for the administrator in one place.
Should it be neccessary to upgrade the system (e.g. a security bug) or to install new software, it could all be done on the server. In a well-defined configuration of the server, it could be sufficient to install a single software package and it would be accessible for all components in the network.
The central storage of the data also allows a backup to be easily made.
However there are more interesting ways which could take advantage of this diskless PC.
For embedded systems, a network-booting PC could be a nice solution. Embedded systems are small PC systems which are not used as a local PC but take special work like a MP3 player or device controller.

An old PC can be transferred into a network-booting X terminal.
The advantage would be that you do not need a hard disk and all other moving parts (e.g. fan) if you constructed it properly. This PC would not produce disturbing noise and could even be used in the quiet living room.

Before the configuration will start please read the following

Warning !
This article describes a configuration which dramatically changes the functionality of the PC (Software as well as Hardware).
The use of all programs and hardware manuals is done at you own risk. All involved authors (i.e. authors of this article, linked articles as well as linked software) cannot be made responsible for damages which occur from the correct or incorrect use of these components (Text, Software, Hardware).

Now another warning in a complete different case.
The installation of a network-booting PC can be very difficult and in general it does not work at first, but only after a longer time of adjusting it. The documentation of the software is often poor. Therefore you should know about the software, hardware and network protocols which are involved and in particular do not give up.
Although we try to make this configuration manual as complete and easy to understand as we can, we are not able to report or even guess all possibilities that might happen.
Any hints, remarks and comments are welcome.


The OS is not saved on a local hard disk but downloaded via network thus the BIOS has to be able to execute the downloaded kernel.
The proper software which can do this task will be saved on a bootrom which will be placed on the network card.
Although commercial bootroms exist and can be bought, that isn't recommended because these bootroms are prepared for Novell networks and based on IPX instead of TCP/IP.
The package netboot (Homepage at http://www.han.de/~gero/netboot.html) offers software and a driver which creates a bootrom of your own (later more). This bootrom can be copied either to an empty Eprom or EEprom, or you put it on a floppy.
Unfortunately buying a writer for Eproms is too expensive (at least EUR 200,-) for a single Eprom and also the empty Eproms cost about EUR 10,- if you just buy a few. So you should build a floppy based boot disk which works as well as the bootrom on an Eprom.
A floppy drive should be placed inside and unreachable for the user.
The floppy will be used once for booting and will not decrease the performance of the system.


The latest version of netboot is recommended and should be downloaded from http://www.han.de/~gero/netboot.html (latest version is 0.8.1).
Decompress it with
  >> tar zxvf netboot-0.8.1.tar.gz -C /tmp/
Change to the created directory and start the configuration
  >> cd /tmp/netboot
  >> ./configure 
  >> make
  >> make install

It could be that the compilation aborts with an error message (that happened on our system). However this is not a tragedy because you do not need the parts which do not work.
If the command make stops with an error, change into the directory makerom and there execute make. The same procedure has to be done in the directories mknbi-linux and bootrom. Then you execute make install.

Next you create you bootrom. Therefore you need specific information about you network card.

card type:
The very cheap cards are often NE2000 cards.

Non-Plug&Play-cards offer jumper to set the interrupt, Plug&Play-cards configure themselves automatically. If you do not know the interrupt number often a program is provided with the card which reads it out.
If your card is already included in a running system you get this information during the boot process. The command

  cat /var/log/dmesg

allows to review the boot printout again. There you search for an entry like

  eth0: RealTek RTL-8029 found at 0x7400, IRQ 5, 00:E0:7D:82:5F:B6

Here you find the IRQ number and IO address (0x740 -- without the last zero). In addition you should write down the last 6 letters and numbers (the so called MAC address) in this line. This is the worldwide unique number which identifies your card.
If the network card was not compiled into the kernel but as a module you have to load the module (insmod eth0 or send a ping if it is loaded automatically) and then search for the network entry in cat /proc/interrupts and cat /proc/ioports.

After collecting all this information, you can start generating the bootrom:
Move into the sub-directory /tmp/netboot/makerom and there start

  >> ./makerom

You should get the output:

  Bootrom configuration program, Version 0.8.1 (netboot)
  Copyright (C) 1995-1998 G. Kuhlmann
  The following 3 kernels are available:
  (1)	kernel.bin
  (2)	kernelm.bin
  (3)	kernel86.bin
  Select the kernel you wish to use [1]: 

Here you choose the kernel which will be installed in the bootrom. You just need the minimal kernel, so you choose 2.

The following question

  Do you want the bootrom to look for boot drives (y/n) [no] ? 

should be answered which no if you wanted that the PC is going to be booted via network and does not own boot-able drives.

The next step asks for the network card which is mounted:

  The following 10 network drivers are available:
  (0)	user defined network driver
  (1)	3c501.com
  (2)	3c503.com
  (3)	3c509.com
  (4)	arcether.com
  (5)	dc21x4.com
  (6)	e100bpkt.com
  (7)	ne1000.com
  (8)	ne2000.com
  (9)	ne2100.com
  (10)	smc_wd.com
  Select the network driver you wish to use [0]: 

Here you choose your card (e.g. NE2000 card with 8). If you are going to have problems with the driver, you should get the latest one from the CRYNWR-driver-collection, type 0 and specify the absolute path to the downloaded driver.
Every driver requires the input of the interrupt, IO address and packet-interrupt-number. The order has to be <packet_int_no> <int_level> <io_addr>, an example:

  Enter command line arguments for network driver: 0x62 5 0x740

The specification of the packet-interrupt-number is only used internally in the bootrom and can be selected freely between 0x60 to 0x66, 0x68 to 0x6f and 0x78 to 0x7e.
Opinions vary on which value works best. Try a low and a high value if it did not work at first.
With Plug&Play-cards it can happen that a high IO address is chosen automatically. This could lead to problems with the netboot drivers.
Cards with jumpers are recommended because you keep the full control over the chosen resource and you do not depend on the randomly chosen Plug&Play settings.

The following three questions can be answered with "no":

  Do you want to use the ANSI display driver (y/n) [yes] ? no
  Do you want to use the packet driver debugger (y/n) [no] ? no
  Do you want to specify an additional program (y/n) [no] ? no

Next you have to decide which format has to be chosen for the bootrom. This depends on the interpreter of your Eprom writer or what kind of chip you are going to write on.
The floppy bootrom is created parallel with all choices.

  Available output file types (floppy image gets always created):
  (1)	Raw binary
  (2)	Image for programming a FlashCard across the network
  (3)	Intel hex
  (4)	Motorola hex
  (5)	Tektronix hex
  Select the format you wish to use [1]: 

So you finished this step. In the directory makerom you should find the file image.flo and another file Image.???, where the suffix depends on the chosen output type (the last question).

Now you create a bootdisk. Therefore you insert an empty floppy in your floppy drive (do not mount the disk) and execute the command

  >> dd if=image.flo of=/def/fd0

Thus you have your bootrom on floppy.

Server configuration

This part describes the configurations of the server from where the diskless PC gets its kernel and its file system.
There are many ways of booting a PC via network. Two older methods are RARP and BOOTP.
A DHCP server would offer much more flexibility if it was included in your distribution (otherwise you have to install it).
The time consumed by both installations is nearly the same, so you should choose DHCP.
The installation of the DHCP server depends on the distribution you use. With SuSE it is enough to change the configuration with YAST: just change


to yes and set your network device in


The option


should be set to no, except you exactly know what you are going to change.

Other distributions follow other installation methods. Sometimes you just have to link the DHCP init script in the proper run level. However you have to read the documentation of your distribution to get it started.

The configuration file of the DHCP server is placed at /etc/dhcpd.conf and should look like

File /etc/dhcpd.conf
         server-identifier server.netmag.de;
         option subnet-mask    ;
         option routers         ;
         option domain-name-servers;
         option domain-name              "netmag.de";
         use-host-decl-names on;
         shared-network WORKSTATIONS {
                 subnet netmask {
         group   {
                 use-host-decl-names             on;
                 host pc1 {
                         hardware ethernet       00:80:C8:D9:31:C1;
                         #                       ---MAC address
                         fixed-address ;
                         #                       ---assigned IP number
                         filename                "pc1/bootImage";
                         #	               ---Where the kernel is placed
                         #                          which has to be booted 
                         #                          (later more)
                 host pc2 {
                         hardware ethernet       00:E3:7F:86:3F:B9;
                         fixed-address ;
                         filename                "pc2/bootImage";

After re-starting the DHCP server (e.g. with SuSE)

  >> /sbin/init.d/dhcp restart
the new configuration file should have been re-read
  Shutting down service dhcpd                                       done
  Starting service dhcpd                                            done
In Red Hat based distributions the DHCP script is placed at /etc/rc.d/init.d/.

The configuration of the DHCP can be tested with the program bootpc which should be automatically installed if you used one of the main distributions (Homepage at http://www.damtp.cam.ac.uk/linux/bootpc/).
The call sends a broadcast into the network and waits for the answer of a server which supports bootp. On the prompt you get the reply:

  >> bootpc
Without any settings bootpc takes the MAC address of the current PC, but it can be re-set with the option --hwaddr to test the settings for a different MAC address. For debugging purposes use the option --verbose.

How does the kernel reach the client from the server during booting?
This works in the following way:
The booting client runs the code in the bootrom or boot-floppy and sends a broadcast with its MAC address and the not-yet-assigned IP address into the network and waits for the reply of a server.
The DHCP server receives this request and sends the settings back which you saw with the command bootpc.
The client reads these settings, sets it IP to the new value, establishes contact with the server and loads the kernel via the TFTP protocol (which is a simple FTP protocol) from the assigned directory.
Then the kernel is copied into the memory and executed. Linux boots.

This short overview shows that you have to install the TFTP protocol on your server. In general this is not active because it has incredible security holes because it does not request a password (default) and should only be used in networks where the port of the TFTP protocol is save (e.g. behind a firewall).
However this does not inhibit that anyone can get illegal access inside your local network.

You activate the TFTP server by adding the following line in /etc/inetd.conf:

File /etc/inetd.conf
  tftp          dgram   udp     wait    nobody  /usr/sbin/tcpd  in.tftpd /tftpboot

The last entry /tftpboot sets the directory /tftpboot to be the root directory for the net-booting PC.
This way is is not allowed to access the files on the server but only the files of the client directories. This secures the files on the server at least.
(For the DHCP configuration you have to set the directories w.r.t. this /tftpboot, because this is the root directory for the TFTP client.)

A re-start of the inetd-process (which could also mean a re-start of the server) reads the new inetd.conf.

NFS settings

The client gets its entire filesystem over the network so the NFS-server has to be configured properly in such a way that the client is allowed to mount the directories.
Every client needs it s entry in the /etc/exports:

File /etc/exports
  /tftpboot/pc1   pc1.netmag.de(rw,no_root_squash)
  /tftpboot/pc2   pc2.netmag.de(rw,no_root_squash)
  /usr		*.netmag.de(ro)

The root directories have to be mounted with read/write access, the /usr directory only with read access.
The option no_root_squash allows that the root of the clients is able to put files on the server with root rights.
Without this entry, all files which are read or written by root are handled as the user nobody from the group nogroup and this makes trouble during booting. In general, you do not even get a prompt to log in because the root does not have the proper right to write to /var/run/utmp.

In addition all boot clients have to be registered with their name, either on the DNS server if it exists or on the computers with entries in the file /etc/hosts.

/etc/hosts  pc1.netmag.de  pc1 pc2.netmag.de  pc2

After restarting the NFS daemon (or the whole server) the changes are active and we can focus on the configuration of the clients.

Installation of the client

The next steps explain the creation of a working kernel and a booting installation.

First you have to compile the kernel which is going to be booted on the client. On any Linux computer you can change into the directory /usr/src/linux and there execute

  >> make xconfig
Configure the kernel that it runs on the hardware of your client. Please keep in mind that only the really important components and drivers have to be integrated into the kernel. The following settings are absolutely necessary for a network-booting PC:

Selection of kernel settings
                     Networking support            y
                     TCP/IP networking             y
                     Network device support        y
                     Ethernet (10 or 100Mbit)      y
                     NFS filesystem support        y
                         Root file system on NFS   y
                              BOOTP support        n
                              RARP support         n

BOOTP and RARP should be deactivated because we use DHCP. It is recommended to create and use a small kernel first and later you can add more hardware support into the kernel.

Then you compile it

  >> make config
  >> make dep
  >> make clean
  >> make zImage
copy the created kernel arch/i386/boot/zImage to the /tmp/netboot/mknbi-linux directory:
  >> cp arch/i386/boot/zImage /tmp/netboot/mknbi-linux/
In the next step you have to modify the kernel a little bit so it can be executed via the network. In the directory /tmp/netboot/mknbi-linux you execute the command:
  ./mknbi-linux/mknbi -d rom -i rom -k zImage -o bootImage
It creates the network-booting kernel bootImage. This is not enough:

If the device /dev/nfs has not already existed, you would have to execute (as root)

  mknod /dev/nfs b 0 255 
The last action on the image has to be:
  rdev bootImage /dev/nfs
Now the kernel is prepared. Next you create the files system on the server which will be used by the clients later. Therefore you create the directory /tftpboot:
  >> mkdir /tftpboot
and the sub-directories for the different clients:
  >> mkdir /tftpboot/pc1
  >> mkdir /tftpboot/pc2
Into these directories you copy the modified kernel
  >> cp bootImage /tftpboot/pc1/
  >> cp bootImage /tftpboot/pc2/
The filesystem of the boot-PCs has to be created next. The simplest way would be to copy the directories of a working distribution into the new ones. If you wanted to have the same Linux version as on your server, you copy (as root):
  >> cp -a /bin /tftpboot/pc1/
  >> cp -a /sbin /tftpboot/pc1/
  >> cp -a /boot /tftpboot/pc1/
  >> cp -a /dev /tftpboot/pc1/
  >> cp -a /etc /tftpboot/pc1/
  >> cp -a /lib /tftpboot/pc1/
  >> cp -a /var /tftpboot/pc1/
  >> cp -a /bin /tftpboot/pc1/
In addition, you have to create the following sub-directories:
  >> mkdir /tftpboot/pc1/home
  >> mkdir /tftpboot/pc1/proc
  >> mkdir /tftpboot/pc1/tmp
(The same for the pc2 installation.) If you wanted to set up the same user accounts on the server, you simply mount the home directories using NFS.

Any further configuration of the client clearly depends on the distribution you use. In any case the routing has to be set on all PCs and also the /etc/fstab has to be adjusted.
Also important are the settings of the host name and the IP number of the computer (with SuSE change the file /etc/rc.config), otherwise the NFS mounting will not work.

File /tftpboot/pc1/etc/fstab
   # /etc/fstab on firewall
   server:/usr			/usr	nfs	defaults	0  0
   #to mount the home directories
   #server:/home			/home   nfs	defaults	0  0
   #to use the CD-ROM drive on the server
   server:/mnt/cdrom                /cdrom  nfs     noauto,user     0  0
   proc 			        /proc   proc    defaults        0  0

File /tftpboot/pc1/etc/route.conf
   # /etc/route.conf
   # In this file you can configure your static routing...
   # This file is read by /sbin/init.d/route. 
   #                  eth0   	       eth0

And now the parts of the file rc.conf which have to be changed

File /tftpboot/pc1/etc/rc.conf
   # IP Adresses
   # parameters for ifconfig, if you put "Bootp" into it, Bootp will
   # be used to configure it
   # sample entry for ethernet:
   # IFCONFIG_0=" broadcast netmask"
   IFCONFIG_0=" up"

These settings should make sure that the PC boots and reaches the prompt (at least). Often you get error messages while first booting. The best scenario would be if you log in and solve these problems directly from the client.
If you found the ideal configuration for your client you can copy the directory /tftpboot and use it for other clients, too.
Of course you can boot more than one client using the same /tftpboot sub-directory.

Diskless PC
A network booting PC inside a paper box. Without hard disk, just a network card, soundcard, a vga card and a floppy drive. No fan. (Duplicating the construction is not recommended.)


You should be astonished if everything worked at the first time. Stay brave if one step did not work. Too many distributions and configurations exist and it is not possible to present an all-round solution.
Often the problems are the following:

Your system uses tcpwrapper.
The new booting PC does not own a legal IP address and registers itself with the IP address TCP wrapper can deny an access to the Bootp or DHCP port.
you can avoid this with an entry in the file /etc/hosts.allow on your server:

File /etc/hosts.allow
  in.tftpd:	192.168.0.
  portmap:	192.168.0.

If the boot floppy does not work like we wanted, it is often caused by the wrong settings for the bootrom. If you were sure that the options were chosen correctly, you should try new drivers.
Also with high IO addresses problems can occur. Reports exist that a few cards have problems with special packet interrupt numbers.
If you MAC address was shown as FF:FF:FF:FF:FF during booting, your card could not be recognized by the driver correctly.

If your card was found but you do not receive the boot data from the server (the information of bootpc) then it might be a wrong routing on the server site. Look into the file /var/log/messages and search for an entry like Network not reachable.
Add the line

into the routing table with the IP address of the gateway (often the server IP itself).

If the client gets the bootp data from the server but was not able to download the kernel you should check if the path in /etc/dhcp.conf was specified correctly.
This error can occur as well with buggy network drivers. Try newer or older card drivers.

More possible errors can be found at the end of the documentation at http://www.ltsp.org/download/lts/doc/lts.html

NFS swapping

A good reason for building network-booting PCs is the re-activation of older computers as working X terminals.
However often the old computers do not own enough RAM to use programs or even start an X server.
You could install a swap drive but then you loose the advantage of no noise because you would need a hard disk. A way out of this problem offers a hacker patch for the Linux kernel which enables a NFS swap device which is placed on the server.
On the server you do not have to make any changes thus you do not risk any security lack on the server.

Nevertheless this patch has two disadvantages which should not be ignored:

  • A swap memory on a NFS drive is very very slow. Its use should only be taken into account if the PC has really low RAM so many programs do not start and work (up to 8MB RAM).
  • Swap space on a NFS drive is a security hole because the memory is not encrypted before sending and thus passwords which are stored in the memory can be intercepted.
If you are not shocked now, we can start. First you get the required patch for your wanted kernel from http://www.instmath.rwth-aachen.de/~heine/nfs-swap/nfs-swap.html (the patch is not offered for all kernel versions).

Before you insert the patch you should make a copy of the kernel.

  >> mkdir /usr/src/hacking
  >> cp -a /usr/src/linux /usr/src/hacking/
then you move into the directory /usr/src/hacking/linux and there you insert the patch with:
  gunzip -c /path/to/linux-2.*.*-nfs-swap.diff |  patch -p1 -l -s
You activate the following option in the kernel:

kernel option in addition
  Code maturity level options 
                Prompt for development and/or incomplete code/drivers 
         Networking options 
                Swapping via network sockets (EXPERIMENTAL) 
         Filesystems/Network File Systems 
                Swapping via NFS (EXPERIMENTAL) 

and compile it. The kernel has to be modified using mknbi and rdev and then you copy the kernel over the one before.
You boot the client and execute

  >> cat /proc/meminfo
You should get an output like:
Output cat /proc/meminfo
          total:    used:    free:  shared: buffers:  cached:
  Mem:   6938624  5767168  1171456  4685824        0  3690496
  Swap:        0        0        0
  MemTotal:      6776 kB
  MemFree:       1144 kB
  MemShared:     4576 kB
  Buffers:          0 kB
  Cached:        3604 kB
  SwapTotal:        0 kB
  SwapFree:         0 kB

Where you can see the swap memory does not exist. This you can change with:

  >> dd if=/dev/zero of=/SWAPFILE bs=1k count=20480
  >> mkswap /SWAPFILE 20480
  >> swapon /SWAPFILE
Then you take another look
  >> cat /proc/meminfo
and you get
Uitvoer cat /proc/meminfo
          total:    used:    free:  shared: buffers:  cached:
  Mem:   6938624  5783552  1155072  4685824        0  3690496
  Swap: 20967424        0 20967424
  MemTotal:      6776 kB
  MemFree:       1128 kB
  MemShared:     4576 kB
  Buffers:          0 kB
  Cached:        3604 kB
  SwapTotal:    20476 kB
  SwapFree:     20476 kB

You installed 20 MB swap space in addition!
Now you can start even bigger programs without running out of memory.

Finally you made it! We warned you that the installation of a network-booting PC is not trivial.

http://web.singnet.com.sg/~leetc/howto/x-terminal.html A short documentation which describes the installation of an X terminal. Also you find different scripts for an automatic configuration of the PCs.
Uses Bootp instead of DHCP.
http://www.ltsp.org/download/lts/doc/lts.html If you have to install a big amount of X terminals this package will save much time for configuration. The reading of the manual will be worthwhile even if you just install a few X terminals.
you find hints to optimize the server and tips to find errors.
http://batronix.com/elektronik/bauanleitungen/eeprommer.shtml If you do not have the money to buy an Eprom writer you can assemble one by yourself, too.
A small manual describing the set-up of a diskless computer.
http://www.linuxdoc.org/HOWTO/mini/NFS-Root.html Mini-Howto about installation and configuration on a PC with root partition which can be mounted via NFS.
http://www.nilo.org/remoteboot/Remote-Boot.html Nilo is a network-lilo, which can be used to start different configurations and OS even over the network.
http://etherboot.sourceforge.net/ Etherboot is another package which creates bootroms but it is not so well developed as netboot.
http://www.online-club.de/m0/rp10067/diskless/grundlagen.html Here you find a short German manual about the configuration of a diskless client.
http://www.instmath.rwth-aachen.de/~heine/nfs-swap/nfs-swap.html The homepage of the NFS swap patch. Remind the security holes!

Talkback Area

Enter Own Comment