In this section I assume you want to boot a Linux kernel. Booting a FreeBSD kernel is documented elsewhere and does not require a tagged image. Booting a DOS kernel is similar, the main differences being in the way you set up the tagged image.
Etherboot expects to download a tagged image containing the code to be executed. Briefly explained, a tagged image is a wrapper around the pieces of code or data that need to be put in various places in the computer's memory. It contains a directory telling how large the pieces are and where they go in memory. It also says where to start execution.
A tagged image is created using a utility program. The utility program is specific to the kernel you want to load. The version for Linux is called mknbi-linux or mkelf-linux and that for DOS is mknbi-dos. These utilities are distributed separately and can be obtained from Etherboot web site.
You will almost certainly have to compile a custom kernel because the kernel needs to have the "Root file system on NFS" option compiled in. (You need to select "NFS filesystem support" as built-in, not a module, and possibly also "Kernel level autoconfiguration" before this option will appear.) You should also select "BOOTP support" and/or "DHCP support". "RARP support" is not needed. In 2.2 kernels you have to enable the "Kernel level autoconfiguration" option under IP networking to access the BOOTP support question. And unless you are using an initrd (initial ramdisk) you will have to compile in the driver for your network card too. For details, see the file /usr/src/linux/Documentation/nfsroot.txt in a Linux kernel source distribution.
After you have compiled the custom kernel, make the tagged image, typically like this:
mknbi-linux --output=/tftpdir/vmlinuz.xterm zImage
(See an important note regarding IP autoconfig in kernels in the 2.2 series 2.2.18 and after under the section --ip= in the mknbi-linux documentation.) Then put the tagged image in where the tftp daemon expects to find it, in this example /tftpdir. Make sure it is world-readable because typically the tftp daemon runs as an unprivileged user. It is recommended that you set a path explicitly for tftpd instead of relying on any defaults. For example:
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpdir
You need to set up a DHCP server to hand out an IP address and other configuration information to the client.
The main requirement of the DHCP server is that it needs to send out suitable configuration information. Prior to version 5.0.7, Etherboot accepted any DHCP offer (but see REQUIRE_VCI_ETHERBOOT below for an exception). In version 5.0.7 and above, Etherboot will not accept any DHCP offer where the server IP is empty (all zero) or the filename is empty. These offers are useless to Etherboot anyway so ignoring these offers will give it a better chance of picking the right DHCP server.
If you already have a DHCP server on your network for providing Windows clients with IP addresses, chances are that it is not a suitable DHCP server because it's only tailored to the single purpose of handing out client addresses. Suitable DHCP servers include the ISC DHCPD, available for most Unix/Linux systems. You can run such a DHCP server in parallel with the Windows one, provided you do not attempt to give Windows clients leases, in which case there would be a clash. You can exclude Windows clients in two ways. One is to register the only the MAC addresses of the diskless clients in /etc/dhcpd.conf, and to make sure that the server is declared "not authoritative". The second is to look for the Vendor Class Identifier of "Etherboot-5.x" in the DHCP discover packet.
If you already have a DHCP server on your network that does provide the server IP and the filename, then you have to either use that DHCP server by editing its configuration file. This may require the cooperation of the system admin if you are not the admin. If you are not able to configure the DHCP server, then proceed to the section on REQUIRE_VCI_ETHERBOOT.
The minimum information you need to put in /etc/dhcpd.conf is:
Here is a sample DHCP configuration for ISC dhcpd:
option domain-name "ken.net.au";
option domain-name-servers 192.168.0.1;
option broadcast-address 192.168.0.255;
use-host-decl-names on;
subnet 192.168.0.0 netmask 255.255.255.0 {
filename "/tftpdir/vmlinuz.xterm";
host xterm {
hardware ethernet 08:00:2B:B7:F3:80;
fixed-address xterm.ken.net.au;
filename "/tftpdir/vmlinuz.xterm";
}
}
The declaration "use-host-decl-names on" tells dhcpd to include the name xterm in the reply so that it can be used as part of pathname to mount by NFS, etc.
If your tftp server is not the same as the DHCP server, use the next-server declaration to specify a tftp server.
You don't have to use fixed addresses, of course, but if you use dynamic addresses, then you have to deal with the resulting issues of NFS mounting.
Recent kernels in the 2.2 series can autoconfigure using DHCP thanks to code by Chip Salzenberg. It also can use DHCP in 2.4 kernels starting from 2.4.4 thanks to Eric Biederman. Otherwise the kernel will do a bootp request to find the IP address for mounting the NFS filesystem.
You may also wish to investigate the --rootdir=rom option in mknbi-linux which tells the kernel to take the address from the initial DHCP reply, or to use initrds in conjunction with a userland DHCP client program to configure the netbooted machine.
You may need to Etherboot in an environment where you have to install your own DHCP server, and it may interfere with the existing DHCP server. Etherboot has a feature designed to overcome this problem. It consists of two parts:
The first part is Etherboot contains code that when it sends out a DHCPDISCOVER request, a tag containing a Vendor Class Identifier of "Etherboot-x.y" is sent out, where x.y is the version number, currently 5.0. The 5 and the 0 are printable digits, not binary values, i.e. byte values 53 and 48 respectively. This allows the server to identify Etherboot clients and ignore all others.
The second part is Etherboot can be conditionally compiled to require a Vendor Encapsulated Option containing a VCI of "Etherboot", otherwise it will ignore the DHCPOFFER. The option is not compiled in by default because it would cause Etherboot to not boot in plain setups. The server we want to respond will include this tag in DHCPOFFERs and while other servers (e.g. Windows servers) may respond, they will be ignored.
Vendor Encapsulated Option is supported in ISC DHCPD 2 or 3. (It's not documented in DHCPD 2, but it works.) Other DHCP servers may support VEO. (It's a RFC2132 option.) In ISC DHCPD 3, follow the documentation for declaring a VEO scope. In ISC DHCPD 2 the magic line required is:
option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
Put this in the appropriate scope. Translation: Vendor Encapsulation Options (Option 43) encloses: Vendor Class Identifier (Option 60 = 0x3c), length 9, value "Etherboot"; End of Options (Option 255 = 0xff).
If you have a DHCP server already running for the subnet, you probably should specify that your additional ISC DHCPD server is not authoritative for the the subnet, or it will veto (NAK) existing client IP address allocations, upsetting the status quo. See the ISC DHCPD options documentation.
Here is a practical document describing how it is done.
More information about DHCP can be found at the DHCP FAQ Web Page.
If you are on a local network that is not directly connected to the Internet, you can use the "private" IP addresses 192.168.x.y (or in the other ranges mentioned in RFC1918). Otherwise please ask either your network administrator or your Internet service provider for your own IP address(es).
You could use a bootp daemon instead of a DHCP daemon. This means installing the bootp package, sometimes it's not supplied or installed by default in some distributions. Then you need to make sure that the bootps service is active in /etc/inetd.conf; it should look something like this:
bootps dgram udp wait root /usr/sbin/tcpd bootpd
Then you need to edit /etc/bootptab. The essential pieces of information you need to put in bootptab are similar to /etc/dhcpd.conf.
Here is an example of a /etc/bootptab for the bootpd supplied with many Linux distributions and probably many versions of Unix:
.default:\
:ht=ethernet:\
:hd=/tftpdir:bf=null:\
:ds=nameserver:\
:hn:to=36000:
xterm.ken.net.au:tc=.default:ha=08002BB7F380:ip=192.168.0.100:bf=vmlinuz.xterm
The first entry sets up some common defaults which applies to all succeeding entries which can be "included" using the tc=.default attribute. The first field is the domain name of the machine. The ha attribute is the Ethernet address. The ip attribute is self-explanatory. The bf field specifies the tagged image filename. For more details, consult the bootptab man page.
There is a bug in some old versions of bootpd where unnecessarily large reply packets are sent, causing packet fragmentation at the UDP level, and dropping of the packets by Etherboot. Either get a recent bootpd or use DHCPD. DHCPD can emulate bootpd if that's what you really want. But for various reasons, DHCPD is prefered to bootpd.
Please note that if you use the ef (extension file) attribute to be able to send more configuration data to the diskless machine, you must run bootpef everytime bootptab is modified.
Now set up a tftp daemon. This means installing the tftp package and making sure that the tftp service is active in /etc/inetd.conf. If you want to be very careful you may wish to use the secure (-s) option of tftpd, this chroots to the specified directory, but then your pathnames in bootptab or dhcpd.conf must be relative to the new root directory.
If you are booting many clients you should be aware of the limitations
of running tftpd from inetd. Typically inetd has limits on how often a
daemon can be spawned, to detect runaway daemons. If many clients
request the tftp service within a short period, inetd may shutdown that
service. If you have a setup where there are many clients, it may be
better to use an improved replacement for inetd, such as xinetd.
Another solution is to run a dedicated tftpd that is not spawned from
inetd. One such tftpd can be found here at:
ftp://nilo.on.openprojects.net/pub/nilo/snapshots Another
possible contender is in the directory atftp at the Etherboot
web site. This one is started from inetd, but thereafter
multithreads internally.