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 CATS 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.
Yet another alternative exists on VMEbus
systems: the IP address can be manually configured in boot ROM.
The DHCP (Dynamic Host Configuration
Protocol) is a more flexible, backwards-compatible extension of BOOTP.
Some systems can only be configured via DHCP.
For PowerPC, if you have a NewWorld Power Macintosh machine, it is a
good idea to use DHCP instead of BOOTP. Some of the latest machines
are unable to boot using BOOTP.
Unlike the Open Firmware found on Sparc and PowerPC machines, the SRM
console will not use RARP to obtain its IP
address, and therefore you must use BOOTP for net booting your Alpha.
You can also enter the IP configuration for network interfaces
directly in the SRM console.
Alpha systems can also be net-booted using the DECNet MOP (Maintenance
Operations Protocol), but this is not covered here. Presumably, your
local OpenVMS operator will be happy to assist you should you have
some burning need to use MOP to boot Linux on your Alpha.
Some older HPPA machines (e.g. 715/75) use RBOOTD rather than BOOTP.
An RBOOTD package is available on the parisc-linux web site.
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.
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 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; server, tftp-hpa qualifies.
If your TFTP server is a GNU/Linux box running Linux 2.4.X you'll need
to set the following on your server:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
to turn off Path MTU discovery, otherwise the Indy's PROM can't
download the kernel. Furthermore, make sure TFTP packets are sent from
a source port no greater than 32767, or the download will stall after
the first packet. Again, it's Linux 2.4.X tripping this bug in the
PROM, and you can avoid it by setting
echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range
to adjust the range of source ports the Linux TFTP server uses.
Move TFTP Images Into Place
Next, place the TFTP boot image you need, as found in
, 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.
On NewWorld Power Macintosh machines, you will need to set up the
yaboot boot loader as the TFTP boot image.
Yaboot will then retrieve the kernel and RAMdisk
images via TFTP itself. For net booting, use the
yaboot-netboot.conf. Just rename this to
yaboot.conf in the TFTP directory.
Often, the file that the TFTP client will look for is
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/pxelinux.cfg, and within that directory
create a text file default. Here is an example of
a default file's contents:
append load initrd=root.bin devfs=nomount
devfs=nomount 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.
DECstation TFTP Images
For DECstations, there are tftpimage files for each subarchitecture,
which contain both kernel and installer in one file. The naming
convention is tftpimage-subarchitecture or
tftpimage-subarchitecture.gz. If the
tftpimage is gzipped (the name ends with .gz), you need to unpack it
first with gunzip
as DECstations cannot boot compressed files by TFTP. Copy the
tftpimage file you would like to use to
/tftpboot/tftpboot.img if you work with the
example BOOTP/DHCP setups described above.
The DECstation firmware boots by TFTP with the command boot
# is the number of the TurboChannel device
from which to boot. On most DECstations this is "3". If the
BOOTP/DHCP server does not supply the filename or you need to pass
additional parameters, they can optionally be appended with the
boot #/tftp/filename param1=value1 param2=value2 ...
Several DECstation firmware revisions show a problem with regard to
net booting: the transfer starts, but after some time it stops with
an a.out err. This can have several reasons:
The firmware does not respond to ARP requests during a TFTP
transfer. This leads to an ARP timeout and the transfer stops. The
solution is to add the MAC address of the Ethernet card in the
DECstation statically to the ARP table of the TFTP server. This is
done by running arp -s
MAC-address as root on the
machine acting as TFTP server. The MAC-address of the DECstation can
be read out by entering cnfg at the DECstation
The firmware has a size limit on the files that can be booted
There are also firmware revisions that cannot boot via TFTP at all. An
overview about the different firmware revisions can be found at the
NetBSD web pages:
Alpha TFTP Booting
On Alpha, you must specify the filename (as a relative path to the
boot image directory) using the -file argument
to the SRM boot command, or by setting the
BOOT_FILE environment variable. Alternatively,
the filename can be given via BOOTP (in ISC dhcpd,
use the filename directive). Unlike Open
Firmware, there is no default filename on SRM, so
you must specify a filename by either one of
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.
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.
BVM/Motorola TFTP Booting
For BVM and Motorola VMEbus systems copy the files
&bvme6000-tftp-files; to /tftpboot/.
Next, configure your boot ROMs or BOOTP server to initially load the
tftplilo.mvme files from the TFTP server. Refer
to the tftplilo.txt file for your subarchitecture
for additional system-specific configuration information.
SGI Indys TFTP Booting
On SGI Indys you can rely on the bootpd to supply
the name of the TFTP file. It is given either as the
bf= in /etc/bootptab or as
the filename= option in
TFTP Installation for Low-Memory Systems
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 .
Copy the Linux kernel image on your TFTP server using the
a.out image for the architecture you are
Untar the root archive on your NFS server (can be the same system as
your TFTP server):
# cd /tftpboot
# tar xvzf root.tar.gz
Be sure to use the GNU tar (other tar programs, like the
SunOS one, badly handle devices as plain files).
Export your /tftpboot/debian-sparc-root directory
with root access to your client. E.g., add the following line to
/etc/exports (GNU/Linux syntax, should be similar
NOTE: "client" is the host name or IP address recognized by the server for
the system you are booting.
Create a symbolic link from your client IP address in dotted notation
to debian-sparc-root in the
/tftpboot directory. For example, if the client
IP address is 192.168.1.3, do
# ln -s debian-sparc-root 192.168.1.3
Installing with TFTP and NFS Root
Installing with TFTP and NFS Root is similar to
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,
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).
To boot the client machine, go to .