diskless(8) - NetBSD Manual Pages

DISKLESS(8)             NetBSD System Manager's Manual             DISKLESS(8)


NAME
diskless - booting a system over the network
DESCRIPTION
The ability to boot a machine over the network is useful for diskless or dataless machines, or as a temporary measure while repairing or re-in- stalling file systems on a local disk. This file provides a general de- scription of the interactions between a client and its server when a client is booting over the network. The general description is followed by specific instructions for configuring a server for diskless Sun clients.
OPERATION
When booting a system over the network, there are three phases of inter- action between client and server: 1. The PROM (or stage-1 bootstrap) loads a boot program. 2. The boot program loads a kernel. 3. The kernel does NFS mounts for root. Each of these phases are described in further detail below. In phase 1, the PROM loads a boot program. PROM designs vary widely, so this phase is inherently machine-specific. Sun machines use RARP to de- termine the client's IP address and then use TFTP to download a boot pro- gram from whomever sent the RARP reply. HP 300-series machines use the HP Remote Maintenance Protocol to download a boot program. Typical per- sonal computers may load a network boot program either from diskette or using a special PROM on the network card. In phase 2, the boot program loads a kernel. Operation in this phase de- pends on the design of the boot program. (The design described here is the one used by Sun and NetBSD/hp300.) The boot program: 2.1 gets the client IP address using RARP. 2.2 gets the client name and server IP address by broadcasting an RPC / BOOTPARAMS / WHOAMI request with the client IP address. 2.3 gets the server path for this client's root using an RPC / BOOTPARAMS / GETFILE request with the client name. 2.4 gets the root file handle by calling mountd(8) with the server path for the client root. 2.5 gets the kernel file handle by calling NFS lookup on the root file handle. 2.6 loads the kernel using NFS read calls on the kernel file handle. 2.7 transfers control to the kernel entry point. In phase 3, the kernel does NFS mounts for root. The kernel repeats much of the work done by the boot program because there is no standard way for the boot program to pass the information it gathered on to the kernel. The procedure used by the kernel is as follows: 3.1 The kernel finds a boot server using the same procedure as described in steps 2.1 and 2.2 above. In general, the GENERIC config(8) files for any particular architecture will specify options to activate in the kernel the same protocol used by the boot program for that ar- chitecture, however, the kernel can be compiled to use any of BOOTP, DHCP, or BOOTPARAMS. See options(4). 3.2 The kernel gets the NFS file handle for root using the same proce- dure as described in steps 2.3 through 2.5 above. 3.3 The kernel calls the NFS getattr function to get the last-modified time of the root directory, and uses it to check the system clock.
CONFIGURATION
Before a client can boot over the network, its server must be configured correctly. This example will demonstrate how a Sun client might be con- figured -- other clients should be similar. Assuming the client's hostname is to be ``myclient'', 1. Add an entry to /etc/ethers corresponding to the client's ethernet address: 8:0:20:7:c5:c7 myclient This will be used by rarpd(8). 2. Assign an IP address for myclient in your /etc/hosts or DNS database: 192.197.96.12 myclient 3. If booting a Sun machine, ensure that /etc/inetd.conf is configured to run tftpd(8) in the directory /tftpboot. If booting an HP 300-series machine, ensure that /etc/rbootd.conf is configured properly to transfer the boot program to the client. An entry might look like this: 08:00:09:01:23:E6 SYS_UBOOT # myclient See the rbootd(8) manual page for more information. 4. If booting a SPARC machine, install a copy of the appropriate disk- less boot loader (such as /usr/mdec/boot or ofwboot.net) in the /tftpboot directory. Make a link such that the boot program is ac- cessible by a file name composed of the client's IP address in HEX, a dot, and the architecture name (all upper case). For example: # cd /tftpboot # ln -s boot C0C5600C.SUN4 For a Sun3 or Ultra Sparc machine, the name would be just C0C5600C (there the PROM does not append the architecture name). The name used is architecture dependent, it simply has to match what the booting client's PROM wishes to it to be. If the client's PROM fails to fetch the expected file, tcpdump(8) can be used to discover which filename the client is trying to read. If booting an HP 300-series machine, ensure that the network boot program SYS_UBOOT (which may be called uboot.lif before installa- tion) is installed in the directory /usr/mdec/rbootd. 5. Add myclient to the bootparams database /etc/bootparams: myclient root=server:/export/myclient/root \ gateway=mygw:255.255.255.0 and ensure that rpc.bootparamd(8) is running. 6. Build the swap file for myclient: # cd /export/myclient/root # dd if=/dev/zero of=swap bs=16k count=1024 This creates a 16 Megabyte swap file. 7. Populate myclient's / file system on the server. How this is done depends on the client architecture and the version of the NetBSD distribution. It can be as simple as copying and modifying the server's root file system, or perhaps you need to get those files out of the standard binary distribution. 8. Export the required file systems in /etc/exports: /usr -ro myclient # for SunOS: # /export/myclient -rw=myclient,root=myclient # for NetBSD: /export/myclient -maproot=root -alldirs myclient If the server and client are of the same architecture, then the client can share the server's /usr file system (as is done above). If not, you must build a properly fleshed out /usr partition for the client in some other place. If your server was a sparc, and your client a sun3, you might create and fill /export/usr.sun3 and then use the following /etc/exports lines: /export/usr.sun3 -ro myclient /export/myclient -rw=myclient,root=myclient Of course, in either case you will have to have an NFS server run- ning on the server side. 9. Copy and customize at least the following files in /export/myclient/root: # cd /export/myclient/root/etc # vi fstab # cp /etc/hosts hosts # echo 'hostname="myclient"' >> rc.conf # echo "inet 192.197.96.12" > ifconfig.le0 Note that "le0" above should be replaced with the name of the net- work interface that the client will use for booting. 10. Correct the critical mount points and the swap file in the client's /etc/fstab (which will be /export/myclient/root/etc/fstab) i.e. myserver:/export/myclient/root / nfs rw 0 0 myserver:/usr /usr nfs rw 0 0 /swap none swap sw Note, you must specify the swap file in /etc/fstab or it will not be used!
FILES
/etc/ethers Ethernet addresses of known clients /etc/bootparams client root pathname /etc/exports exported NFS mount points /etc/rbootd.conf configuration file for HP Remote Boot Daemon /tftpboot location of boot programs loaded by the Sun PROM /usr/mdec/rbootd location of boot programs loaded by the HP Boot ROM
SEE ALSO
bootparams(5), ethers(5), exports(5), mountd(8), nfsd(8), rarpd(8), rbootd(8), reboot(8), rpc.bootparamd(8), tftpd(8) NetBSD 1.6.2 January 25, 1998 3

Powered by man-cgi (2024-08-26). Maintained for NetBSD by Kimmo Suominen. Based on man-cgi by Panagiotis Christias.