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-installing
filesystems on a local disk. This file provides a general description 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 clients.

When booting a system over the network, there are three phases of interaction
between client and server:

The PROM (or stage-1 bootstrap) loads a boot program.

The boot program loads a kernel.

The kernel does NFS mounts for root and swap.

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 and
Motorola machines use RARP to determine the client's IP address and then use
TFTP to download a boot program from whoever sent the RARP reply. HP
300-series machines use the HP Remote Maintenance Protocol to download a boot
program. Other machines 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 depends on the design of the boot program. The
procedure used by the boot program is as follows:

The boot program gets the client IP address using
RARP.

The boot program gets the client name and server IP
address by broadcasting an RPC/BOOTPARAMS/WHOAMI request with the client
IP address.

The boot program gets the server path for this client's
root using an RPC/BOOTPARAMS/GETFILE request with the client name.

The boot program gets the root file handle by calling
mountd(8) with
the server path for the client root.

The boot program gets the kernel file handle by calling
NFS lookup on the root file handle.

The boot program loads the kernel using NFS read calls on
the kernel file handle.

The boot program transfers control to the kernel entry
point.

In phase 3, the kernel does NFS mounts for root and
swap. 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:

The kernel finds a boot server using the same procedure as
described in steps 1 and 2 of phase 2, above.

The kernel gets the NFS file handle for root using the
same procedure as described in steps 3, 4, and 5 of phase 2, above.

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.

If the kernel is configured for swap on NFS, it uses the
same mechanism as for root, but uses the NFS getattr function to determine
the size of the swap area.

The
INSTALL.⟨arch⟩
notes that come with each distribution also give details on the specifics of
net/diskless booting for each architecture.

The procedures for AMD64 and i386 clients vary somewhat to the stages detailed
above. See
pxeboot(8) for more
detailed information.

If booting a newer alpha, amd64, hppa, i386, sgi, sparc,
or sparc64 client, install a copy of the appropriate diskless boot loader
(such as boot.net from the root directory of
the OpenBSD sparc tree) in the
/tftpboot directory.

If booting a Motorola or Sun client, make a link such that the boot program
is accessible as a file named after the client's IP address in hex. For
example:

Sun Sparc machines also require a
“.⟨arch⟩”
suffix. So the filename in the example above for a Sun4 machine would be
“C0C5600C.SUN4”. The name used is really architecture
dependent: it simply has to match what the booting client's PROM wishes 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.

Architectures using DHCP (newer alpha, amd64, hppa, i386, or sgi) should
ensure that
dhcpd(8) is
configured on the server to serve BOOTP protocol requests. An example
entry in
dhcpd.conf(5):

Note that some bootparam servers are somewhat sensitive. Some require fully
qualified hostnames or partially qualified hostnames (which can be solved
by having both fully and partially qualified entries). Other servers are
case sensitive.

This creates a 120 Megabyte swap file and an empty /swap directory. A
smaller swap file may be created if the boot is for maintenance (i.e.
temporary) purposes only.

Populate myclient's root filesystem on the server. How
this is done depends on the client architecture and the version of the
OpenBSD distribution. It can be as simple as
copying and modifying the server's root filesystem, or perhaps the files
can be taken from the standard binary distribution.

Export the required filesystems in
/etc/exports:

/usr -ro myclient
/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 filesystem (as is
done above). If not, a properly fleshed out
/usr partition will have to be built for the
client in some other place.

Copy and customize at least the following files in
/export/myclient/root:

The above example works even if /usr and
/var are not on separate partitions. It
allows them to be mounted with NFSv3, if the server allows it, and to
specify per-partition mount options, such as “nodev”.

If the /usr partition is to be shared between
machines, as in the example /etc/exports
above, a more suitable entry might be:

myserver:/usr /usr nfs ro 0 0

Make sure the correct processes are enabled on the server.
See rc.conf(8)
for details of how to start these processes at boot.