Subject: diskless Sun3
To: Joshua Lackey <jlackey@darkwing.uoregon.edu>
From: Gordon W. Ross <gwr@mc.com>
List: port-sun3
Date: 01/10/1996 14:10:56
> Date: Mon, 8 Jan 1996 21:15:56 -0800 (PST)
> From: Joshua Lackey <jlackey@darkwing.uoregon.edu>

> Greetings,
> 
> I was wondering if it is possible to get NetBSD to run on a completely 
> diskless Sun3.  I'm currently running Xkernel on my Sun3 but I wanted to 
> play around a bit more so I thought I would check out NetBSD.  (The 
> installation instructions assume that you have a local disk but no tape 
> drive -- they mention nothing about completely diskless installation.  I 
> thought I better ask before I started to play.)
> 
> Thanks,
> Josh.

Yes, NetBSD (Sun3 and others) can run completely diskless.

The install notes make reference to the diskless(8) man page, but
do not mention that the man page also explains how to prepare an NFS
server to support diskless clients.  Perhaps that man page should
be included as an appendix to the installation notes.  Here it is:

.\"	$NetBSD: diskless.8,v 1.6 1995/09/02 17:12:32 thorpej 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 2, 1994
.Dt DISKLESS 8
.Os NetBSD
.Sh NAME
.Nm diskless
.Nd booting a system over the network
.Sh DESCRIPTION
The ability to boot a machine over the network is useful for
.Xr diskless
or
.Xr 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 Sun clients.
.Pp
.Sh OPERATION
When booting a system over the network, there are three
phases of interaction between client and server:
.Pp
.Bl -tag -width 1.2 -compact
.It 1.
The PROM (or stage-1 bootstrap) loads a boot program.
.It 2.
The boot program loads a kernel.
.It 3.
The kernel does NFS mounts for root and swap.
.El
.Pp
Each of these phases are described in further detail below.
.Pp
In phase 1, the PROM loads a boot program.  PROM designs
vary widely, so this phase is inherently machine-specific.
Sun machines use
.Tn RARP
to determine the client's
.Tn IP
address and then use
.Tn TFTP
to download a boot program from whoever sent the
.Tn RARP
reply.  HP 300-series machines use the
.Tn HP Remote Maintainance Protocol
to download a boot program.
Typical personal computers may load a
network boot program either from diskette or
using a special PROM on the network card.
.Pp
In phase 2, the boot program loads a kernel.  Operation in
this phase depends on the design of the boot program.
(The design described here is the one used by Sun and NetBSD/hp300.)
The boot program:
.Pp
.Bl -tag -width 2.2 -compact
.It 2.1
gets the client IP address using
.Tn RARP .
.It 2.2
gets the client name and server
.Tn IP
address by broadcasting an
.Tn RPC / BOOTPARAMS / WHOAMI
request with the client IP address.
.It 2.3
gets the server path for this client's
root using an
.Tn RPC / BOOTPARAMS / GETFILE
request with the client name.
.It 2.4
gets the root file handle by calling
.Xr mountd 8
with the server path for the client root.
.It 2.5
gets the kernel file handle by calling
.Tn NFS
lookup on the root file handle.
.It 2.6
loads the kernel using
.Tn NFS
read calls on the kernel file handle.
.It 2.7
transfers control to the kernel entry point.
.El
.Pp
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:
.Pp
.Bl -tag -width 2.2 -compact
.It 3.1
The kernel finds a boot server using the same procedure
as described in steps 2.1 and 2.2 above.
.It 3.2
The kernel gets the
.Tn NFS
file handle for root using the same procedure
as described in steps 2.3 through 2.5 above.
.It 3.3
The kernel calls the
.Tn NFS
getattr function to get the last-modified time of the root
directory, and uses it to check the system clock.
.It 3.4
If the kernel is configured for swap on
.Tn NFS ,
it uses the same mechanism as for root, but uses the
.Tn NFS
getattr funciton to determine the size of the swap area.
.El
.Sh CONFIGURATION
Before a client can boot over the network,
its server must be configured correctly.
This example will demonstrate how a Sun client
might be configured -- other clients should be similar.
.Pp
Assuming the client's hostname is to be
"myclient",
.Pp
.Bl -tag -width 2.1 -compact
.It 1.
Add an entry to 
.Pa /etc/ethers
corresponding to the client's ethernet address:
.Bd -literal -offset indent -compact
8:0:20:7:c5:c7          myclient
.Ed
This will be used by
.Xr rarpd 8 .
.Pp
.It 2.
Assign an IP address for myclient in your
.Pa /etc/hosts
or DNS database:
.Bd -literal -offset indent -compact
192.197.96.12           myclient
.Ed
.Pp
.It 3.
If booting a Sun machine, ensure that
.Pa /etc/inetd.conf
is configured to run
.Xr tftpd 8
in the directory
.Pa /tftpboot .
.Pp
If booting an HP 300-sseries machine, ensure that
.Pa /etc/rbootd.conf
is configured properly to transfer the boot program to the client.
An entry might look like this:
.Bd -literal -offset indent -compact
08:00:09:01:23:E6	SYS_NBOOT	# myclient
.Ed
.Pp
See the
.Xr rbootd 8
manual page for more information.
.Pp
.It 4.
If booting a Sun machine, install a copy of the appropriate diskless boot
loader (such as
.Pa boot.sun4.sunos.4.1.1
from the SunOS media) in the
.Pa /tftpboot
directory.
Make a link such that the boot program is
accessible by a file name composed of the client's IP adddress
in HEX, a dot, and the architecture name (all upper case).
For example:
.Bd -literal -offset indent -compact
# cd /tftpboot
# ln -s boot.sun4.sunos.4.1.1 C0C5600C.SUN4
.Ed
.Pp
For a Sun3 machine, the name would be just C0C5600C
(the sun3 PROM does not append the architecture name). The name
used is architecture dependent, it simply has to match what the
booting client's PROM wishes to it to be.
If the client's PROM fails to fetch the expected file,
.Xr tcpdump 8
can be used to discover which filename the client is trying to read.
.Pp
If booting an HP 300-series machine, ensure that the network boot program
.Pa SYS_NBOOT
(which may be called
.Pa netboot.lif
before installation)
is installed in the directory
.Pa /usr/mdec/rbootd .

.It 5.
Add myclient to the bootparams database
.Pa /etc/bootparams :
.Bd -literal -offset indent -compact
myclient  root=server:/export/myclient/root \\
          swap=server:/export/myclient/swap
.Ed
.Pp
.It 6.
Build the swap file for myclient:
.Bd -literal -offset indent -compact
# mkdir /export/myclient
# cd /export/myclient
# dd if=/dev/zero of=swap bs=16k count=1024
.Ed
This creates a 16 Megabyte swap file.
.Pp
.It 7.
Populate myclient's
.Pa /
filesystem on the 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
filesystem, or perhaps you need to get those files out of the
standard binary distribution.
.Pp
.It 8.
Export the required filesystems in
.Pa /etc/exports :
.Bd -literal -offset indent -compact
/usr -ro myclient
# for SunOS:
# /export/myclient -rw=myclient,root=myclient
# for NetBSD:
/export/myclient -maproot=root myclient
.Ed
.Pp
If the server and client are of the same architecture, then the client
can share the server's
.Pa /usr
filesystem (as is done above).
If not, you must build a properly fleshed out
.Pa /usr
partition for the client in some other place.
.Pp
If your server was a sparc, and your client a sun3,
you might create and fill
.Pa /export/usr.sun3
and then use the following
.Pa /etc/exports
lines:
.Bd -literal -offset indent -compact
/export/usr.sun3 -ro myclient
/export/myclient -rw=myclient,root=myclient
.Ed
.Pp
.It 9.
Copy and customize at least the following files in
.Pa /export/myclient/root :
.Bd -literal -offset indent -compact
# cd /export/myclient/root/etc
# cp fstab.nfs fstab
# cp /etc/hosts hosts
# echo myclient > myname
# echo 192.197.96.12 > hostname.le0
.Ed
.Pp
Note that "le0" above should be replaced with the name of
the network interface that the client will use for booting.
.Pp
.It 10.
Correct the critical mountpoints in the client's
.Pa /etc/fstab
(which will be
.Pa /export/myclient/root/etc/fstab )
ie.
.Bd -literal -offset indent -compact
myserver:/export/myclient/root / nfs rw 0 0
myserver:/usr /usr nfs rw 0 0
.Ed
.El
.Sh FILES
.Bl -tag -width /usr/mdec/rbootd -compact
.It Pa /etc/ethers
Ethernet addresses of known clients
.It Pa /etc/bootparams
client root and swap pathnames
.It Pa /etc/exports
exported NFS mount points
.It Pa /etc/rbootd.conf
configuration file for HP Remote Boot Daemon
.It Pa /tftpboot
location of boot programs loaded by the Sun PROM
.It Pa /usr/mdec/rbootd
location of boot programs loaded by the HP Boot ROM
.El
.Sh "SEE ALSO"
.Xr rarpd 8 ,
.Xr ethers 5 ,
.Xr tftpd 8 ,
.Xr rpc.bootparamd 8 ,
.Xr bootparams 5 ,
.Xr mountd 8 ,
.Xr exports 5 ,
.Xr nfsd 8 ,
.Xr rbootd 8 ,
.Xr reboot 8