Return to diskless.8 CVS log

Up to [cvs.NetBSD.org] / src / share / man / man8

PR/29858: Miles Nordin: diskless(8) man page is wrong about
'option swap-server'

Patch applied, thanks!

.\"	$NetBSD: diskless.8,v 1.29 2006/10/07 22:23:45 elad Exp $
.\"
.\" Copyright (c) 1994 Gordon W. Ross, Theo de Raadt
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. The name of the author may not be used to endorse or promote products
.\"    derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd October 7, 2006
.Dt DISKLESS 8
.Os
.Sh NAME
.Nm diskless
.Nd booting a system over the network
.Sh DESCRIPTION
The ability to boot a system over the network is useful for
two kinds of systems:
.Pp
.Bl -tag -width diskless
.It Em diskless
a system with no attached mass storage media to boot or run from
.Pq e.g. a network computer .
.It Em 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.
.El
.Pp
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
.Nx
are capable of being network booted.
.Pp
The protocols used to obtain a network address
.Pq e.g. an Tn \&IP host address ,
include, but are not limited to:
.Pp
.Bl -tag -width BOOTP -offset indent -compact
.It Tn RARP
Reverse Address Resolution Protocol
.Pq Tn ARP
.It Tn DHCP
Dynamic Host Configuration Protocol
.It Tn BOOTP
Bootstrap Protocol
.El
.Pp
This information can also be derived from non-volatile
.Tn RAM
or by a transform of a network interface
.Pq e.g. Tn Ethernet
.Tn MAC
address.
.Pp
The protocols used to load a
.Nx
kernel over a network include, but are not limited to:
.Pp
.Bl -tag -width TFTP -offset indent -compact
.It Tn TFTP
Trivial File Transfer Protocol
.It Tn NFS
.Tn Sun
Network File System
.It Tn RMP
.Tn \&HP
Remote Maintenance Protocol
.It Tn MOP
.Tn DEC
Maintenance Operations Protocol
.El
.Pp
Derivation of the filename of the secondary bootstrap program can
be done by a transform of a network interface
.Tn MAC
address
.Pq or other protocol address ,
or provided by a server as with
.Tn BOOTP ,
and
.Tn DHCP .
How this is done is platform dependent; see
.Xr boot 8 .
.Pp
The
.Nx
kernel doesn't care how it gets loaded and started.
The protocols used to boot
.Nx
can be completely different than the ones that
.Nx
uses operationally, i.e. you can netboot the system using
.Tn \&HP
.Tn RMP
and the
.Nx
kernel can use
.Tn \&IP
to communicate after bootstrap.
.Pp
There is no standard way to pass all the required information
from a boot loader to an operating system kernel, so the
.Nx
kernel usually has to recapitulate the same
.Pq or similar
protocol exchanges over the network to obtain a network address,
determine which servers to use, and so on.
.Nx
supports obtaining this information from
.Tn RARP ,
.Tn BOOTP ,
.Tn DHCP ,
and
.Tn Sun RPC
.Qq bootparams .
See
.Xr options 4
for a list of methods that can be compiled into a
.Nx
kernel.
.Pp
.Nx
only supports the
.Tn Sun
Network File System
.Pq Tn NFS
for mounting its root file system over a network.
.Nx
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.
.Pp
.Sy N.B.
.Tn DHCP
is essentially a series of extensions to
.Tn BOOTP ;
the
.Nx
.Xr dhcpd 8
is capable of responding to both kinds of protocol requests.
.Pp
In the majority of configurations, network boot servers and clients
are attached to the same
.Tn LAN
so that broadcast queries from the clients can be heard by the servers.
Unless specially configured, routers block broadcasts from propagating from
.Tn LAN
to
.Tn LAN ;
some routers can be configured to
.Qq forward
broadcast
.Tn BOOTP
packets to another
.Tn LAN
attached to that router, which permits a server on that remote
.Tn LAN
to respond to the client's broadcast query.
.Sh OPERATION
When booting a system over the network, there are three
phases of interaction between client and server:
.Pp
.Bl -enum -compact
.It
The system firmware
.Pq or stage-1 bootstrap
loads a boot program.
.It
The boot program loads a
.Nx
kernel.
.It
The
.Nx
kernel performs an
.Tn NFS
mount of the root file system.
.El
.Pp
Each of these phases are described in further detail below.
.Ss 1. loading a boot program
In phase 1, the system firmware loads a boot program.
Firmware designs vary widely,
so this phase is inherently machine-specific.
Some examples:
.Pp
.Tn DEC
Alpha systems use
.Tn BOOTP
to determine the client's
.Tn \&IP
address and then use
.Tn TFTP
load a secondary bootstrap program from the server and filename
specified in the
.Tn BOOTP
reply.
.Tn DEC
Alpha systems can also use
.Tn MOP
to load a program to run the system.
.Pp
.Tn Sun
systems use
.Tn RARP
to determine the client's
.Tn \&IP
address, transform that address to a hexadecimal string to form
the filename of the secondary boot program, and then use
.Tn TFTP
to download the boot program from the server that sent the
.Tn RARP
reply.
.Pp
.Tn \&HP
300-series systems use the
.Tn \&HP
.Tn RMP
to download a boot program.
.Pp
Typical personal computers may load a network boot program either
from diskette or from a
.Tn PROM
on a Network Interface Card
.Pq Tn NIC .
Some
.Tn BIOS Ns No \&es
support booting from a network interface.
.Ss 2. loading a kernel
In phase 2, the secondary boot program loads a kernel.
Operation in this phase depends on the design of the boot program
.Po
the design described here is the one used by
.Tn Sun
and
.Nx Ns Tn /hp300
.Pc .
The boot program:
.Pp
.Bl -enum -compact
.It
gets the client
.Tn \&IP
address using
.Tn RARP .
.It
gets the client name and server
.Tn \&IP
address by broadcasting an
.Tn RPC / BOOTPARAMS / WHOAMI
request with the client
.Tn \&IP
address.
.It
gets the server path for this client's
root using an
.Tn RPC / BOOTPARAMS / GETFILE
request with the client name.
.It
gets the root file handle by calling
.Xr mountd 8
with the server path for the client root file system.
.It
gets the kernel file handle by calling
.Tn NFS
.Fn lookup
on the root file handle.
.It
loads the kernel using
.Tn NFS
read calls on the kernel file handle.
.It
transfers control to the kernel entry point.
.El
.Pp
A
.Tn BOOTP
and/or
.Tn DHCP
secondary bootstrap program will do the following:
.Pp
.Bl -enum -compact
.It
query for the client's bootstrap parameters.
The response must include the client's
.Tn \&IP
address, and a
.Tn TFTP
server to load the
.Nx
kernel from.
.It
loads the
.Nx
kernel from the
.Tn TFTP
server.
.It
transfers control to the kernel entry point.
.El
.Ss 3. NFS mounting the root file system
In phase 3, the kernel performs an
.Tn NFS
mount of the root file system.
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.
.Pp
In general, the GENERIC kernel
.Xr 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
.Nx
kernel can be compiled to use any of
.Tn BOOTP ,
.Tn DHCP ,
or
.Tn Sun RPC BOOTPARAMS ;
see
.Xr options 4 .
.Pp
The procedure typically used by the kernel is as follows:
.Pp
.Bl -enum -compact
.It
The kernel finds a boot server using the same procedures
as described above to determine the client's
.Tn \&IP
address, an
.Tn NFS
server, etc.
.It
The kernel gets the
.Tn NFS
file handle for root using the same procedure as described above.
.It
The kernel calls the
.Tn NFS
.Fn getattr
function to get the last-modified time of the root
directory, and uses it to check the system clock.
.El
.Sh SERVER CONFIGURATION
Before a client can bootstrap over the network,
its server must be configured.
Each daemon that implements these protocols must be set up so
that it can answer queries from the clients.
Some of these daemons are invoked as packets come in, by
.Xr inetd 8 ,
and some must run independently, started from
.Pa /etc/rc ;
see
.Xr rc.conf 5 .
.Pp
.Bl -column "Protocol" "rpc.bootparamd" "inetd.conf(5)" -offset indent
.It Sy Protocol Ta Sy Program Ta Sy Startup
.It RARP Ta rarpd Ta Xr rc.conf 5
.It DHCP Ta dhcpd Ta Xr rc.conf 5
.It BOOTP Ta bootpd Ta Xr inetd.conf 5
.It TFTP Ta tfptd Ta Xr inetd.conf 5
.It Sun RPC Ta rpcbind Ta Xr rc.conf 5
.It Sun RPC Ta rpc.bootparamd Ta Xr rc.conf 5
.It Sun NFS Ta mountd Ta Xr rc.conf 5
.It Sun NFS Ta nfsiod Ta Xr rc.conf 5
.It \&HP RMP Ta rbootd Ta Xr rc.conf 5
.El
.Pp
.Sy N.B.
.Tn DHCP
is essentially a series of extensions to
.Tn BOOTP ;
the
.Nx
.Xr dhcpd 8
is capable of responding to both kinds of protocol requests.
Since they both bind to the same
.Tn UDP
port, only one may be run on a given server.
.Pp
In the following examples, the client's hostname is
.Sy myclient ;
the server is
.Sy myserver ,
and the addresses are all fictional.
In these examples
the hostnames may be Fully Qualified Domain Names
.Pq FQDN, e.g. Qq myclient.mydomain.com
provided that they are used consistently.
.Ss RARP
For clients that use
.Tn RARP
to obtain their
.Tn \&IP
address,
an entry must be added for each client to
.Pa /etc/ethers
with the client's
.Tn Ethernet
.Tn MAC
address and Internet hostname:
.Pp
.Bd -literal -offset indent -compact
8:0:20:7:c5:c7          myclient
.Ed
.Pp
This will be used by
.Xr rarpd 8
to reply to queries from the clients.
There must be one entry per client system.
.Pp
A client system's
.Tn Ethernet
.Tn MAC
address is often printed on the system case, or on a chip on its
motherboard, or on the
.Tn NIC .
If not,
.Qq sniffing
the network with
.Xr tcpdump 8
when the client is powered-on should reveal its
.Tn Ethernet
.Tn MAC
address.
.Pp
Each client system that uses
.Tn RARP
must have its own, unique
.Tn \&IP
address assigned to it.
Assign an
.Tn \&IP
address for myclient in your
.Pa /etc/hosts
file, or in the master file for your
.Tn DNS
zone.
For
.Pa /etc/hosts
the entry should look like:
.Pp
.Bd -literal -offset indent -compact
192.197.96.12           myclient
.Ed
.Ss DHCP/BOOTP
The
.Nx
.Tn DHCP
server
.Xr dhcpd 8
was developed by the Internet Software Consortium
.Pq ISC ;
.Pa http://www.isc.org/
.Pp
.Tn DHCP
can provide a wide range of information to a requesting client;
the key data for bootstrapping a diskless client are:
.Pp
.Bl -enum -compact
.It
an
.Tn \&IP
address
.It
a subnet mask
.It
a
.Tn TFTP
server address for loading the secondary bootstrap and the
.Nx
kernel
.It
a filename of the secondary bootstrap
.It
an
.Tn NFS
server address for the client's file system
.It
the client's root file system path, to be
.Tn NFS
mounted.
.El
.Pp
An example for
.Pa /etc/dhcpd.conf
.Pp
.Bd -literal -offset indent
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";
}
.Ed
.Pp
That
.Sy host
declaration goes inside a
.Sy subnet
declaration, which gives parameters for all hosts on the subnet
that will be using
.Tn DHCP ,
such as the
.Qq routers
.Pq the default route ,
.Qq subnet-mask ,
.Qq broadcast-address ,
.Qq domain-name-servers ,
etc.
See
.Xr dhcpd.conf 5
for details.
In that example,
.Sy myclient
has an assigned IP address.
.Pp
The
.Tn 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
.Tn DHCP
is extensible, some hardware vendors have specified
.Tn DHCP
options to return information to requesting clients that are specific
to that platform.
Please see your platform's
.Xr boot 8
for details.
.Ss TFTP
If booting a
.Tn Sun
system, or other system that expects to use
.Tn TFTP ,
ensure that
.Xr inetd 8
is configured to run
.Xr tftpd 8 .
The
.Xr tftpd 8
server should be set up to serve the directory
.Pa /tftpboot .
.Pp
If booting a
.Tn SPARC
system, install a copy of the appropriate diskless secondary boot
loader
.Po
such as
.Pa /usr/mdec/boot
or
.Pa ofwboot.net
.Pc
in the
.Pa /tftpboot
directory.
Make a link such that the boot program is
accessible by a filename composed of the client's
.Tn \&IP
address in hexadecimal, a dot, and the architecture name
.Pq all upper case .
For example:
.Pp
.Bd -literal -offset indent -compact
# cd /tftpboot
# ln -s boot C0C5600C.SUN4
.Ed
.Pp
For a
.Tn Sun-3
or
.Tn UltraSPARC
system, the filename would be just C0C5600C
.Po
these systems' firmware does not append the architecture name
.Pc .
The name used is architecture dependent, it simply has to match
what the booting client's system firmware wishes to it to be.
.Pp
If the client's system firmware fails to fetch the expected file,
.Xr tcpdump 8
can be used to discover which filename the client is being requested.
Also, examination of
.Xr tftpd 8
log entries
.Po
typically in
.Pa /var/log/messages
.Pc
should show whether the server is hearing the client system, and
what filename the client is asking for.
.Ss HP RMP
If booting an
.Tn HP
300-series system, ensure that
.Pa /etc/rbootd.conf
is configured properly to transfer the boot program to the client.
An entry might look like this:
.Pp
.Bd -literal -offset indent -compact
08:00:09:01:23:E6	SYS_UBOOT	# myclient
.Ed
.Pp
The secondary bootstrap program for an
.Tn \&HP
300-series system
.Pa SYS_UBOOT
.Po
which may be called
.Pa uboot.lif
before installation
.Pc
must be installed in the directory
.Pa /usr/mdec/rbootd .
.Pp
See the
.Xr rbootd 8
manual page for more information.
.Ss Sun RPC BOOTPARAMS
Add
.Sy myclient
to the bootparams database in
.Pa /etc/bootparams :
.Pp
.Bd -literal -offset indent -compact
myclient  root=myserver:/export/myclient/root \\
          swap=myserver:/export/myclient/root/swap \\
          dump=myserver:/export/myclient/root/swap
.Ed
.Pp
and ensure that
.Xr rpc.bootparamd 8
and
.Xr rpcbind 8
are running.
Both
.Sy myclient
and
.Sy myserver
must have
.Tn \&IP
addresses in the
.Tn DNS
or
.Pa /etc/hosts .
.Ss Diskless Client File Systems
Build the swap file for
.Sy myclient
on the
.Tn NFS
server:
.Pp
.Bd -literal -offset indent -compact
# cd /export/myclient/root
# dd if=/dev/zero of=swap bs=16k count=1024
.Ed
.Pp
This creates a 16 megabyte swap file.
.Pp
Populate
.Sy myclient Ns No 's
root file system on the
.Tn NFS
server.
How this is done depends on the client architecture and the version
of the
.Nx
distribution.
It can be as simple as copying and modifying the server's root
file system, or unpack a complete
.Nx
binary distribution for the appropriate platform.
.Pp
If the
.Tn NFS
server is going to support multiple different architectures
.Po
e.g.
.Tn Alpha ,
.Tn PowerPC ,
.Tn SPARC ,
.Tn MIPS
.Pc ,
then it is important to think carefully about how to lay out the
.Tn NFS
server's exported file systems, to share what can be shared
.Pq e.g. text files, configuration files, user home directories ,
and separate that which is distinct to each architecture
.Pq e.g. binary executables, libraries .
.Ss NFS
Export the client-populated file systems on the
.Tn NFS
server in
.Pa /etc/exports :
.Pp
.Bd -literal -offset indent -compact
/usr -ro myclient
# for SunOS:
# /export/myclient -rw=myclient,root=myclient
# for NetBSD:
/export/myclient -maproot=root -alldirs myclient
.Ed
.Pp
If the server and client are of the same architecture, then the client
can share the server's
.Pa /usr
file system
.Pq as is done above .
If not, you must build a properly fleshed out
.Pa /usr
partition for the client in some other part of the server's
file system, to serve to the client.
.Pp
If your server is a
.Tn SPARC ,
and your client a
.Tn Sun-3 ,
you might create and fill
.Pa /export/usr.sun3
and then use the following
.Pa /etc/exports
lines:
.Pp
.Bd -literal -offset indent -compact
/export/usr.sun3 -ro myclient
/export/myclient -rw=myclient,root=myclient
.Ed
.Pp
Of course, in either case you will have to have an
.Tn NFS
server running on the server side.
.Sh CLIENT CONFIGURATION
Copy and customize at least the following files in
.Pa /export/myclient/root :
.Pp
.Bd -literal -offset indent -compact
# cd /export/myclient/root/etc
# vi fstab
# cp /etc/hosts hosts
# echo 'hostname="myclient"' \*[Gt]\*[Gt] rc.conf
# echo "inet 192.197.96.12" \*[Gt] ifconfig.le0
.Ed
.Pp
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
.Nx .
.Pp
Correct the critical mount points and the swap file in the client's
.Pa /etc/fstab
.Po
which will be
.Pa /export/myclient/root/etc/fstab
.Pc
i.e.
.Pp
.Bd -literal -offset indent -compact
myserver:/export/myclient/root  /    nfs  rw 0 0
myserver:/usr                   /usr nfs  rw 0 0
/swap                           none swap sw 0 0
.Ed
.Pp
Note, you
.Em must
specify the swap file in
.Pa /etc/fstab
or it will not be used!
See
.Xr swapctl 8 .
.Sh FILES
.Bl -tag -width /usr/mdec/rbootd -compact
.It Pa /etc/hosts
table of associated
.Tn \&IP
addresses and
.Tn \&IP
host names; see
.Xr hosts 5
.It Pa /etc/ethers
table of associated
.Tn Ethernet
.Tn MAC
addresses and
.Tn \&IP
host names used by
.Xr rarpd 8 ;
see
.Xr ethers 5
.It Pa /etc/bootparams
client root pathname and swap pathname; see
.Xr bootparams 5
.It Pa /etc/exports
exported
.Tn NFS
mount points; see
.Xr exports 5
.It Pa /etc/rbootd.conf
configuration file for
.Tn \&HP RMP ;
see
.Xr rbootd 8
.It Pa /usr/mdec/rbootd
location of boot programs offered by
.Xr rbootd 8
.It Pa /tftpboot
location of boot programs offered by
.Xr tftpd 8
.El
.Sh SEE ALSO
.Xr bootparams 5 ,
.Xr dhcpd.conf 5 ,
.Xr ethers 5 ,
.Xr exports 5 ,
.Xr fstab 5 ,
.Xr hosts 5 ,
.Xr networks 5 ,
.Xr boot 8 ,
.Xr dhcpd 8 ,
.Xr mopd 8 ,
.Xr mountd 8 ,
.Xr nfsd 8 ,
.Xr rarpd 8 ,
.Xr rbootd 8 ,
.Xr reboot 8 ,
.Xr rpc.bootparamd 8 ,
.Xr tftpd 8
.Rs
.%R RFC
.%N 903
.%D June 1984
.%T "Reverse Address Resolution Protocol"
.Re
.Rs
.%R RFC
.%N 906
.%D June 1984
.%T "Bootstrap Loading using TFTP"
.Re
.Rs
.%R RFC
.%N 951
.%D September 1985
.%T "Bootstrap Protocol"
.Re
.Rs
.%R RFC
.%N 1350
.%D July 1992
.%T "The TFTP Protocol (Revision 2)"
.Re
.Rs
.%R RFC
.%N 2131
.%D March 1997
.%T "Dynamic Host Configuration Protocol"
.Re
.Rs
.%R RFC
.%N 2132
.%D March 1997
.%T "DHCP Options and BOOTP Vendor Extensions"
.Re
.Pp
.Pa http://www.rfc-editor.org/