Diskless Nodes HOW-TO document for Linux Robert Nemkin buci@math.klte.hu , Al Dev (Alavoor Vasudevan) - Maintainer of this HOWTO alavoor@yahoo.com , Markus Gutschke markus+etherboot@gutschke.com , Ken Yap ken.yap@acm.org , Zurück zu Gero gero@gkminix.han.de v1.0, 13 May 1999 This document describes how to set up a diskless Linux box. As tech­ nology is advancing rapidly, networkcards are becoming cheaper and much faster - 100 MBits ethernet is standard now and in about 1 to 2 years 1000 MBits i.e. 1GigBits ethernet cards will become a industry standard. With high-speed network cards, remote access will become as fast as the local disk access which will make diskless nodes a viable alternative to workstations in local LAN. Also diskless nodes elimi­ nates the cost of software upgrades and system administration costs like backup, recovery which will be centralized on the server side. Diskless nodes also enable "sharing/optimization" of centralised server CPU, memory, hard-disk, tape and cdrom resources. Diskless nodes provides mobility for the users i.e., users can log on from any one of diskless nodes and are not tied to one workstation. Diskless Linux box completely eliminates the need for local floppy disk, cdrom drive, tape drive and hard-disk. Diskless nodes JUST has a network card, 8MB RAM, a low-end cpu and a very simple mother-board which does not have any interface sockets/slots for harddisks, modem, cdrom, floppy etc.. With Diskless linux nodes you can run programs on remote Linux 64 CPU SMP box or even on Linux super-computer! Diskless nodes lowers the "Total Cost of Ownership" of the computer system. This document is copy­righted by Robert Nemkin and other authors as listed above. Copyright policy is GPL. Thanks to Bela Kis bkis@car­ tan.math.klte.hu for translating this initial document v0.0.3 (which was a mini-howto) to English. ______________________________________________________________________ Table of Contents 1. Other Formats of this Document 2. Introduction to Network Booting and Etherboot 2.1 What is Network booting? 2.2 How does it work 2.3 Netbooting in Practice 2.4 Uses of Network booting 2.5 For more information 3. Begin setup 3.1 Document Changes 3.2 How to set up a diskless Linux box 3.3 Related documents 3.4 How does it work? 3.5 Hardware 4. Fundamental ideas 4.1 Setting up the PC 4.2 Setting up a bootpd on the server 4.3 Configure the bootpd on the server 4.4 Understanding tftp 4.5 Kernel Image 4.6 Setting up a minimal Linux configuration on the remote server 4.7 Configuring the tftp server 4.8 Final work 4.9 Net Loader 4.10 RH5 configuration 4.11 Gotchas and caveats 4.12 X-terminal 5. Trouble shooting 5.1 Memory and diskspace requirements; speed 5.2 Possible errors 5.3 Errors and possible further expansions of this document 6. EEPROM Burners and Memory chips 6.1 List of EEPROM Burner manufacturers 6.2 Non-Volatile Memory chips 7. Etherboot 7.1 Introduction 7.1.1 What hardware is supported? 7.1.2 Availability of this document 7.1.3 Getting help 7.2 Unpacking, compiling and testing the package 7.2.1 Unpacking the distribution 7.2.2 Compiling the ROM images 7.2.3 Testing the ROM images 7.3 Setting up a diskless boot 7.3.1 Making a tagged image 7.3.2 Compiling a custom kernel 7.3.3 Setting up a bootp daemon 7.3.4 Setting up a DHCP daemon 7.3.5 Setting up a tftp daemon 7.4 Testing the network booting 7.4.1 Setting up a NFS root filesystem 7.4.2 Swap over NFS 7.5 Booting DOS 7.6 Making an Etherboot EPROM or EEPROM 7.6.1 Choosing the EPROM 7.6.2 Enabling the EPROM 7.6.3 Size and speed of the EPROM 7.7 Troubleshooting tips 7.8 Acknowledgements 7.9 Copyright 8. Netboot 8.1 Introduction 8.2 README 8.2.1 Copyright Notice, Acknowledgements 8.2.2 Overview 8.2.3 Features 8.2.4 Installation 8.2.5 Mailing list 8.2.6 Disclaimer 8.3 Download Netboot 8.4 Netboot useful links 8.5 RFC 951 8.6 RFC 1533 8.7 RFC 1350 8.8 Install Instructions 8.9 Troubleshoot Problems ______________________________________________________________________ 1. Other Formats of this Document This document is published in 10 different formats namely - DVI, Postscript, Latex, LyX, GNU-info, HTML, RTF(Rich Text Format), Plain- text, Unix man pages and SGML. · You can get this HOWTO document as a single file tar ball in HTML, DVI, Postscript or SGML formats from - · Plain text format is in: · Translations to other languages like French, German, Spanish, Chinese, Japanese are in Any help from you to translate to other languages is welcome. The document is written using a tool called "SGML tool" which can be got from - Compiling the source you will get the following commands like · sgml2html databasehowto.sgml (to generate html file) · sgml2rtf databasehowto.sgml (to generate RTF file) · sgml2latex databasehowto.sgml (to generate latex file) This document is located at - · Also you can find this document at the following mirrors sites - · · · · · Other mirror sites near you (network-address-wise) can be found at select a site and go to directory /LDP/HOWTO/Diskless-HOWTO.html In order to view the document in dvi format, use the xdvi program. The xdvi program is located in tetex-xdvi*.rpm package in Redhat Linux which can be located through ControlPanel | Applications | Publishing | TeX menu buttons. To read dvi document give the command - xdvi -geometry 80x90 howto.dvi And resize the window with mouse. See man page on xdvi. To navigate use Arrow keys, Page Up, Page Down keys, also you can use 'f', 'd', 'u', 'c', 'l', 'r', 'p', 'n' letter keys to move up, down, center, next page, previous page etc. To turn off expert menu press 'x'. You can read postscript file using the program 'gv' (ghostview) or The ghostscript program is in ghostscript*.rpm package and gv program is in gv*.rpm package in Redhat Linux which can be located through Con­ trolPanel | Applications | Graphics menu buttons. The gv program is much more user friendly than ghostscript. Also ghostscript and gv are available on other platforms like OS/2, Windows 95 and NT, you view this document even on those platforms. To read postscript document give the command - gv howto.ps To use ghostscript give - ghostscript howto.ps 2. Introduction to Network Booting and Etherboot This chapter is written by Ken Yap and explains how to bootstrap your computer from a program stored in non-volatile memory without accessing your hard disk. It is an ideal technique for maintaining and configure a farm of linux boxes 2.1. What is Network booting? Network booting is an old idea. The central idea is that the computer has some bootstrap code in non-volatile memory, e.g. a ROM chip, that will allow it to contact a server and obtain system files over a network link. One goal is to avoid the use of a hard disk for booting. There are various reasons for doing this. One is to reduce the cost of maintaining software on many different machines. With network booting the files are held at a central server and can be updated at one location. Another goal is to use computers in locations where hard disks are not robust enough. For example this might be a computer on a factory floor where a hard disk might be too fragile. Finally another goal is to have a system that can be switched between different operating systems without having to reload the software. Network booting often co-exists with disk booting. For example, a system could run Windows from disk but sometimes boot Linux from the network. There are some interesting applications of this technique. For example: a friend of mine uses this to reload Windows over the network. When a Windows installation becomes corrupted, as it often does, the sysadmin can reload a fresh installation by booting Linux over the network and letting the automatic script format the disk and copy a fresh Windows installation onto it. 2.2. How does it work In order to boot over the network, the computer must get 1. an identity, 2. an operating system image and 3. usually, a working filesystem. Consider a diskless computer (DC) that has a network boot ROM. It may be one of several identical DCs. How can we distinguish this computer from others? There is one piece of information that is unique to that computer (actually its network adapter) and that is its Ethernet address. Every Ethernet adapter in the world has a unique 48 bit Ethernet address because every Ethernet hardware manufacturer has been assigned blocks of addresses. By convention these addresses are written as hex digits with colons separating each group of two digits, for example: 00:60:08:C7:A3:D8. The protocols used for obtaining an IP address, given an Ethernet address, are called Boot Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP). DHCP is an evolution of BOOTP. In our discussion, unless otherwise stated, anything that applies to BOOTP also applies to DHCP. (Actually it's a small lie that BOOTP and DHCP only translate Ethernet addresses. In their foresight, the designers made provision for BOOTP and DHCP to work with any kind of hardware address. But Ethernet is what most people will be using.) An example of a BOOTP exchange goes like this: DC: Hello, my hardware address is 00:60:08:C7:A3:D8, please give me my IP address. BOOTP server: (Looks up address in database.) Your name is aldebaran, your IP address is 192.168.1.100, your server is 192.168.1.1, the file you are supposed to boot from is /tftpboot/vmlinux.nb (and a few other pieces of information). You may wonder how the DC found the address of the BOOTP server in the first place. The answer is that it didn't. The BOOTP request was broadcast on the local network and any BOOTP server that can answer the request will. After obtaining an IP address, the DC must download an operating system image and execute it. Another Internet protocol is used here, called Trivial File Transfer Protocol (TFTP). TFTP is like a cut-down version of FTP---there is no authentication, and it runs over User Datagram Protocol (UDP) instead of Transmission Control Protocol (TCP). UDP was chosen instead of TCP for simplicity. The implementation of UDP on the DC can be small so the code is easy to fit on a ROM. Because UDP is a block oriented, as opposed to a stream oriented, protocol, the transfer goes block by block, like this: DC: Give me block 1 of /tftpboot/vmlinux.nb. TFTP server: Here it is. DC: Give me block 2. and so on, until the whole file is transferred. Handshaking is a simple acknowledge each block scheme, and packet loss is handled by retransmit on timeout. When all blocks have been received, the network boot ROM hands control to the operating system image at the entry point. Finally, in order to run an operating system, a root filesystem must be provided. The protocol used by Linux and other Unixes is normally Network File System (NFS), although other choices are possible. In this case the code does not have to reside in the ROM but can be part of the operating system we just downloaded. However the operating system must be capable of running with a root filesystem that is a NFS, instead of a real disk. Linux has the required configuration variables to build a version that can do so. 2.3. Netbooting in Practice Besides commercial boot ROMs, there are two sources for free packages for network booting. They are Etherboot and Netboot. Both can be found through the Etherboot home page. First you have to ascertain that your network card is supported by Etherboot or Netboot. Eventually you have to find a person who is willing to put the code on an EPROM (Erasable Programmable Read Only Memory) for you but in the beginning you can do network booting from a floppy. To create a boot floppy, a special boot block is provided in the distribution. This small 512 byte program loads the disk blocks following it on the floppy into memory and starts execution. Thus to make a boot floppy, one has only to concatenate the boot block with the Etherboot binary containing the driver for one's network card like this: cat floppyload.bin 3c509.lzrom > /dev/fd0 Before you put in the network boot floppy, you have to set up three services on Linux: BOOTP (or DHCP), TFTP and NFS. You don't have to set up all three at once, you can do them step by step, making sure each step works before going on to the next. I assume you have installed the bootpd server from a distribution or by compiling from source. You then have to ensure that this server is waiting for bootp requests. There are two ways to do this: one is to start bootpd as a network service that is always listening when the computer is up, and the other is to start it from inetd. For the latter, /etc/inetd.conf should contain a line like this: bootps dgram udp wait root /usr/sbin/tcpd bootpd If you had to modify /etc/inetd.conf, then you need to restart inetd by sending the process a HUP signal. Next, you need to give bootp a database to map Ethernet addresses to IP addresses. This database is in /etc/bootptab. It contains lines of the following form: aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nb Other information can be specified but we will start simple. Now boot the DC with the floppy and it should detect your Ethernet card and broadcast a BOOTP request. If all goes well, the server should respond to the DC with the information required. Since /tftpboot/vmlinux.nb doesn't exist yet, it will fail when it tries to load the file. Now you need to compile a special kernel, one that has the option for mounting the root filesystem from NFS turned on. You also need to enable the option to get the IP address of the kernel from the original BOOTP reply. You also need to compile the Linux driver for your network adapter into the kernel instead of loading it as a module. It is possible to download an initial ramdisk so that module loading works but this is something you can do later. You cannot install the zImage resulting from the kernel compilation directly. It has to be turned into a tagged image. A tagged image is a normal kernel image with a special header that tells the network bootloader where the bytes go in memory and at what address to start the program. You use a program called mknbi-linux to create this tagged image. This utility can be found in the Etherboot distribution. After you have generated the image, put it in the /tftpboot directory under the name specified in /etc/bootptab. Make sure to make this file world readable because the tftp server does not have special privileges. For TFTP, I assume that you installed tftpd from a distribution or by compiling from source. Tftpd is normally started up from inetd with a line like this in /etc/inetd.conf. tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot Again, restart inetd with a HUP signal and you can retry the boot and this time it should download the kernel image and start it. You will find that the boot will continue until the point where it tries to mount a root filesystem. At this point you must configure and export NFS partitions to proceed. For various reasons, it's not a good idea to use the root filesystem of the server as the root filesystem of the DCs. One is simply that there are various configuration files there and the DC will get the wrong information that way. Another is security. It's dangerous to allow write access (and write access is needed for the root filesystem, for various reasons) to your server's root. However the good news is that a root filesystem for the DC is not very large, only about 30 MB and a lot of this can be shared between multiple DCs. Ideally, to construct a root filesystem, you have to know what files your operating system distribution is expecting to see there. Critical to booting are device files, files in /sbin and /etc. You can bypass a lot of the hard work by making a copy of an existing root filesystem and modifying some files for the DC. In the Etherboot distribution, there is a tutorial and links to a couple of shell scripts that will create such a DC root filesystem from an existing server root filesystem. There are also troubleshooting tips in the Etherboot documentation as this is often the trickiest part of the setup. The customised Linux kernel for the DC expects to see the root filesystem at /tftpboot/(IP address of the DC), for example: /tftpboot/192.168.1.100 in the case above. This can be changed when configuring the kernel, if desired. Now create or edit /etc/exports on the server and put in a line of the following form: /tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash) The rw access is needed for various system services. The no_root_squash attribute prevents the NFS system from mapping root's ID to another one. If this is not specified, then various daemons and loggers will be unhappy. Start or restart the NFS services (rpc.portmap and rpc.mountd) and retry the diskless boot. If you are successful, the kernel should be able to mount a root filesystem and boot all the way to a login prompt. Most likely, you will find several things misconfigured. Most Linux distributions are oriented towards disked operation and require a little modification to suit diskless booting. The most common failing is reliance on files under /usr during the boot process, which is normally imported from a server late in the boot process. Two possible solutions are: 1. Provide the few required files under a small /usr directory on the root filesystem, which will then be overlaid when /usr is imported, and 2. Modify the paths to look for the files in the root filesystem. The files to edit are under /tftpboot/192.168.1.100 (remember, this is the root directory of the DC). You may wish to mount other directories from the server, such as /usr (which can be exported read-only). When you are satisfied that you can boot over the network without any problems, you may wish to put the code on an EPROM. An EPROM programmer starts at around $100 US, and is not a cost effective investment for a hobbyist who uses it sporadically. Occasionally one will appear on the used market at a bargain price, the main caveat being to ensure that the software to drive it is available. A proficient electronics hobbyist could build one using one of the several free designs published on the Internet, but for the majority of readers, the best solution is to make the acquaintance of someone who has access to one, perhaps someone in an electronics hobbyist group or working in the electronics industry. A short note on EPROM technology: The bits of an EPROM are programmed by injecting electrons with an elevated voltage into the floating gate of a field-effect transistor where a 0 bit is desired. The electrons trapped there cause that transistor to conduct, reading as 0. To erase the EPROM, the trapped electrons are given enough energy to escape the floating gate by bombarding the chip with ultraviolet radiation through the quartz window. To prevent slow erasure over a period of years from sunlight and fluorescent lights, this quartz window is covered with an opaque label in normal use. There is another technology, called EEPROM or Electrically Erasable PROM, sometimes called Flash PROM. Here the bits are cleared by an electrical signal. This obviates the need for an ultraviolet eraser if the EPROM is to be reused, but requires additional circuitry to support the erase phase. If one is handy with electronics, there is a contributed circuit design and driver software for an EEPROM board in the Etherboot distribution. The board is plugged into any spare ISA bus slot on a PC and boots a network card plugged into some other slot. 2.4. Uses of Network booting X-terminals are one natural use of network booting. The lack of a disk in the terminal makes it quieter and contributes to a pleasant working environment. The machine should ideally have 16MB of memory or more and the best video card you can find for it. This is an ideal use for a high-end 486 or low-end Pentium that has been obsoleted by hardware advances. Other people have used network booting for clusters of machines where the usage is light on the DC and does not warrant a disk, e.g. a cluster of classroom machines. 2.5. For more information Your first stop should be the Etherboot home page: There you will find links to other resources, including a mailing list you can subscribe to, where problems and solutions are discussed. 3. Begin setup 3.1. Document Changes Following are the history of changes to this document: · v0.0.3 12 Sep 1996: Some minor error fixes · v1.0.0 13 May 1999: Added some useful URLs. Changed this HOWTO to main HOWTO from mini-howto. Also rewrote this HOWTO using SGML tool. Added more chapters written by Ken Yap, Robert Nemkin. 3.2. How to set up a diskless Linux box This document is about setting up a diskless Linux box. Sometimes it might be necessary to run Linux on PC's which have neither hard disks nor floppy drives. If a network, another Unix system with bootp, tftp, an NFS server, and an eprom burner is available then it is possible to set up and operate Linux without hard/floppy disks. 3.3. Related documents · NFS-root Mini Howto · Linux NET-2/3-HOWTO by Terry Dawson, 94004531@postoffice.csu.edu.au · /usr/src/linux/README about configuring and compiling new kernels 3.4. How does it work? · 1.Diskless computer (DC) broadcasts MAC address with bootp: Who am I? · 2.Bootp or DHCP server on S looks up DB: Your IP address is X.X.X.X, your server is S, your boot file is vmlinuz.myname, etc. · 3.DC asks to load file from TFTP server on S: Please give me vmlinuz.myname · 4.S: Here you are (/tftpboot/vmlinuz.myname) DC thinks a while (booting Linux). · 5.DC: Please let me mount / with NFS · 6.S: Here is your root FS (/tftpboot/IPnumber). (In 2.2 kernels, /tftpboot/domainname.) · 7.DC: Please let me mount other NFSes (/usr, /home/, etc) · 8.S: Here you are · 9.DC: Runs intended application Network boot ROM contains code to do 1 and 3. 3.5. Hardware Whatever is described here was checked on the following configuration · Sun-OS 4.1.3 as boot server · Slackware 2.3 + Linux 1.2.8 + wd 8013 ethercard. · Working Ethernet lan 4. Fundamental ideas The fundamental idea is as follows: the PC will get its IP address from the boot server via the bootp protocol, using 0.0.0.0 as the initial IP address and its kernel via the tftp protocol. (-- Booting across segments (via router) not a simple question, so either put both the server and the diskless boxes on the same lan segment or configure an UDP helper address in your router to the address of the server. Refer to your router product manual for further info.--) For this follow the steps below. 4.1. Setting up the PC Get the nfsboot package (the package is available from your favourite linux mirror site in the /pub/Linux/system/Linux-boot directory). It contains a booteprom image for the wd8013 card which can be directly burned in. There are alternative ways to prepare the PC: · If your machine is not quite diskless, then you may use the little DOS program, or · The binary floppy image contained in the same package. If you choose the latter option you must write the image onto a floppy by the dd command. These images contain a bootp and tftp client. You need to prepare a linux kernel too, which contains the nfs-root option. · If you are using the latest stable kernel, linux-1.2.13, then you need to patch the kernel with the patchfile included in the nfsboot package (-- Refer to patch(1)--) · If you try to use the latest, but unstable kernel from the linux-1.3.x series, then you have to configure in the nfs-root option. You may or may not configure block device (floppy or hard disk) support, but you must configure tcp/ip support, wd ethernet card support, nfs filesystem support. Then recompile the kernel as usual. 4.2. Setting up a bootpd on the server It can be found in package bootpd-2.4.tar.gz (which can be found on your favourite linux mirror site in the /pub/Linux/system/Network/boot.net directory). Get the package, compile and install it. If your other Unix box happens to be a Slackware Linux then you may skip this step for the standard distributions contain a bootpd. The daemon can be run either directly by issuing command ______________________________________________________________________ bootpd -s ______________________________________________________________________ or by using inetd. In this case you need to edit: · /etc/inetd.conf to remove the hashmark from the start of these lines: ______________________________________________________________________ # tftp dgram udp wait root /usr/sbin/in.tftpd tftpd /export # bootps dgram udp wait root /usr/sbin/in.bootpd bootpd ______________________________________________________________________ · insert or uncomment the following two lines in /etc/services: ______________________________________________________________________ bootps 67/tcp # BOOTP server tftp 69/udp # TFTP server ______________________________________________________________________ · restart inetd by ______________________________________________________________________ kill -HUP . ______________________________________________________________________ 4.3. Configure the bootpd on the server First of all, bootpd have a config file called bootptab which usually resides in /etc. You must modify it by inserting the IP addresses of your gateway, dns server, and the ethernet address(es) of your diskless machine(s). An example /etc/bootptab: ______________________________________________________________________ global.prof:\ :sm=255.255.255.0:\ :ds=192.168.1.5:\ :gw=192.168.1.19:\ :ht=ethernet:\ :bf=linux: machine1:hd=/export/root/machine1:tc=global.prof:ha=0000c0863d7a:ip=192.168.1.140: machine2:hd=/export/root/machine2:tc=global.prof:ha=0800110244e1:ip=192.168.1.141: machine3:hd=/export/root/machine3:tc=global.prof:ha=0800110244de:ip=192.168.1.142: ______________________________________________________________________ global.prof is a general template for host entries, where · sm field contains the subnet mask · ds field contains the address of the Domain Name Server · gw field contains the default gateway address · ht field contains the lan media hardware type · bf field contains the name of the boot file After this, every machine must have a line: · the first field contains the host name, · hd field contains the directory of the bootfile, · the global template can be included with the tc field, · ha field contains the hardvare address of the ethernet card, · ip field contains the assigned ip address. 4.4. Understanding tftp TFTP (Trivial File Transfer Protocol) is a file transfer protocol, such as ftp, but it's much simpler to help coding it in EPROMs. TFTP can be used in two ways: · simple tftp: means that the client can acces to your whole file system. It's simpler but it's a big security hole (anyone can get your password file via tftp). · secure tftp: the tftp server uses a chroot.2 system call to change it's own root directory. Anything outside the new root directory will be completelly inaccessible. Because of the chroot dir becomes the new root dir, the hd filed in the bootptab must reflect the new situation. For example: when using insecure tftp, the hd field contains the full path to the boot directory: /export/root/machine1. When using secure tftp whith /export as root dir, then /export becomes / and the hd field must be /root/machine1. Almost every Unix implementation contains tfpt server, probably you don't need to install your own one. Install tftpd, make sure it's active in /etc/inetd.conf, typical line tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot 4.5. Kernel Image You must compile a kernel for the DC that includes NFS support and NIC driver compiled in (not modules). Answer yes to Root file system on NFS? and BOOTP support? After building the kernel, run mknbi-linux from the Etherboot distribution on it. Install this tagged image as /tftpboot/(bf attribute in bootptab). 4.6. Setting up a minimal Linux configuration on the remote server This may contain packages a, ap, n, and x of the Slackware distribution. To install more is OK; however the above packages suffice for the purposes of a diskless X terminal. For the installation you need a working Linux system. Find some disk space on the remote machine and export it read-write. Mount the exported directory onto somewhere (e.g. /mnt) on the file system of the Linux box. Start Linux setup and change the root option in the setup from / to /mnt. Then setup the above packages as usual. If you want to run no more than one diskless Linux then no changes are needed. On the other hand, if you plan to use more than one diskless machine then the above setup will not work because some files and directories must be private to the machines. The problem can be bypassed by moving the /usr (it contains no private data) and then create a separate subdir for each diskless machine. For example, if /export/linux/machine1 were mounted to /mnt then the directory structure after the initial setup will look like ______________________________________________________________________ /export/linux/machine1/bin /export/linux/machine1/sbin /export/linux/machine1/lib /export/linux/machine1/etc /export/linux/machine1/var /export/linux/machine1/usr ______________________________________________________________________ After the changes you will have ______________________________________________________________________ /export/linux/machine1/bin /export/linux/machine1/sbin /export/linux/machine1/lib /export/linux/machine1/etc /export/linux/machine1/var /export/linux/usr ______________________________________________________________________ Now create the subdirectories for the other machines. Assume for now that your diskless machines are called machine1, machine2, machine3, etc.; then you may use the following bash script to setup the other directories ______________________________________________________________________ cd /export/linux for x in machine2 machine3 ; do mkdir $x; cd $x (cd ../machine1; tar cf - *) | tar xvf - done ______________________________________________________________________ Then do the following export: · /export/linux/usr readonly for everyone. · /export/liunx/machine1 only to machine1 with rw,root rights. · /export/liunx/machine2 only to machine2 with rw,root rights. · /export/liunx/machine3 only to machine3 with rw,root rights. as follows (-- the format of this example follows the SunOs 4.1.3 exports file syntax--) : ______________________________________________________________________ # This file is /etc/export # for remote linux X terminals by Buci # this line is only once /export/root/usr -access=linuxnet # these lines once for every host /export/root/machine1 rw=machine1,root=machine1 /export/root/machine2 rw=machine2,root=machine2 /export/root/machine3 rw=machine3,root=machine3 ______________________________________________________________________ Don't forget to run exportfs -a. 4.7. Configuring the tftp server Now it is time to configure the tftp server. If you do not need secure tftp then everything is quite simple for your clients can be booted from the /export directory. If a secure tftp is used then you can either make a full /export/linux directory structure under /tftpboot (with a single real kernel and symbolic links for the other machines), or let the /export directory be the boot directory of the secure tftpd. Or, if you have a separate tftpboot directory then, similarly, you need only the original directory structure with a single kernel and symbolic links for the others. You can achieve this setup by typing the following: ______________________________________________________________________ mkdir -p /tftpboot/export/linux/machine1 cd /tftpboot/export/linux/machine1 cp /export/linux/machine1/ . ______________________________________________________________________ Then type the following: ______________________________________________________________________ mkdir -p /tftpboot/export/linux/machine2 cd ../machine2 ln -s ../machine2/ ______________________________________________________________________ 4.8. Final work Finally, you must insert ______________________________________________________________________ /sbin/mount nfs_server:/export/linux/usr /usr ______________________________________________________________________ as the first line of ______________________________________________________________________ /export/linux//etc/rc.d/rc.S ______________________________________________________________________ where stands for machine1, machine2, etc. 4.9. Net Loader A small program that runs as a BIOS extension, usually on an EPROM on the NIC. It handles the BOOTP query and TFTP loading and then transfers control to the loaded image. It uses TCP/IP protocols but the loaded image doesn't have to be Linux. The loaded image can be anything, even DOG. There are two free implementations of TCP/IP net loaders: Etherboot and Netboot : Etherboot uses built-in drivers while Netboot uses Packet drivers. They can also be loaded from a floppy for testing and for temporary setups. 4.10. RH5 configuration The DC requests to mount /tftpboot/(IP address of DC) (in 2.1 and above: /tftpboot/(name of DC in bootptab) ) as its / by NFS from server. You must export this from the server (rw, no_root_squash) because the DC wants to write on it (log files, etc). The / must contain /sbin, /bin, /lib, /etc, /var, /tmp, /root, /dev and /proc. /sbin, /bin, /lib/ can be a copy of an existing RH5 system. They can be shared between all DCs. But hard links only. BTW, don't link to server originals. /etc, /var and /dev should be non-sharable copies. Customise /etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-eth0, /etc/fstab, /etc/conf.modules, and others. Turn off all network services you don't need. Remove all stuff you don't need from /var, e.g. RPM db, lpd files. /root and /proc should just exist. /tmp should exist and be mode 1777. You probably want to create /usr and /home mount points. /usr can be mounted ro. About 10 MB per DC plus about 15 MB of shared files should be sufficient. BTW: if your DCs are quite similar, the kernel image can also be shared. Here is an illustrative script to create the first root filesystem. #!/bin/sh if [ $# != 1 ] then echo Usage: $0 client-IP-addr exit 1 fi cd / umask 022 mkdir -p /tftpboot/$1 # just make these ones for d in home mnt proc tmp usr do mkdir /tftpboot/$1/$d done chmod 1777 /tftpboot/$1/tmp touch /tftpboot/$1/fastboot chattr +i /tftpboot/$1/fastboot # copy these ones cp -a bin lib sbin dev etc root var /tftpboot/$1 cat <company->Hardware->Peripherals->Device programmers. Click on this site · Yahoo URL for EPROMs at · Advanced Research Technology B.V - development, production and sales of electronic programmer equipment; development of hard- and software. · Advin Systems Inc. - PC-based device programmers that support the latest in package types and device technologies. · Andromeda Research Labs - manufactures a portable eprom and device programming system. · B and C Microsystems, Inc - offers test and duplication/programming equipment for PCMCIA (PC) Cards, ISA/PCI Cards, SIMMs, Memory Devices (including FLASH), PLDs. · BP Microsystems - Device Programmers. · Bytek - designs, develops, manufactures and markets micro-processor-based, modular electronic systems used to program and test semiconductor devices. Product line includes the ChipBurner. · Concentrated Programming Ltd - offers a full range of device programming solutions. · Dataman Programmmers Ltd. - manufacture of hand-help EPROM programmer/emulator. Also sell PC-based programmers, and Gang-Pro programmers. · General Device Instruments - IC Device programmers. Universal and Gang programmers for Pld, Flash, microcontrollers, Proms, EEproms, Memory, Epld, Mach and many other ic devices. · HI-LO System Research Co., Ltd. - manufacturer of universal and gang device programmers. · ICE Technology - EPROM and universal device programmers which support memories, microcontrollers, and programmable logic devices. · Iceprom - in-circuit erasable programmable read-only memory. · Incept Ltd. · International Microsystems Inc - High speed reliable gang programmer. (PROM, FLASH, Microcontroller, PCMCIA memory card). · JED Microprocessors Pty. Ltd. - plugs into a PC printer port D25 connector, and programs any 28-pin or 32-pin EPROM and FLASH device. · Logical Devices, Inc - device programming for PLDs, FPGAs, PROMs, microcontrollers. Producers of CUPL compiler for programmable logic and the ALLPRO and Chipmaster device programmer. · MCL Systems - new method not only for programming but also for developing your new hardware with Integrated Controller Unit. And you don't need to be an expert. · MQP Electronics - manufacturer of universal device programmers, gang programmers, production software, and package converters. High thoughput and reliability. · Needham's Electronics - manufacturer of device programmers. · NP Programming Services - provides programming for memory and logic parts. · Program Automation, Inc. - independent service company specializing in high volume PROM programming, including flash I/Cs. · Stag Programmers Inc - manufacturer of prom and logic programmers, production handling equipment and UV erasers. · Sunrise Electronics - universal device programmers, gang and in-circuit programmers with life time support. · System General Co. - Device Programmer, EPROM Writer and IC Tester · Tribal Microsystems - universal and gang device programmers, 8051 and EPROM emulators, test and burn-in sockets and production sockets. · Universal Device Programmers 6.2. Non-Volatile Memory chips This chapter gives brief descriptions of memory chips. · PROM: Pronounced prom, an acronym for programmable read-only memory. A PROM is a memory chip on which data can be written only once. Once a program has been written onto a PROM, it remains there forever. Unlike RAM, PROMs retain their contents when the computer is turned off. The difference between a PROM and a ROM (read-only memory) is that a PROM is manufactured as blank memory, whereas a ROM is programmed during the manufacturing process. To write data onto a PROM chip, you need a special device called a PROM programmer or PROM burner. The process of programming a PROM is sometimes called burning the PROM. An EPROM (erasable programmable read-only memory) is a special type of PROM that can be erased by exposing it to ultraviolet light. Once it is erased, it can be reprogrammed. An EEPROM is similar to a PROM, but requires only electricity to be erased. · EPROM: Acronym for erasable programmable read-only memory, and pronounced ee-prom, EPROM is a special type of memory that retains its contents until it is exposed to ultraviolet light. The ultraviolet light clears its contents, making it possible to reprogram the memory. To write to and erase an EPROM, you need a special device called a PROM programmer or PROM burner. An EPROM differs from a PROM in that a PROM can be written to only once and cannot be erased. EPROMs are used widely in personal computers because they enable the manufacturer to change the contents of the PROM before the computer is actually shipped. This means that bugs can be removed and new versions installed shortly before delivery. · EEPROM: Acronym for electrically erasable programmable read-only memory. Pronounced double-e-prom or e-e-prom, an EEPROM is a special type of PROM that can be erased by exposing it to an electrical charge. Like other types of PROM, EEPROM retains its contents even when the power is turned off. Also like other types of ROM, EEPROM is not as fast as RAM. EEPROM is similar to flash memory (sometimes called flash EEPROM). The principal difference is that EEPROM requires data to be written or erased one byte at a time whereas flash memory allows data to be written or erased in blocks. This makes flash memory faster. · FRAM: Short for Ferroelectric Random Access Memory, a type of non- volatile memory developed by Ramtron International Corporation. FRAM combines the access speed of DRAM and SRAM with the non- volatility of ROM. Because of its high speed, it is replacing EEPROM in many devices. The term FRAM itself is a trademark of Ramtron. · NVRAM: Abbreviation of Non-Volatile Random Access Memory, a type of memory that retains its contents when power is turned off. One type of NVRAM is SRAM that is made non-volatile by connecting it to a constant power source such as a battery. Another type of NVRAM uses EEPROM chips to save its contents when power is turned off. In this case, NVRAM is composed of a combination of SRAM and EEPROM chips. · Bubble Memory: A type of non-volatile memory composed of a thin layer of material that can be easily magnetized in only one direction. When a magnetic field is applied to circular area of this substance that is not magnetized in the same direction, the area is reduced to a smaller circle, or bubble. It was once widely believed that bubble memory would become one of the leading memory technologies, but these promises have not been fulfilled. Other non-volatile memory types, such as EEPROM, are both faster and less expensive than bubble memory. · Flash Memory: A special type of EEPROM that can be erased and reprogrammed in blocks instead of one byte at a time. Many modern PCs have their BIOS stored on a flash memory chip so that it can easily be updated if necessary. Such a BIOS is sometimes called a flash BIOS. Flash memory is also popular in modems because it enables the modem manufacturer to support new protocols as they become standardized. 7. Etherboot 7.1. Introduction This is the README file for the Etherboot package. This document explains how to install, configure and use the Etherboot package. The instructions here apply to version 4.0 of Etherboot. Etherboot is a package for creating ROM images that can download code over the network to be executed on an x86 computer. Typically the computer is diskless and the code is Linux, but these are not the only possibilities. The code uses the bootp, tftp and NFS Internet Protocols. 7.1.1. What hardware is supported? Etherboot supports the following network hardware (in no particular order): 3c503, 3c507, 3c509, 3c905b, NE1000, NE2000 (also the PCI cards, with the nepci driver), WD8003, WD8013, SMC8216/8416, Lance based cards such as the NE2100 and NI6510 (also the PCI Lance cards), Crystal CS89x0, Intel EtherExpress Pro, SMC 83c170 EPIC/100, SMC9000, Realtek 8139, NI5210, Schneider and Koch G16, and Tiara (Fujitsu Lancard). All Etherboot drivers are autoprobing, which means they attempt to detect the hardware addresses at which the card is installed. It's fairly easy to write a driver if you are familiar with Ethernet hardware interfacing. Please contact me for more information if you are interested in doing so or are interested in having a driver written. 7.1.2. Availability of this document This document and related documents are also kept online at the Etherboot Home Page . This will in general have the latest distributions and documentation. For a talk/tutorial type introduction to what Etherboot does and how to set it up, see my SLUG talk . You may wish to review this before reading further. An older version of this README, which is now out of date, can be accessed via this link . 7.1.3. Getting help There is a mailing list for all netbooting related issues. To subscribe follow the instructions on the Etherboot home page . With the exception of the following section, the information on diskless booting is not specific to Etherboot but can be used for the Netboot package also. 7.2. Unpacking, compiling and testing the package This section is Etherboot specific. 7.2.1. Unpacking the distribution Unpack the distribution using gunzip and tar, using either of the following commands: ______________________________________________________________________ tar zxvf etherboot-4.0.tar.gz gunzip < etherboot-4.0.tar.gz | tar xvf - ______________________________________________________________________ 7.2.2. Compiling the ROM images Precompiled ROM images are provided in the bin/ directory but you may wish to review the options compiled in and make your own versions. For the 32 bit version you need a recent release of gcc and the binutils tools. This package was compiled with the tools from a RedHat 5.2 distribution but it should work with any recent Linux distribution. For the 16 bit version you need the bcc tools from the Embedded Linux Kernel Subset (ELKS) project, for more details see the notes on 16 bit Etherboot <16.html>. You need the 16 bit version only if you intend to run Etherboot on a 286 or 086/088 PC. Assuming you have decided to make the 32 bit version, you only have to go to src-32/, edit the options in Config and say make. This will create all the ROM images available. The .lzrom images are the same as the .rom images. Since the .lzrom images are smaller and work exactly the same, there is no real reason to use .rom images any more, unless you are nervous about compression algorithm patents. We believe the algorithm used does not infringe patents, having been in public use for some time, but we do not know all the legal ramifications. See here for more details. Here is a brief description of the options available: ______________________________________________________________________ Basic options: -DDHCP_SUPPORT - Use DHCP instead of BOOTP (default on) -DIMAGE_MENU - Allow to interactively chose between different bootimages; read vendortags.html for further information. -DMOTD - Display message of the day; read vendortags.html for further information. -DANSIESC - evaluate a subset of common ANSI escape sequences when displaying the message of the day; this probably does not make sense unless you also define -DMOTD or at least -DIMAGE_MENU. Combining this option with -DSERIAL_CONSOLE is a waste of EPROM space. -DGFX - support extensions to the ANSI escape sequences for displaying graphics (icons or logos); this requires -DANSIESC -DASK_BOOT=n - Ask "Boot from Network or from Local? " at startup, timeout after n seconds (0 = no timeout); this can be done in a more generic way by using the IMAGE_MENU, but it requires that the "bootp" server is accessible, even when booting locally. -DANS_DEFAULT=ANS_NETWORK - Assume Network to previous question (alternative: ANS_LOCAL) on timeout or Return key See etherboot.h for prompt and answer strings. -DEMERGENCYDISKBOOT - if no BOOTP server can be found, then boot from local disk. The accessibility of the TFTP server has no effect, though! So configure your BOOTP server properly. Basic options only on Etherboot/32: -DPASSWD - enable password protection for boot images; this requires -DIMAGE_MENU -DUSRPARMS - allow the user to interactively edit parameters that are passed to the booted kernel; you should probably enable -DPASSWD as well; this feature requires -DIMAGE_MENU -DFLOPPY - boot from floppy/hd if bootimage matches the pattern "/dev/[fh]d*"; if you do not have enough space in the EPROM, then disable this feature and use "mknbi-blkdev" for booting from a local blockdevice. -DCONFIG_PCI_DIRECT - define this for PCI BIOSes that do not implement BIOS32 or not correctly These options should normally not need to be touched: -DNOINT19H - Take control as soon as BIOS detects the ROM Normally hooks onto INT19H -DMOVEROM - if your motherboard does not cache adapter memory space, then this option can speed up loading of compressed BOOT-Prom images. It has no effect on uncompressed images. Unless you are very tight on free space, you will usually want to define this option. -DDELIMITERLINES - print a line of = characters at the start and also just before starting an image. -DSIZEINDICATOR - update a running total of the amount of code loaded so far, in kilobytes -DT509HACK - send two bootp packets before waiting for a reply to the first. Makes a 3c509 do bootp quicker -DT503_AUI - Use AUI by default on 3c503 cards. These options are only for a serial console for Etherboot/32: -DSERIAL_CONSOLE- use a serial line for input and output -DCOMPORT - 0x0 for COM1, 0x1 for COM2 etc -DCOMPARM - configuration for COMPORT, save values: 0xe3 == 9600/8n1, 0xa3 == 2400/8n1 ______________________________________________________________________ 7.2.3. Testing the ROM images You can test the image with a floppy before burning an EPROM. On Linux just put a blank floppy in fd0 and say make card.fd0 where card is the name of your network card and it will copy a bootable image onto the floppy. If you wish to do this by hand, it's easy, just prepend floppyload.bin to card.rom (or card.lzrom) and write this combined binary to the floppy raw, i.e. starting at the boot block. Like this: ______________________________________________________________________ cat floppyload.bin 3c509.lzrom > /dev/fd0 ______________________________________________________________________ When you boot with this floppy it will load the Etherboot ROM image from floppy and execute it. It should be able to detect your card. To get the bootrom to acquire an IP address and load the intended code, you need to set up bootp, tftp and NFS services, which we will discuss next. We suggest you continue to use floppy booting until you have completed the setup of the server and are satisfied that diskless booting works. 7.3. Setting up a diskless boot In this section I assume you want to boot a Linux kernel. Booting a DOS kernel is similar, the main differences being in the way you set up the tagged image. 7.3.1. Making a 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 and that for DOS is mknbi-dos. These utilities are found in the netboot- directory of the distribution. 7.3.2. Compiling a custom kernel You will probably have to compile a custom kernel because the kernel needs to have the "Root file system on NFS" option compiled in. You should also select "BOOTP support". "RARP support" is not needed. In 2.2 kernels you have to enable the "Kernel Autoconfig" option to access the BOOTP support question. And unless you are using an initrd (initial ramdisk) you will probably 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 -x -k zImage -o /tftpboot/vmlinuz.xterm ______________________________________________________________________ Then put the tagged image in where the tftp daemon expects to find it, typically /tftpboot. Make sure it is world-readable because typically the tftp daemon runs as an unprivileged user. 7.3.3. Setting up a bootp daemon Now set up a bootp daemon. In RedHat 5.2 this means installing the bootp RPM package, making sure that the bootps service is active in /etc/inetd.conf, and editing /etc/bootptab. The essential pieces of information you need to put in bootptab are: 1. The domain name of the machine. 2. The Ethernet (MAC) address of the network card, which you generally obtain from a sticker on the card, a configuration program for the card, or in the last resort, from watching the output of Etherboot or from the packets sent from the card when trying to boot, using the debug option of bootpd. 3. The name of the tagged image file, relative to the tftpboot directory. 4. The IP address you intend to give it. 5. The IP addresses of various servers. You will need at least the tftp server's address. Here is an example of a /etc/bootptab for the bootpd supplied with RedHat Linux 5.2 and probably many versions of Unix: ______________________________________________________________________ .default:\ :ht=ethernet:\ :hd=/tftpboot:bf=null:\ :ds=nameserver:\ :hn:to=36000: xterm.ken.net.au:tc=.default:ha=08002BB7F380:ip=192.168.26.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. 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. 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). 7.3.4. Setting up a DHCP daemon As an alternative to bootp, you could set up a DHCP server which has the advantage of automating the handing out of IP addresses. However the kernel may still do a bootp request to find the IP address for mounting the NFS filesystem. You may then wish to investigate the option in mknbi-linux which tells the kernel to take the address from the initial DHCP reply. More information about DHCP can be found at the DHCP FAQ Web Page . 7.3.5. Setting up a tftp daemon Now set up a tftp daemon. In RedHat 5.2 this means installing the tftp RPM package and making sure that the tftp service is active in /etc/inetd.conf. You probably want to use the secure (-s) option so that files can only be fetched from /tftpboot or people may be able to fetch arbitrary files from your server. 7.4. Testing the network booting Now when you start up Etherboot, it should obtain an IP address and print out what it received. If you do not get this to work, turn on debugging in bootpd and see if any query was received. If not, check your network hardware (cables, etc). If a query was received, check if bootpd was able to give an answer. If not, then the Ethernet address was not found in /etc/bootptab. If a reply was sent, then only faulty hardware or a bug in Etherboot would prevent it being received by Etherboot. Assuming an IP address was received, the next thing Etherboot tries to do is load a file using tftp. Check your system logs to see if a tftp daemon was started up and a file requested. Generally if you run tftpd under tcpwrapper security, a log entry will be generated. If not, it could be a path problem or file permission problem (the file needs to be readable by tftpd). Fix the problem. After the tagged image is loaded, Etherboot will jump to it. If it crashes here, check that the image is a tagged image. If it executes and stops at the point where it's trying to mount the NFS root, then you need to check that you have the "root on NFS" option compiled in and that you have compiled in the network card driver. 7.4.1. Setting up a NFS root filesystem Now you need to set up a NFS root filesystem for the diskless computer. Typically this is under /tftpboot/. (In 2.1 and presumably future kernels, this should be /tftpboot/). This needs to contain a complete root filesystem that will make the kernel boot happily. This means, for most kernels, it should contain /dev, /proc, /etc, /sbin, /bin, /tmp and /var. The details vary from distribution to distribution. Being lazy I just make a copy of the necessary files from an existing RedHat 5.2 filesystem and modify some key files appropriately. You can find a description in my tutorial and some shell scripts to copy the files. Since the amount of disk space needed is relatively small in these days of large disks, I don't bother to throw out things that may not be needed. Warning: Do not attempt to reuse the root filesystem of your server, whether by exporting it directly or by making hard links (symbolic links will not work). First of all, the configuration files will contain information pertaining to the server, not the client, so your client will get the wrong information. Secondly, this is a security risk. NFS is already not totally safe, but this way you are directly exposing your server root to clients. Even if you make hard links, the clients could (maliciously or accidentally) overwrite key binaries, making the server unusable. Don't try to save a few megabytes of disk space this way. You can however share some directories between clients, typically /sbin, /bin and /lib. The sample scripts in the tutorial show you how. The root filesystem should be exported rw and no_root_squash because the various processes need to be root and need to write to log files in the root partition. You may wish to export /usr and /home filesystems to the diskless computer also. These do not need no_root_squash permission. Be aware that the RedHat 5.2 distribution has a few "bugs" relating to symlinks and so forth for diskless booting. These are mentioned in the tutorial. Other distributions may have similar problems. 7.4.2. Swap over NFS Swap over NFS can be arranged but you have to patch the kernel source. There is a patch for kernels in the contrib/ directory for 2.0.x kernels. Hopefully this will make it into future kernels. Be aware that opinions are divided on NFS swap. Some people think it's a bad thing because it just kills the network if you have lots of diskless computers and that you shouldn't be running into a swap regime on a diskless computer anyway. Some other people like having a bit of insurance. There are patches in the contrib directory for NFS swap but for up to date patches, try here < http://www.math1.rwth-aachen.de/~heine/nfs- swap/>. Also have a look at the NBD Network Block Device web page for swapping over that. This requires a 2.1 or 2.2 kernel. 7.5. Booting DOS What about DOS? The deal with DOS is that one is loading a virtual floppy called A: into extended memory and then booting from this floppy. So you have to capture an image of a bootable DOS floppy first. Some more details can be found in the mknbi-dos directory. I have booted DOS (both M$ and DR versions) diskless this way. Note that extended memory is used so that rules out 086/088 computers but 286s are ok. See this document for more details. If you were thinking of booting a Windows machine via the network, it seems (I'm not masochistic enough to do this) the problem is not the network booting but the mounting of a file system over NetBIOS (Windows does not do remote mounts of root filesystems over NetBIOS on TCP). So that rules out a Samba server. It appears to be possible over a Netware server, for which Linux has workalikes. But then what do you do about the networking stack? This situation may change with with future Samba developments. But you will still have problems with pathnames and the usual Windows hassles. Do you really want to do this? In the Web page for Etherboot , there is a link to someone's Web page explaining how this was done with a commercial TCP/IP boot ROM. 7.6. Making an Etherboot EPROM or EEPROM Assuming you have satisfactorily set up your server environment, you may now wish to put the Etherboot onto an EPROM or EEPROM. Naturally this assumes access to hardware to burn (and possibly erase) EPROMs. An alternative is to use an EEPROM card. There is a schematic and PCB artwork for such a card in the distribution. This EEPROM card plugs onto the ISA bus and can be reprogrammed with software. 7.6.1. Choosing the EPROM Most network cards come with a blank (E)EPROM socket even though it is seldom used. When it is used, it is typically filled with a proprietary EPROM from the network card manufacturer. You can put an Etherboot EPROM there instead. 7.6.2. Enabling the EPROM First you must discover how to enable the EPROM socket on your card. Typically the EPROM is not enabled at the factory and a jumper or a soft configuration is used to turn it on. 7.6.3. Size and speed of the EPROM Secondly, you must discover what size and speed of EPROM is needed. This can be difficult as network card manufacturers often neglect to provide this information. The smallest EPROM that is accepted by network cards is an 8K EPROM (2764). Some cards will even go up to 64KB EPROMs (27512). You want to use the smallest EPROM you can so that you don't take up more of the upper memory area than needed as other extensions BIOSes may need the space. However you also want to get a good price for the EPROM. Currently the 32KB and 64KB EPROMs (27256 and 27512) seem to be the cheapest per unit. Smaller EPROMs appear to be more expensive because they are out of mainstream production. If you cannot find out from the documentation what capacity of EPROM your card takes, you could do it by trial and error. Take an ROM with some data on it (say a character generator ROM) and plug it into the socket. Be careful not to use an extension BIOS for this test because it may be detected and activated and prevent you from booting your computer. Using the debug program under DOS, dump various regions of the memory space. Say you discover that you can see the data in a memory window from CC00:0 to CC00:3FFF (= 4000 hex = 16384 decimal locations). This indicates that a 16 KB EPROM is needed. However if you see an alias in parts of the memory space, say the region from CC00:0 to CC00:1FFF is duplicated in CC00:2000 to CC00:3FFF, then you have put an 8 KB EPROM into a 16 KB slot and you need to try a larger EPROM. Note that because pinouts for 28 pin EPROMs are upward compatible after a fashion, you can probably use a larger capacity EPROM in a slot intended for a smaller one. The higher address lines will probably be held high so you will need to burn the image in the upper half or upper quarter of the larger EPROM, as the case may be. However you should double check the voltages on the pins armed with data sheet and a meter because CMOS EPROMs don't like floating pins. The speed of the EPROM needed depends on how it is connected to the computer bus. If the EPROM is directly connected to the computer bus, as in the case of many cheap NE2000 clones, then you will probably have to get an EPROM that is at least as fast as the ROMs used for the main BIOS. This is typically 150 ns. Some network cards mediate access to the EPROM via an ASIC and this ASIC may insert wait states so that slower EPROMs can be used. Incidentally the slowness of the EPROM doesn't affect Etherboot execution speed much because Etherboot copies itself to RAM before executing. I'm told Netboot does the same thing. 7.7. Troubleshooting tips · Floppy boot doesn't work. Have you copied the ROM image (with the floppyloader prepended) to the floppy raw? Is that size of floppy bootable by your computer? Are you trying to run a 32 bit Etherboot on a 16 bit machine (286, 086/088)? Have you selected too many compile time options? The real limit on Etherboot is not the size of the EPROM but the fact that it executes in the 32 KB region between 0x98000 and 0xA0000. If the sum of code, stack and bss is greater than 32 KB, then Etherboot might crash at unexpected places. You could increase the memory to 48 KB by lowering the RELOCADDR in the Makefile but this is outside the specifications. Definitely do not lower RELOCADDR below 0x94000 because various pieces of booting information are stored from 0x90000 upwards. · Floppy version works but EPROM version doesn't work. There is a program called rom-scan (Linux and DOS versions) in the directory contrib/rom-scan which will help detect problems. · If the EPROM is not detected at all then the contents of the EPROM are not visible to the BIOS. Check that you have enabled the EPROM with any jumpers or soft configuration settings. Check that you do not have any conflicts in the memory address of the EPROM and any other hardware. Perhaps you have to prevent it from being mapped out by your BIOS settings. Or perhaps you have to shadow it with RAM. Maybe you put the code in the wrong half or wrong quarter of the EPROM. Maybe the access time of the EPROM is not low enough. You can also use the debug program under BIOS to examine the memory area in question. · If rom-scan says the EPROM is present but not active, then something prevented the BIOS from seeing it as a valid extension BIOS. This could be truncation of the EPROM window, maybe you have a larger EPROM in a slot meant for a smaller one. Maybe there is a checksum error in the EPROM due to some bits not properly programmed or the EPROM not being fast enough. In one case that we know of, the 3c503 network card, the ASIC actually returns 2 bytes of 80 80 in the end locations of the EPROM space. This apparently is a kind of signature. The makerom program in Etherboot compensates for this, but if the pattern is not 80 80, then the code needs to be modified. · If rom-scan says the EPROM is present and active, but BIOS does not see it, then perhaps the EPROM is located in an area that the BIOS does not scan. The range scanned is supposed to be 0xC0000 to 0xEF800 in increments of 2 KB but I have seen some BIOSes that continue the scan into the 0xF0000 page. Note that rom-scan will also detect other extension BIOSes mounted on your computer, for example VGA BIOSes and SCSI adapter BIOSes. This is normal. · Etherboot does not detect card. Are you using the right ROM image? Is the card properly seated in the computer? Can you see the card with other software? Are there any address conflicts with other hardware? Is the PCI id of the card one that is not known to Etherboot yet? In this case and where you think there is a bug in Etherboot, please contact the author with all details. · Etherboot detects card but hangs computer after detection. Some cards are booby traps while they are enabled. The typical offenders are NE2000s which will hang the bus if any access is made to the reset addresses while interrupts are active. You may need to do a hard reset of the computer, i.e. power down and up again before running Etherboot. · Etherboot detects card but does nothing after saying Searching for server. Check your network hardware. Did you select the right hardware interface (AUI, BNC, RJ45)? Is the cabling ok? If you have a Unix computer on the network and have root privileges, you could run tcpdump looking for broadcast packets on the bootps port. If the requests are getting sent out but no replies are getting back, check your bootpd setup. Also check if the server has a route to the client. · Etherboot obtains IP address but fails to load file. Check the tftp server. Is the tagged image file installed? Is the file world readable? Did you put the right home directory and boot filename in bootptab? · Etherboot loads file via tftp but Linux fails to boot. This is a large category. Here are some suggestions: · You do not have a private copy of the /, /etc, /var, ... directories · Your /dev directory is missing entries for /dev/zero and/or /dev/null or is sharing device entries from a server that uses different major and minor numbers (i.e. a server that is not running Linux). · Your /lib directory is missing libraries (most notably libc* and/or libm*) or does not have the loader files ld*.so* · You neglected to run ldconfig to update /etc/ldconfig.cache or you do not have a configuration file for ldconfig. · Your /etc/inittab and/or /etc/rc.d/* files have not been customized for the clients. · Your kernel is missing some crucial compile-time feature (such as NFS filesystem support, booting from the net, transname (optional), ELF file support, networking support, driver for your ethernet card). · Missing init executable (in one of the directories known by the kernel: /etc, /sbin, ?). Remember /sbin/init must be a real file, not a symlink. · Missing /etc/inittab · Missing /dev/tty? · Missing /bin/sh · System programs that insist on creating/writing to files outside of /var (mount and /etc/mtab* is the canonical example) The essence is that you must provide whatever is needed in the NFS root filesystem that your kernel needs to boot. This is somewhat distribution dependent. In the discussion above I solved the problem by making a copy of an existing root filesystem and modifying a few bits. Be aware that some, if not all, distributions contain bugs in their layout that hinder diskless mounting so you will have to fix any problems that arise. An example was a directory in /usr/X11R6/lib that needed to be writable, preventing /usr from being mounted ro. · Etherboot works fine and kernel starts but network interface doesn't work. Check your network configuration in the OS. Etherboot uses polled I/O and not interrupt I/O to fetch the images. So the IRQ line doesn't get exercised. This manifested itself in one case with a NIC that could netboot but network programs run afterwards couldn't receive any packets. It seemed to be a combination of a weak NIC IRQ line and a fussy motherboard. But the same thing could happen if say the IRQ is not set to where the software is expecting it. The image will load fine with the wrong IRQ but the software will not run properly. This is more of an issue with say DOS packet drivers, where the user has to specify the IRQ line than with Linux, which autoprobes. 7.8. Acknowledgements The following people have contributed substantially to Etherboot. If you feel your name has been left out, just let me know and I will fix it up. Markus Gutschke Co-author of Etherboot. He was the person who ported the Netboot suite from FreeBSD. He has enhanced Etherboot with many features, one new driver and has contributed various utilities and addons. Gero Kuhlmann The mknbi utilities used by Etherboot are from Netboot. He has also clarified the original specification by Jamie Honan. Jamie Honan Jamie started Netboot off by writing the first version that used code from a packet driver. Martin Renters et. al The original authors of Netboot on FreeBSD. Bruce Evans Created bcc compiler used by Etherboot/16. Rob de Bath Current maintainer of bcc and associated tools like as86. Gerd Knorr Contributed MASQ for making a boot floppy without DOS. Adam Richter Contributed comboot for making a boot floppy without DOS. Claus-Justus Heine Contributed patch for serial console and NFS swapping. See the contrib/nfs-swap directory for his Web page. Dickon Reed Contributed display of loading status and a hack for the 3c509 card. David Munro Contributed PCI detection code originally from Linux sources. Charlie Brady Donated NE2100 card so that a driver could be written, and helped test the LancePCI driver. Spotted bug with 4.1 header code. Rogier Wolff Created Intel EtherExpressPro 100 driver and binary to hex converter. Vlag Lungu Contributed patches to work with DHCP. Also contributed a fix to match the received XID against the transmitted one, important in a network with many requesters. William Arbaugh Patches for eepro to work with 3.2. Jean Marc Lacroix Contributed an improved bin2intelhex. Jim Hague Contributed fixes to 3c503 driver for PIO mode, fix to makerom for presetting EPROM bytes, and various endian fixes. Andrew Coulthurst Contributed patch for making Intel eepro work in 4.0. Doug Ambrisko Contributed patches to start32.S from FreeBSD version to make it boot Windoze after answering N to Boot from Network question. Alex Harin Contributed patches for prepended loaders and makerom to make bootrom PnP and PCI compatible. Peter Dobcsanyi Contributed vendor and device IDs for the Netvin NE2000/PCI clone. adam@mudlist.eorbit.net Contributed RARP code as alternative to BOOTP/DHCP. Activated by RARP_NOT_BOOTP define. Daniel Engstrom Contributed a SMC9000 driver. Didier Poirot Contributed an Etherpower II (EPIC 100) driver. Martin Atkins Contributed mntnbi for mounting DOS NBIs. Atilla Bogar Contributed a bug fix to the bootmenu code and a patch to main.c to remove looping menus on failure. Also code for ARP replies and TFTP retransmit (#ifdefed). Cleanup of tftp and tftpd. Nathan R. Neulinger Found bug due to tu_block being declared signed short in arpa/tftp.h on many platforms when it should be unsigned short. David Sharp Contributed a FreeBSD driver for Tulip based cards. Ken Yap ported it to Etherboot. Not tested because code needs to be written for all the variants of the Tulip and also because no hardware available to me. Greg Beeley Contributed a 3c905b driver. Be sure to read the release notes in 3c905b.txt before using. Alex Nemirovsky Contributed patches to use BIOS call to size memory otherwise Etherboot was trampling on top of 640kB area, which is used by some extended BIOSes. Also contributed patches to pci.c to implement PCI bus support on BIOSes that do not implement BIOS32, or incorrectly. Guenter Knauf Suggested making the ASK_BOOT prompts more generic and clearer. (Why doesn't SGML-Tools accept üaut;?) Also contributed a DOS utility for extracting the identifier string and PCI IDs, if any, out of the boot ROM. Klaus Espenlaub Contributed various cleanup patches to the code especially in the bootmenu area, as well as a completely revamped start32.S. Also introduced Rainer Bawidamann's code, see next paragraph. Rainer Bawidamann Contributed a Realtek 8139 driver. Georg Baum contributed a Schneider & Koch G16 driver. jluke@deakin.edu.au sent in a fix for the WD/SMC8013 which I finally verified. 7.9. Copyright The boot code from FreeBSD is under the BSD license. The netboot code is under the GPL. This is not a problem really: the GPL states that mere aggregation of another work with a GPL'ed work on a storage medium, e.g. an archive file, does not put the other work under the GPL. Send changes to this document to Ken Yap (ken.yap@acm.org). 8. Netboot This chapter was written by Zurück zu Gero. The main site is at . 8.1. Introduction What do I need it for? The following list shows just a few examples of what Netboot can be used for: · Printer spooler · Terminal server · X11 terminal · Data logging system · Network-Computer (NC) · Some more .... Basically Netboot can be used for any cases in which a computer should be utilized without having a hard disk. But also for computers with a hard disk Netboot can be used if you want to hold just one operating system on your disk and additionally want to be able to boot a different system over the network. What operating systems are supported? Presently Netboot can boot Linux and MS-DOS. Since Windows-95 is also based on MS-DOS that can be used as well. In the future support is also planned for OS/2 and Free-BSD. However, Windows-NT will never be supported. The utility programs, which come with Netboot should run on an UNIX like system. What do I need in order to work with netboot? Obviously first of all you need one (or more) computers which should get bootet. Those are called clients. Netboot itself should be able to run on almost any PC compatible system, even with the oldest 8088 and 80286 processors. However, it has been optimized to run on 386 and up. Of course this system also needs a network card. Since Netboot uses standard DOS packet drivers, all network cards can be used for which packet drivers exist, even PCI and 100MBps cards. In case no such driver has been delivered with a network card it can usually be downloaded from an FTP server of the manufacturer, such as 3Com , SMC or Intel . In addition there are packet drivers for many popular network cards available for free from the Crynwr packet driver collection . Next you need a system which acts as the server. Because Netboot uses the BOOTP and TFTP standard protocols this server has to be able to understand those. It doesn´t matter if the server runs a UNIX like operating system or Windows-NT. What does it cost? Nothing! Netboot is given away for free and covered by the GNU General Public Licence . How does it work? In order to boot a computer without a hard disk a bootrom is necessary, which gets plugged into a socket on the network card. Netboot contains the full source code and executable binaries for such a bootrom. After poweron this bootrom queries a BOOTP server for the system´s network name and boot image file name, which then gets loaded using the TFTP protocol. This boot image file contains the operating system which get executed by the bootrom after loading. Netboot contains all necessary utilities to build such a boot image file for Linux and MS-DOS. 8.2. README 8.2.1. Copyright Notice, Acknowledgements You are allowed to modify and redistribute this code under the terms of the GNU General License. By making use of this software in any way you are automatically agreeing to these terms. My special thanks go to Jamie Honan for defining the initial bootrom specifications, to Markus Gutschke for enhancing mknbi-linux, and to Jens-Uwe Mager for explaining to me the basics of the NFS networking system and sometimes helping me out with his wealth of knowledge and experience. 8.2.2. Overview Booting a computer without a hard disk usually requires a floppy disk drive or a network connection in order to get the operating system into the RAM and up running. This package allows a diskless PC to boot an operating system using an IP based ethernet network. This is done in the following steps: · First the operating system has to be loaded into system memory. This can be done using a bootrom, which loads the operating system image over the network. The bootrom code found in this package can be burned into a real EPROM, or just copied onto a floppy and then started from it upon bootup. Please note that the term bootrom in all documentation texts in this package refers to the real EPROM version as well as the version copied onto and started from a floppy disk. For the bootrom to find the kernel image it uses the BOOTP protocol as defined in ``'' and ``'' to get the necessary boot information, and then loads the actual image using the TFTP protocol as defined in ``''. · When the operating system starts running, it has to setup it's memory layout using a special boot loader, which is included into the boot image. Then it has to mount it's root filesystem. This can either be done using NFS over the network, or using a ramdisk. The exact specifications for this netboot process can be found here . 8.2.3. Features Booting a diskless client either from an EPROM or from a floppy without additional utility tools The Bootrom code can use many standard DOS packet drivers and therefore supports almost any PC network card. Easy configuration of the bootrom under UNIX. The bootrom can load a BOOTP vendor extension file in order to support more space for tags according to ``''. Using the bootrom menu support it's possible to optionally boot different operating systems. Even if there is a hard disk installed in the client computer, the bootrom can be used as a boot manager, since it also allows booting from any partition. Cross-gateway booting Bootrom runs on any 80x86 processor but is optimized for the 386+. Able to boot different operating system. Currently supported are Linux and MS-DOS. 8.2.4. Installation See the file ``'' for installation instructions. If you have any problems installing or running the programs see the file ``''. 8.2.5. Mailing list There exists a mailing list devoted to network booting. To subscribe simply send a mail with the line subscribe netboot in it's body to majordomo@baghira.han.de The subject in the mail header doesn't matter. This mailing list is intended to be a general discussion forum about any aspect of network booting. Any new versions of this Netboot package will also get announced on that mailing list. After subscribing to it, you can send messages into the list by writing a mail to netboot@baghira.han.de. 8.2.6. Disclaimer The software in this package heavily interacts with hardware and software not only on the local system, but also on the boot server. Use it at your own risk. I cannot be held responsible for any damage done by this software. 8.3. Download Netboot You can download netboot version 0.9 from and netboot version 0.8.1 from 8.4. Netboot useful links Netboot mailing list archive is at · 3com drivers at · Accton drivers at here · Artisoft · CNET · Compaq · D-Link · Microdyne · Many NE2000 PCI cards are based on Realtek chipsets. Get drivers here · Standard Microsystems Corp · Surecom · Thomas Conrad corp · Winbond · Xircom · Webopaedia page on network cards · Jargon's driver page with many drivers for older network cards. · Etherboot This is a project similar to Netbot but based on the BSD bootrom code. · How to make an X Window Terminal out of your old or outdated PC. · List of jumper settings for various network cards. This page also contains many other good links. · Freefire is the home page of the Freefire project, which lists many resources for network security issues. 8.5. RFC 951 Network Working Group Bill Croft (Stanford University) Request for Comments: 951 John Gilmore (Sun Microsystems) September 1985 BOOTSTRAP PROTOCOL (BOOTP) 1. Status of this Memo This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 2. Overview This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled 'address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol [9], since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP [3] or FTP [6]. We suggest that the client's PROM software provide a way to do a complete bootstrap without 'user' interaction. This is the type of boot that would occur during an unattended power-up. A mechanism should be provided for the user to manually supply the necessary address and filename information to bypass the BOOTP protocol and enter the file transfer phase directly. If non-volatile storage is available, we suggest keeping default settings there and bypassing the BOOTP protocol unless these settings cause the file transfer phase to fail. If the cached information fails, the bootstrap should fall back to phase 1 and use BOOTP. Here is a brief outline of the protocol: 1. A single packet exchange is performed. Timeouts are used to retransmit until a reply is received. The same packet field layout is used in both directions. Fixed length fields of maximum reasonable length are used to simplify structure definition and parsing. 2. An 'opcode' field exists with two values. The client broadcasts a 'bootrequest' packet. The server then answers with a 'bootreply' packet. The bootrequest contains the client's hardware address and its IP address, if known. Croft & Gilmore [Page 1] RFC 951 September 1985 Bootstrap Protocol 3. The request can optionally contain the name of the server the client wishes to respond. This is so the client can force the boot to occur from a specific host (e.g. if multiple versions of the same bootfile exist or if the server is in a far distant net/domain). The client does not have to deal with name / domain services; instead this function is pushed off to the BOOTP server. 4. The request can optionally contain the 'generic' filename to be booted. For example 'unix' or 'ethertip'. When the server sends the bootreply, it replaces this field with the fully qualified path name of the appropriate boot file. In determining this name, the server may consult his own database correlating the client's address and filename request, with a particular boot file customized for that client. If the bootrequest filename is a null string, then the server returns a filename field indicating the 'default' file to be loaded for that client. 5. In the case of clients who do not know their IP addresses, the server must also have a database relating hardware address to IP address. This client IP address is then placed into a field in the bootreply. 6. Certain network topologies (such as Stanford's) may be such that a given physical cable does not have a TFTP server directly attached to it (e.g. all the gateways and hosts on a certain cable may be diskless). With the cooperation of neighboring gateways, BOOTP can allow clients to boot off of servers several hops away, through these gateways. See the section 'Booting Through Gateways' below. This part of the protocol requires no special action on the part of the client. Implementation is optional and requires a small amount of additional code in gateways and servers. 3. Packet Format All numbers shown are decimal, unless indicated otherwise. The BOOTP packet is enclosed in a standard IP [8] UDP [7] datagram. For simplicity it is assumed that the BOOTP packet is never fragmented. Any numeric fields shown are packed in 'standard network byte order', i.e. high order bits are sent first. In the IP header of a bootrequest, the client fills in its own IP source address if known, otherwise zero. When the server address is unknown, the IP destination address will be the 'broadcast address' 255.255.255.255. This address means 'broadcast on the local cable, (I don't know my net number)' [4]. Croft & Gilmore [Page 2] RFC 951 September 1985 Bootstrap Protocol The UDP header contains source and destination port numbers. The BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) and 'BOOTP server' (67). The client sends requests using 'BOOTP server' as the destination port; this is usually a broadcast. The server sends replies using 'BOOTP client' as the destination port; depending on the kernel or driver facilities in the server, this may or may not be a broadcast (this is explained further in the section titled 'Chicken/Egg issues' below). The reason TWO reserved ports are used, is to avoid 'waking up' and scheduling the BOOTP server daemons, when a bootreply must be broadcast to a client. Since the server and other hosts won't be listening on the 'BOOTP client' port, any such incoming broadcasts will be filtered out at the kernel level. We could not simply allow the client to pick a 'random' port number for the UDP source port field; since the server reply may be broadcast, a randomly chosen port number could confuse other hosts that happened to be listening on that port. The UDP length field is set to the length of the UDP plus BOOTP portions of the packet. The UDP checksum field can be set to zero by the client (or server) if desired, to avoid this extra overhead in a PROM implementation. In the 'Packet Processing' section below the phrase '[UDP checksum.]' is used whenever the checksum might be verified/computed. FIELD BYTES DESCRIPTION ----- ----- ----------- op 1 packet op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 hardware address type, see ARP section in "Assigned Numbers" RFC. '1' = 10mb ethernet hlen 1 hardware address length (eg '6' for 10mb ethernet). hops 1 client sets to zero, optionally used by gateways in cross-gateway booting. xid 4 transaction ID, a random number, used to match this boot request with the responses it generates. secs 2 filled in by client, seconds elapsed since client started trying to boot. Croft & Gilmore [Page 3] RFC 951 September 1985 Bootstrap Protocol -- 2 unused ciaddr 4 client IP address; filled in by client in bootrequest if known. yiaddr 4 'your' (client) IP address; filled by server if client doesn't know its own address (ciaddr was 0). siaddr 4 server IP address; returned in bootreply by server. giaddr 4 gateway IP address, used in optional cross-gateway booting. chaddr 16 client hardware address, filled in by client. sname 64 optional server host name, null terminated string. file 128 boot file name, null terminated string; 'generic' name or null in bootrequest, fully qualified directory-path name in bootreply. vend 64 optional vendor-specific area, e.g. could be hardware type/serial on request, or 'capability' / remote file system handle on reply. This info may be set aside for use by a third phase bootstrap or kernel. 4. Chicken / Egg Issues How can the server send an IP datagram to the client, if the client doesnt know its own IP address (yet)? Whenever a bootreply is being sent, the transmitting machine performs the following operations: 1. If the client knows its own IP address ('ciaddr' field is nonzero), then the IP can be sent 'as normal', since the client will respond to ARPs [5]. 2. If the client does not yet know its IP address (ciaddr zero), then the client cannot respond to ARPs sent by the transmitter of the bootreply. There are two options: a. If the transmitter has the necessary kernel or driver hooks Croft & Gilmore [Page 4] RFC 951 September 1985 Bootstrap Protocol to 'manually' construct an ARP address cache entry, then it can fill in an entry using the 'chaddr' and 'yiaddr' fields. Of course, this entry should have a timeout on it, just like any other entry made by the normal ARP code itself. The transmitter of the bootreply can then simply send the bootreply to the client's IP address. UNIX (4.2 BSD) has this capability. b. If the transmitter lacks these kernel hooks, it can simply send the bootreply to the IP broadcast address on the appropriate interface. This is only one additional broadcast over the previous case. 5. Client Use of ARP The client PROM must contain a simple implementation of ARP, e.g. the address cache could be just one entry in size. This will allow a second-phase-only boot (TFTP) to be performed when the client knows the IP addresses and bootfile name. Any time the client is expecting to receive a TFTP or BOOTP reply, it should be prepared to answer an ARP request for its own IP to hardware address mapping (if known). Since the bootreply will contain (in the hardware encapsulation) the hardware source address of the server/gateway, the client MAY be able to avoid sending an ARP request for the server/gateway IP address to be used in the following TFTP phase. However this should be treated only as a special case, since it is desirable to still allow a second-phase-only boot as described above. 6. Comparison to RARP An earlier protocol, Reverse Address Resolution Protocol (RARP) [1] was proposed to allow a client to determine its IP address, given that it knew its hardware address. However RARP had the disadvantage that it was a hardware link level protocol (not IP/UDP based). This means that RARP could only be implemented on hosts containing special kernel or driver modifications to access these 'raw' packets. Since there are many network kernels existent now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications is a decided advantage. BOOTP provides this hardware to IP address lookup function, in addition to the other useful features described in the sections above. Croft & Gilmore [Page 5] RFC 951 September 1985 Bootstrap Protocol 7. Packet Processing 7.1. Client Transmission Before setting up the packet for the first time, it is a good idea to clear the entire packet buffer to all zeros; this will place all fields in their default state. The client then creates a packet with the following fields. The IP destination address is set to 255.255.255.255. (the broadcast address) or to the server's IP address (if known). The IP source address and 'ciaddr' are set to the client's IP address if known, else 0. The UDP header is set with the proper length; source port = 'BOOTP client' port destination port = 'BOOTP server' port. 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware address type as assigned in the ARP section of the "Assigned Numbers" RFC. 'hlen' is set to the length of the hardware address, e.g. '6' for 10mb ethernet. 'xid' is set to a 'random' transaction id. 'secs' is set to the number of seconds that have elapsed since the client has started booting. This will let the servers know how long a client has been trying. As the number gets larger, certain servers may feel more 'sympathetic' towards a client they don't normally service. If a client lacks a suitable clock, it could construct a rough estimate using a loop timer. Or it could choose to simply send this field as always a fixed value, say 100 seconds. If the client knows its IP address, 'ciaddr' (and the IP source address) are set to this value. 'chaddr' is filled in with the client's hardware address. If the client wishes to restrict booting to a particular server name, it may place a null-terminated string in 'sname'. The name used should be any of the allowable names or nicknames of the desired host. The client has several options for filling the 'file' name field. If left null, the meaning is 'I want to boot the default file for my machine'. A null file name can also mean 'I am only interested in finding out client/server/gateway IP addresses, I dont care about file names'. The field can also be a 'generic' name such as 'unix' or Croft & Gilmore [Page 6] RFC 951 September 1985 Bootstrap Protocol 'gateway'; this means 'boot the named program configured for my machine'. Finally the field can be a fully directory qualified path name. The 'vend' field can be filled in by the client with vendor-specific strings or structures. For example the machine hardware type or serial number may be placed here. However the operation of the BOOTP server should not DEPEND on this information existing. If the 'vend' field is used, it is recommended that a 4 byte 'magic number' be the first item within 'vend'. This lets a server determine what kind of information it is seeing in this field. Numbers can be assigned by the usual 'magic number' process --you pick one and it's magic. A different magic number could be used for bootreply's than bootrequest's to allow the client to take special action with the reply information. [UDP checksum.] 7.2. Client Retransmission Strategy If no reply is received for a certain length of time, the client should retransmit the request. The time interval must be chosen carefully so as not to flood the network. Consider the case of a cable containing 100 machines that are just coming up after a power failure. Simply retransmitting the request every four seconds will inundate the net. As a possible strategy, you might consider backing off exponentially, similar to the way ethernet backs off on a collision. So for example if the first packet is at time 0:00, the second would be at :04, then :08, then :16, then :32, then :64. You should also randomize each time; this would be done similar to the ethernet specification by starting with a mask and 'and'ing that with with a random number to get the first backoff. On each succeeding backoff, the mask is increased in length by one bit. This doubles the average delay on each backoff. After the 'average' backoff reaches about 60 seconds, it should be increased no further, but still randomized. Before each retransmission, the client should update the 'secs' field. [UDP checksum.] Croft & Gilmore [Page 7] RFC 951 September 1985 Bootstrap Protocol 7.3. Server Receives BOOTREQUEST [UDP checksum.] If the UDP destination port does not match the 'BOOTP server' port, discard the packet. If the server name field (sname) is null (no particular server specified), or sname is specified and matches our name or nickname, then continue with packet processing. If the sname field is specified, but does not match 'us', then there are several options: 1. You may choose to simply discard this packet. 2. If a name lookup on sname shows it to be on this same cable, discard the packet. 3. If sname is on a different net, you may choose to forward the packet to that address. If so, check the 'giaddr' (gateway address) field. If 'giaddr' is zero, fill it in with my address or the address of a gateway that can be used to get to that net. Then forward the packet. If the client IP address (ciaddr) is zero, then the client does not know its own IP address. Attempt to lookup the client hardware address (chaddr, hlen, htype) in our database. If no match is found, discard the packet. Otherwise we now have an IP address for this client; fill it into the 'yiaddr' (your IP address) field. We now check the boot file name field (file). The field will be null if the client is not interested in filenames, or wants the default bootfile. If the field is non-null, it is used as a lookup key in a database, along with the client's IP address. If there is a default file or generic file (possibly indexed by the client address) or a fully-specified path name that matches, then replace the 'file' field with the fully-specified path name of the selected boot file. If the field is non-null and no match was found, then the client is asking for a file we dont have; discard the packet, perhaps some other BOOTP server will have it. The 'vend' vendor-specific data field should now be checked and if a recognized type of data is provided, client-specific actions should be taken, and a response placed in the 'vend' data field of the reply packet. For example, a workstation client could provide Croft & Gilmore [Page 8] RFC 951 September 1985 Bootstrap Protocol an authentication key and receive from the server a capability for remote file access, or a set of configuration options, which can be passed to the operating system that will shortly be booted in. Place my (server) IP address in the 'siaddr' field. Set the 'op' field to BOOTREPLY. The UDP destination port is set to 'BOOTP client'. If the client address 'ciaddr' is nonzero, send the packet there; else if the gateway address 'giaddr' is nonzero, set the UDP destination port to 'BOOTP server' and send the packet to 'giaddr'; else the client is on one of our cables but it doesnt know its own IP address yet --use a method described in the 'Egg' section above to send it to the client. If 'Egg' is used and we have multiple interfaces on this host, use the 'yiaddr' (your IP address) field to figure out which net (cable/interface) to send the packet to. [UDP checksum.] 7.4. Server/Gateway Receives BOOTREPLY [UDP checksum.] If 'yiaddr' (your [the client's] IP address) refers to one of our cables, use one of the 'Egg' methods above to forward it to the client. Be sure to send it to the 'BOOTP client' UDP destination port. 7.5. Client Reception Don't forget to process ARP requests for my own IP address (if I know it). [UDP checksum.] The client should discard incoming packets that: are not IP/UDPs addressed to the boot port; are not BOOTREPLYs; do not match my IP address (if I know it) or my hardware address; do not match my transaction id. Otherwise we have received a successful reply. 'yiaddr' will contain my IP address, if I didnt know it before. 'file' is the name of the file name to TFTP 'read request'. The server address is in 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the packets should be forwarded there first, in order to get to the server. 8. Booting Through Gateways This part of the protocol is optional and requires some additional code in cooperating gateways and servers, but it allows cross-gateway booting. This is mainly useful when gateways are diskless machines. Gateways containing disks (e.g. a UNIX machine acting as a gateway), might as well run their own BOOTP/TFTP servers. Gateways listening to broadcast BOOTREQUESTs may decide to forward or rebroadcast these requests 'when appropriate'. For example, the Croft & Gilmore [Page 9] RFC 951 September 1985 Bootstrap Protocol gateway could have, as part of his configuration tables, a list of other networks or hosts to receive a copy of any broadcast BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea to simply globally rebroadcast the requests, since broadcast loops will almost certainly occur. The forwarding could begin immediately, or wait until the 'secs' (seconds client has been trying) field passes a certain threshold. If a gateway does decide to forward the request, it should look at the 'giaddr' (gateway IP address) field. If zero, it should plug its own IP address (on the receiving cable) into this field. It may also use the 'hops' field to optionally control how far the packet is reforwarded. Hops should be incremented on each forwarding. For example, if hops passes '3', the packet should probably be discarded. [UDP checksum.] Here we have recommended placing this special forwarding function in the gateways. But that does not have to be the case. As long as some 'BOOTP forwarding agent' exists on the net with the booting client, the agent can do the forwarding when appropriate. Thus this service may or may not be co-located with the gateway. In the case of a forwarding agent not located in the gateway, the agent could save himself some work by plugging the broadcast address of the interface receiving the bootrequest into the 'giaddr' field. Thus the reply would get forwarded using normal gateways, not involving the forwarding agent. Of course the disadvantage here is that you lose the ability to use the 'Egg' non-broadcast method of sending the reply, causing extra overhead for every host on the client cable. 9. Sample BOOTP Server Database As a suggestion, we show a sample text file database that the BOOTP server program might use. The database has two sections, delimited by a line containing an percent in column 1. The first section contains a 'default directory' and mappings from generic names to directory/pathnames. The first generic name in this section is the 'default file' you get when the bootrequest contains a null 'file' string. The second section maps hardware addresstype/address into an ipaddress. Optionally you can also overide the default generic name by supplying a ipaddress specific genericname. A 'suffix' item is also an option; if supplied, any generic names specified by the client will be accessed by first appending 'suffix' to the 'pathname' Croft & Gilmore [Page 10] RFC 951 September 1985 Bootstrap Protocol appropriate to that generic name. If that file is not found, then the plain 'pathname' will be tried. This 'suffix' option allows a whole set of custom generics to be setup without a lot of effort. Below is shown the general format; fields are delimited by one or more spaces or tabs; trailing empty fields may be omitted; blank lines and lines beginning with '#' are ignored. # comment line homedirectory genericname1 pathname1 genericname2 pathname2 ... % end of generic names, start of address mappings hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix ... Here is a specific example. Note the 'hardwaretype' number is the same as that shown in the ARP section of the 'Assigned Numbers' RFC. The 'hardwaretype' and 'ipaddr' numbers are in decimal; 'hardwareaddr' is in hex. # last updated by smith /usr/boot vmunix vmunix tip ethertip watch /usr/diag/etherwatch gate gate. % end of generic names, start of address mappings hamilton 1 02.60.8c.06.34.98 36.19.0.5 burr 1 02.60.8c.34.11.78 36.44.0.12 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101 mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip In the example above, if 'mjh-gateway' does a default boot, it will get the file '/usr/boot/gate.mjh'. Croft & Gilmore [Page 11] RFC 951 September 1985 Bootstrap Protocol 10. Acknowledgements Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP bootstraping [2] using RARP [1]. We would also like to acknowledge the previous work and comments of Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer. REFERENCES 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984. 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC, June, 1984. 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC, September, 1984. 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC, October, 1984. 5. David Plummer. An Ethernet Address Resolution Protocol. RFC 826, NIC, September, 1982. 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980. 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980. 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981. 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC, June, 1981. Croft & Gilmore [Page 12] 8.6. RFC 1533 Network Working Group S. Alexander Request for Comments: 1533 Lachman Technology, Inc. Obsoletes: 1497, 1395, 1084, 1048 R. Droms Category: Standards Track Bucknell University October 1993 DHCP Options and BOOTP Vendor Extensions Status of this Memo This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined. Each superseding document will include the entire current list of valid options. All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. Table of Contents 1. Introduction .............................................. 2 2. BOOTP Extension/DHCP Option Field Format .................. 2 3. RFC 1497 Vendor Extensions ................................ 3 4. IP Layer Parameters per Host .............................. 10 5. IP Layer Parameters per Interface ........................ 13 6. Link Layer Parameters per Interface ....................... 16 7. TCP Parameters ............................................ 17 8. Application and Service Parameters ........................ 18 Alexander & Droms [Page 1] RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993 9. DHCP Extensions ........................................... 23 10. Extensions ................................................ 27 11. Acknowledgements .......................................... 28 12. References ................................................ 28 13. Security Considerations ................................... 19 14. Authors' Addresses ........................................ 30 1. Introduction This document specifies options for use with both the Dynamic Host Configuration Protocol and the Bootstrap Protocol. The full description of DHCP packet formats may be found in the DHCP specification document [1], and the full description of BOOTP packet formats may be found in the BOOTP specification document [3]. This document defines the format of information in the last field of DHCP packets ('options') and of BOOTP packets ('vend'). The remainder of this section defines a generalized use of this area for giving information useful to a wide class of machines, operating systems and configurations. Sites with a single DHCP or BOOTP server that is shared among heterogeneous clients may choose to define other, site- specific formats for the use of the 'options' field. Section 2 of this memo describes the formats of DHCP options and BOOTP vendor extensions. Section 3 describes options defined in previous documents for use with BOOTP (all may also be used with DHCP). Sections 4-8 define new options intended for use with both DHCP and BOOTP. Section 9 defines options used only in DHCP. References further describing most of the options defined in sections 2-6 can be found in section 12. The use of the options defined in section 9 is described in the DHCP specification [1].