To setup RARP, you need to know the Ethernet address of the client (a.k.a. the MAC address). If you don't know this information, you can boot into ``Rescue'' mode (e.g., from the rescue floppy) and use the command /sbin/ifconfig eth0.

On systems using a Linux 2.2.x kernel, you need to populate the kernel's RARP table. To do this, run the following commands:

If you get

SIOCSRARP: Invalid argument

you probably need to load the RARP kernel module or else recompile the kernel to support RARP. Try modprobe rarp and then try the rarp command again.

On systems using a Linux 2.4.x kernel, there is no RARP module, and you should instead use the rarpd program. The procedure is similar to that used under SunOS in the following paragraph.

Under SunOS, you need to ensure that the Ethernet hardware address for the client is listed in the ``ethers'' database (either in the /etc/ethers file, or via NIS/NIS+) and in the ``hosts'' database. Then you need to start the RARP daemon. In SunOS 4, issue the command (as root): /usr/etc/rarpd -a; in SunOS 5, use /usr/sbin/rarpd -a.

There are two BOOTP servers available for GNU/Linux, the CMU bootpd and the other is actually a DHCP server, ISC dhcpd, which are contained in the bootp and dhcp packages in Debian GNU/Linux.

To use CMU bootpd, you must first uncomment (or add) the relevant line in /etc/inetd.conf. On Debian GNU/Linux, you can run update-inetd --enable bootps, then /etc/init.d/inetd reload to do so. Elsewhere, the line in question should look like:

bootps   dgram   udp     wait    root    /usr/sbin/bootpd  bootpd -i -t 120

Now, you must create an /etc/bootptab file. This has the same sort of familiar and cryptic format as the good old BSD printcap, termcap, and disktab files. See the bootptab manual page for more information. For CMU bootpd, you will need to know the hardware (MAC) address of the client. Here is an example /etc/bootptab:

client:\
  hd=/tftpboot:\
  bf=tftpboot.img:\
  ip=192.168.1.90:\
  sm=255.255.255.0:\
  sa=192.168.1.1:\
  ha=0123456789AB:

You will need to change at least the "ha" option, which specifies the hardware address of the client. The "bf" option specifies the file a client should retrieve via TFTP; see Abschnitt 4.6.5, „Move TFTP Images Into Place“ for more details.

By contrast, setting up BOOTP with ISC dhcpd is really easy, because it treats BOOTP clients as a moderately special case of DHCP clients. Some architectures require a complex configuration for booting clients via BOOTP. If yours is one of those, read the section Abschnitt 4.6.3, „Setting up a DHCP server“. Otherwise, you will probably be able to get away with simply adding the allow bootp directive to the configuration block for the subnet containing the client, and restart dhcpd with /etc/init.d/dhcpd restart.

At the time of this writing, there is only one DHCP server which is free software, namely ISC dhcpd. In Debian GNU/Linux, this is available in the dhcp package. Here is a sample configuration file for it (usually /etc/dhcpd.conf):

option domain-name "example.com";
option domain-name-servers ns1.example.com;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
server-name "servername";

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.200 192.168.1.253;
  option routers 192.168.1.1;
}

host clientname {
  filename "/tftpboot/tftpboot.img";
  server-name "servername";
  next-server servername;
  hardware ethernet 01:23:45:67:89:AB; 
  fixed-address 192.168.1.90;
}

In this example, there is one server "servername" which performs all of the work of DHCP, server, TFTP server, and network gateway. You will almost certainly need to change the domain-name options, as well as the server name and client hardware address. The "filename" option should be the name of the file which will be retrieved via TFTP.

After you have edited the dhcpd configuration file, restart it with /etc/init.d/dhcpd restart.

option domain-name "example.com";

default-lease-time 6048;
max-lease-time 604800;

allow booting;
allow bootp;

# The next paragraph needs to be modified to fit your case
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.200 192.168.1.253;
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
# the gateway address which can be different 
# (access to the internet for instance)
  option routers 192.168.1.1;
# indicate the dns you want to use
  option domain-name-servers 192.168.1.3;
}

host tftpserver {
# tftp server ip address
  fixed-address 192.168.1.90;
# tftp server hardware address
  hardware ethernet 01:23:45:67:89:AB;
}

group {
 next-server 192.168.1.3;
 host tftpclient {
# tftp client hardware address
  hardware ethernet  00:10:DC:27:6C:15;
  filename "/tftpboot/pxelinux.0";
 }
}

To get the TFTP server ready to go, you should first make sure that tftpd is enabled. This is usually enabled by having the following line in /etc/inetd.conf:

tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot

Look in that file and remember the directory which is used as the argument of in.tftpd; you'll need that below. The -l argument enables some versions of in.tftpd to log all requests to the system logs; this is useful for diagnosing boot errors. If you've had to change /etc/inetd.conf, you'll have to notify the running inetd process that the file has changed. On a Debian machine, run /etc/init.d/inetd reload (for slink/2.1 and older systems use /etc/init.d/netbase reload); on other machines, find out the process ID for inetd, and run kill -HUP inetd-pid.

To use the Pre-boot Execution Environment (PXE) method of TFTP booting, you will need a TFTP server with tsize support. On a Debian GNU/Linux server, tftp-hpa qualifies.

Next, place the TFTP boot image you need, as found in Abschnitt 4.2.3, „Where to Find Installation Files“, in the tftpd boot image directory. Generally, this directory will be /tftpboot. You'll have to make a link from that file to the file which tftpd will use for booting a particular client. Unfortunately, the file name is determined by the TFTP client, and there are no strong standards.

Often, the file that the TFTP client will look for is client-ip-in-hexclient-architecture. To compute client-ip-in-hex, take each byte of the client IP address and translate it into hexadecimal notation. If you have a machine handy with the bc program, you can use the program. First issue the obase=16 command to set the output to hex, then enter the individual components of the client IP one at a time. As for client-architecture, try out some values.

For PXE booting, you can use the boot loader included with syslinux: pxelinux.0. The boot loader should be copied into the /tftpboot folder. Then create a subdirectory within /tftpboot named /tftpboot/pxelinux.cfg, and within that directory create a text file default. Here is an example of a default file's contents:

default lanlinux
prompt 1

label lanlinux
  kernel tftpboot.img
  append load initrd=root.bin devfs=mount

devfs=mount is important, because without it there may be problems mounting the root.bin file system once the kernel is booted.

Finally, copy the tftpboot.img and root.bin files from the Debian ftp archive into the /tftpboot folder, where the bootloader will be looking for them.

On some systems, the standard installation RAMdisk, combined with the memory requirements of the TFTP boot image, cannot fit in memory. In this case, you can still install using TFTP, you'll just have to go through the additional step of NFS mounting your root directory over the network as well. This type of setup is also appropriate for diskless or dataless clients.

First, follow all the steps above in Abschnitt 4.6, „Preparing Files for TFTP Net Booting“.

Installing with TFTP and NFS Root is similar to Abschnitt 4.6.6, „TFTP Installation for Low-Memory Systems“ because you don't want to load the RAMdisk anymore but boot from the newly created NFS-root file system. You then need to replace the symlink to the tftpboot image by a symlink to the kernel image (for example, linux-a.out).

RARP/TFTP requires all daemons to be running on the same server (the workstation is sending a TFTP request back to the server that replied to its previous RARP request).