diskless



DISKLESS(8)             OpenBSD 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-
     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:

     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 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:

     1.   The boot program gets the client IP address using RARP.
     2.   The boot program gets the client name and server IP address by
          broadcasting an RPC/BOOTPARAMS/WHOAMI request with the client IP
          address.
     3.   The boot program gets the server path for this client's root using
          an RPC/BOOTPARAMS/GETFILE request with the client name.
     4.   The boot program gets the root file handle by calling mountd(8) with
          the server path for the client root.
     5.   The boot program gets the kernel file handle by calling NFS lookup
          on the root file handle.
     6.   The boot program loads the kernel using NFS read calls on the kernel
          file handle.
     7.   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:

     1.   The kernel finds a boot server using the same procedure as described
          in steps 1 and 2 of phase 2, above.
     2.   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.
     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.
     4.   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.


EXAMPLES

     Before a client can boot over the network, its server must be configured
     correctly.  This example will demonstrate how to configure a server and
     client.

     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 /etc/hosts:

                192.197.96.12           myclient

     3.   If booting an alpha, amd64, hppa, hppa64, i386, sgi, mvme68k,
          mvme88k, sparc, sparc64, or vax client, ensure that tftpd(8) is
          configured to run in the directory /tftpboot.

          If booting an HP 300 or older HPPA 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 newer alpha, amd64, hppa, hppa64, i386, sgi, mvme68k,
          mvme88k, 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:

                # cd /tftpboot
                # ln -s boot.net C0C5600C

          The following example converts an IP address to hex:

                $ echo 192.197.96.12 | awk -F . \
                        '{ printf "%02X%02X%02X%02X\n", $1, $2, $3, $4 }'

          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, hppa64, 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):

                subnet 10.0.0.0 netmask 255.0.0.0 {
                        host myclient {
                                filename "netboot";
                                option root-path "/export/myclient/root";
                                hardware ethernet 00:02:56:00:73:31;
                                fixed-address 10.42.42.42;
                        }
                }

          Note that procedures for AMD64 and i386 clients vary somewhat.  See
          pxeboot(8) for more detailed information.

          Architectures using the HP remote boot server (HP 300 or older HPPA)
          should ensure that the general purpose boot program is installed in
          the directory /usr/mdec/rbootd.

          Architectures using MOP (older Alpha and Vax) should follow the
          instructions in mopd(8) for setting up a TFTP boot.

     5.   Add myclient to the bootparams database /etc/bootparams:

                myclient  root=server:/export/myclient/root \
                          swap=server:/export/myclient/swap

          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.

     6.   Build the swap file for myclient:

                # mkdir -p /export/myclient/root/swap
                # cd /export/myclient
                # dd if=/dev/zero of=swap bs=1m count=120

          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.

     7.   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.

     8.   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.

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

                # cd /export/myclient/root/etc
                # cp /etc/fstab fstab
                # cp /etc/hosts hosts
                # echo myclient > myname
                # echo inet 192.197.96.12 > hostname.le0

          Note that "le0" above should be replaced with the name of the
          network interface that the client will use for booting.

     10.  Correct at least the critical mount points in the client's fstab(5)
          (which will be /export/myclient/root/etc/fstab):

                myserver:/export/myclient/root / nfs rw 0 0
                myserver:/export/myclient/swap none swap sw,nfsmntpt=/swap
                myserver:/export/myclient/root/usr /usr nfs rw,nodev 0 0
                myserver:/export/myclient/root/var /var nfs rw,nosuid,nodev 0 0

          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

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

          For all clients: mountd(8), nfsd(8), portmap(8), and rarpd(8).

          For alpha, amd64, hppa, hppa64, i386, sgi, mvme68k, mvme88k, sparc,
          sparc64, and vax clients: tftpd(8)

          For HP 300 and older HPPA clients: rbootd(8)

          For newer alpha, amd64, hppa, hppa64, i386, and sgi clients:
          dhcpd(8)

          For hp300, older hppa, mvme68k, mvme88k, sparc, sparc64, and vax
          clients: rpc.bootparamd(8)

          For older alpha and vax clients: mopd(8)

     12.  Net boot the client.


FILES

     /etc/bootparams     Client root and swap pathnames.
     /etc/dhcpd.conf     DHCP daemon configuration file.
     /etc/ethers         Ethernet addresses of known clients.
     /etc/exports        Exported NFS mount points.
     /etc/fstab          Static information about the filesystems.
     /etc/hostname.$if   Interface-specific configuration file.
     /etc/hosts          Host name database.
     /etc/myname         Default hostname and gateway.
     /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), dhcpd.conf(5), ethers(5), exports(5), fstab(5),
     hostname.if(5), hosts(5), myname(5), dhcpd(8), mopd(8), mountd(8),
     nfsd(8), portmap(8), pxeboot(8), rarpd(8), rbootd(8), rpc.bootparamd(8),
     tcpdump(8), tftpd(8)

OpenBSD 5.4                     April 15, 2013                     OpenBSD 5.4

[Unix Hosting | Open-Source | Contact Us]
[Engineering & Automation | Software Development | Server Applications]