DISKLESS(8) | System Manager's Manual | DISKLESS(8) |
It can also be done as a temporary measure while repairing or re-installing file systems on a local disk. This capability is necessarily platform dependent because of its dependence on system firmware support; not all platforms supported by NetBSD are capable of being network booted.
The protocols used to obtain a network address (e.g. an IP host address), include, but are not limited to:
This information can also be derived from non-volatile RAM or by a transform of a network interface (e.g. Ethernet) MAC address.
The protocols used to load a NetBSD kernel over a network include, but are not limited to:
Derivation of the filename of the secondary bootstrap program can be done by a transform of a network interface MAC address (or other protocol address), or provided by a server as with BOOTP, and DHCP. How this is done is platform dependent; see boot(8).
The NetBSD kernel doesn't care how it gets loaded and started. The protocols used to boot NetBSD can be completely different than the ones that NetBSD uses operationally, i.e. you can netboot the system using HP RMP and the NetBSD kernel can use IP to communicate after bootstrap.
There is no standard way to pass all the required information from a boot loader to an operating system kernel, so the NetBSD kernel usually has to recapitulate the same (or similar) protocol exchanges over the network to obtain a network address, determine which servers to use, and so on. NetBSD supports obtaining this information from RARP, BOOTP, DHCP, and Sun RPC “bootparams”. See options(4) for a list of methods that can be compiled into a NetBSD kernel.
NetBSD only supports the Sun Network File System (NFS) for mounting its root file system over a network. NetBSD can use any local mass storage device for which it has a driver, after bootstrap, even if that device is not supported by the system's firmware for booting.
N.B. DHCP is essentially a series of extensions to BOOTP; the NetBSD dhcpd(8) is capable of responding to both kinds of protocol requests.
In the majority of configurations, network boot servers and clients are attached to the same LAN so that broadcast queries from the clients can be heard by the servers. Unless specially configured, routers block broadcasts from propagating from LAN to LAN; some routers can be configured to “forward” broadcast BOOTP packets to another LAN attached to that router, which permits a server on that remote LAN to respond to the client's broadcast query.
Each of these phases are described in further detail below.
DEC Alpha systems use BOOTP to determine the client's IP address and then use TFTP load a secondary bootstrap program from the server and filename specified in the BOOTP reply. DEC Alpha systems can also use MOP to load a program to run the system.
Sun systems use RARP to determine the client's IP address, transform that address to a hexadecimal string to form the filename of the secondary boot program, and then use TFTP to download the boot program from the server that sent the RARP reply.
HP 300-series systems use the HP RMP to download a boot program.
Typical personal computers may load a network boot program either from diskette or from a PROM on a Network Interface Card (NIC). Some BIOSes support booting from a network interface.
A BOOTP and/or DHCP secondary bootstrap program will do the following:
In general, the GENERIC kernel config(1) file for any particular architecture will specify compile-time options to use the same protocol used by the secondary boot program for that architecture. A NetBSD kernel can be compiled to use any of BOOTP, DHCP, or Sun RPC BOOTPARAMS; see options(4).
The procedure typically used by the kernel is as follows:
Protocol | Program | Startup |
RARP | rarpd | rc.conf(5) |
DHCP | dhcpd | rc.conf(5) |
BOOTP | bootpd | inetd.conf(5) |
TFTP | tfptd | inetd.conf(5) |
Sun RPC | rpcbind | rc.conf(5) |
Sun RPC | rpc.bootparamd | rc.conf(5) |
Sun NFS | mountd | rc.conf(5) |
Sun NFS | nfsiod | rc.conf(5) |
HP RMP | rbootd | rc.conf(5) |
N.B. DHCP is essentially a series of extensions to BOOTP; the NetBSD dhcpd(8) is capable of responding to both kinds of protocol requests. Since they both bind to the same UDP port, only one may be run on a given server.
In the following examples, the client's hostname is myclient; the server is myserver, and the addresses are all fictional. In these examples the hostnames may be Fully Qualified Domain Names (FQDN, e.g. “myclient.mydomain.com”) provided that they are used consistently.
8:0:20:7:c5:c7 myclient
This will be used by rarpd(8) to reply to queries from the clients. There must be one entry per client system.
A client system's Ethernet MAC address is often printed on the system case, or on a chip on its motherboard, or on the NIC. If not, “sniffing” the network with tcpdump(8) when the client is powered-on should reveal its Ethernet MAC address.
Each client system that uses RARP must have its own, unique IP address assigned to it. Assign an IP address for myclient in your /etc/hosts file, or in the master file for your DNS zone. For /etc/hosts the entry should look like:
192.197.96.12 myclient
DHCP can provide a wide range of information to a requesting client; the key data for bootstrapping a diskless client are:
An example for /etc/dhcpd.conf
host myclient { hardware ethernet 8:0:20:7:c5:c7; fixed-address myclient; # client's assigned IP address filename "myclient.netboot"; # secondary bootstrap next-server myserver; # TFTP server for secondary bootstrap option swap-server myserver; # NFS server for root filesystem option root-path "/export/myclient/root"; }
That host declaration goes inside a subnet declaration, which gives parameters for all hosts on the subnet that will be using DHCP, such as the “routers” (the default route), “subnet-mask”, “broadcast-address”, “domain-name-servers”, etc. See dhcpd.conf(5) for details. In that example, myclient has an assigned IP address.
The DHCP parameters required for network bootstrapping a system will vary from platform to platform, as dictated by each system's firmware. In particular, because the DHCP is extensible, some hardware vendors have specified DHCP options to return information to requesting clients that are specific to that platform. Please see your platform's boot(8) for details.
If booting a SPARC system, install a copy of the appropriate diskless secondary boot loader (such as /usr/mdec/boot or ofwboot.net) in the /tftpboot directory. Make a link such that the boot program is accessible by a filename composed of the client's IP address in hexadecimal, a dot, and the architecture name (all upper case). For example:
# cd /tftpboot # ln -s boot C0C5600C.SUN4
For a Sun-3 or UltraSPARC system, the filename would be just C0C5600C (these systems' firmware does not append the architecture name). The name used is architecture dependent, it simply has to match what the booting client's system firmware wishes to it to be.
If the client's system firmware fails to fetch the expected file, tcpdump(8) can be used to discover which filename the client is being requested. Also, examination of tftpd(8) log entries (typically in /var/log/messages) should show whether the server is hearing the client system, and what filename the client is asking for.
08:00:09:01:23:E6 SYS_UBOOT # myclient
The secondary bootstrap program for an HP 300-series system SYS_UBOOT (which may be called uboot.lif before installation) must be installed in the directory /usr/mdec/rbootd.
See the rbootd(8) manual page for more information.
myclient root=myserver:/export/myclient/root \ swap=myserver:/export/myclient/root/swap \ dump=myserver:/export/myclient/root/swap
and ensure that rpc.bootparamd(8) and rpcbind(8) are running. Both myclient and myserver must have IP addresses in the DNS or /etc/hosts.
# cd /export/myclient/root # dd if=/dev/zero of=swap bs=16k count=1024
This creates a 16 megabyte swap file.
Populate myclient's root file system on the NFS 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 unpack a complete NetBSD binary distribution for the appropriate platform.
If the NFS server is going to support multiple different architectures (e.g. Alpha, PowerPC, SPARC, MIPS), then it is important to think carefully about how to lay out the NFS server's exported file systems, to share what can be shared (e.g. text files, configuration files, user home directories), and separate that which is distinct to each architecture (e.g. binary executables, libraries).
/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 part of the server's file system, to serve to the client.
If your server is a SPARC, and your client a Sun-3, 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 running on the server side.
# 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 network interface that the client will use for booting; the network interface name is device dependent in NetBSD.
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 0 0
Note, you must specify the swap file in /etc/fstab or it will not be used! See swapctl(8).
Reverse Address Resolution Protocol, RFC, 903, June 1984.
Bootstrap Loading using TFTP, RFC, 906, June 1984.
Bootstrap Protocol, RFC, 951, September 1985.
The TFTP Protocol (Revision 2), RFC, 1350, July 1992.
Dynamic Host Configuration Protocol, RFC, 2131, March 1997.
DHCP Options and BOOTP Vendor Extensions, RFC, 2132, March 1997.
http://www.rfc-editor.org/
October 7, 2006 | NetBSD 6.1 |