4.4. Preparing Files for TFTP Net Booting

If your machine is connected to a local area network, you may be able
to boot it over the network from another machine, using TFTP. If you
intend to boot the installation system from another machine, the
boot files will need to be placed in specific locations on that machine,
and the machine configured to support booting of your specific machine.

You need to setup a TFTP server, and for many machines, a BOOTP server
, or RARP server, or DHCP server.

The Reverse Address Resolution Protocol (RARP) is
one way to tell your client what IP address to use for itself. Another
way is to use the BOOTP protocol. BOOTP is an IP protocol that
informs a computer of its IP address and where on the network to obtain
a boot image. The DHCP (Dynamic Host Configuration
Protocol) is a more flexible, backwards-compatible extension of BOOTP.
Some systems can only be configured via DHCP.

The Trivial File Transfer Protocol (TFTP) is used to serve the boot
image to the client. Theoretically, any server, on any platform,
which implements these protocols, may be used. In the examples in
this section, we shall provide commands for SunOS 4.x, SunOS 5.x
(a.k.a. Solaris), and GNU/Linux.

4.4.1. Setting up RARP server

To setup RARP, you need to know the Ethernet address (a.k.a. the MAC address)
of the client computers to be installed.
If you don't know this information, you can
pick it off the initial OpenPROM boot messages, use the
OpenBoot .enet-addr command, or
boot into “Rescue” mode (e.g., from the rescue floppy) and use the
command /sbin/ifconfig eth0.

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

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 a RARP server system 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.

4.4.2. Setting up BOOTP server

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:

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
Section 4.4.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 Section 4.4.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.

4.4.3. Setting up a DHCP server

One free software DHCP server is 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):

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.

4.4.4. Enabling the TFTP Server

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

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

Debian packages will in general set this up correctly by default when they
are installed.

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; on other machines,
find out the process ID for inetd, and run
kill -HUP inetd-pid.

4.4.5. Move TFTP Images Into Place

Next, place the TFTP boot image you need, as found in
Section 4.2.1, “Where to Find Installation Images”, 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.

4.4.5.1. SPARC TFTP Booting

SPARC architectures for instance use the subarchitecture names, such
as “SUN4M” or “SUN4C”; in some cases, the
architecture is left blank, so the file the client looks for is just
client-ip-in-hex. Thus, if your system
subarchitecture is a SUN4C, and its IP is 192.168.1.3, the filename
would be C0A80103.SUN4C. An easy way to determine
this is to enter the following command in a shell (assuming the
machine's intended IP is 10.0.0.4).

$ printf '%.2x%.2x%.2x%.2x\n' 10 0 0 4

This will spit out the IP in hexadecimal; to get to the correct
filename, you will need to change all letters to uppercase and
if necessary append the subarchitecture name.

You can also force some sparc systems to look for a specific file name
by adding it to the end of the OpenPROM boot command, such as
boot net my-sparc.image. This must still reside
in the directory that the TFTP server looks in.