The ability to boot a system over the network is useful for two kinds of systems:
diskless
a system with no attached mass storage media to boot or run from (e.g. a network computer).
dataless
a system with a hard drive that only contains system and application software, and user data is mounted over the network from a central server.
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:
RARP
Reverse Address Resolution Protocol (ARP)
DHCP
Dynamic Host Configuration Protocol
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:
TFTP
Trivial File Transfer Protocol
NFS
Sun Network File System
RMP
HP Remote Maintenance Protocol
MOP
DEC Maintenance Operations Protocol
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.