> From: "Robert L. Shady" <rls@zeus.id.net>
> Date: Thu, 5 May 1994 18:14:20 +1523847 (EDT)
> 
> I am *VERY* interested in this processes, a complete description from
> beginning to end would be wonderful right about now since I have machines,
> but I have NO hard drives..  Well, to spare that is.. ;)

Diskless boot works as long as you have a boot program that can get
your kernel loaded into memory somehow.  I am using the SunOS boot
program because netboot has not yet been ported to the Sun3.

I'll try to describe both boot programs, but be warned that my
description of netboot will probably be inaccurate.

First, the basic steps in diskless boot are as follows:

1  PROM Loads a bootstrap program
2  Bootstrap determines client IP address and server
3  Bootstrap loads a kernel from the server
4  Kernel determines client IP address, server(s),
   and path names for root and swap
5  Kernel does NFS mounts for root and swap

Steps 1-3 are, of course, quite machine specific.

On a Sun machine, the bootstrap gets loaded as follows:
1a  PROM does RARP to determine client and server IP addresses
1b  PROM does TFTP to download bootstrap from server
2   Bootstrap (Sun's that is) does RPC to bootparamd to
    determine the path name for root (to get the kernel)
3   Bootstrap does NFS reads to load kernel (from root path)

On a PC, you could load the netboot program from a floppy, or
if you have an appropriate Ethernet PROM, that could load it.
Once netboot (the NetBSD bootstrap) is loaded, it does this:
2   Uses BOOTP (or RARP?) to get client and server IP addresses
3   Uses TFTP (or NFS?) to download a kernel

When the kernel is loaded, it receives little or no information
from the boot program, so it needs to AGAIN determine the IP
addresses for client and server, request path names, etc.
The kernel uses RARP and BOOTP for this, regardless of what
the boot program uses.  (For example, my use of the SunOS
bootstrap means I need both rpc.bootparamd and bootpd running
on my server to answer questions from the bootstrap and kernel.)

In short, your server needs to be running rarpd, bootpd, and
possibly rpc.bootparamd as well, all informed of your client.

The current NFS mount_root implementation uses BOOTP to get the
path names for root and swap.  In fact, it kind of misuses the
"boot file name" part of the BOOTP response packet to get it.
The client sends a BOOTP request with "root" as the boot file
name, and expects the reply to have something like:
	"/export/myclient/root"
as the boot file name.  The client then sends another request
with "swap" as the boot file and expects something like:
	"/export/myclient/swap"
as the boot file name.  Not all bootp servers like this.
The bootp server I am maintaining (from CMU originally, and
now up to version 2.3.7) did not until recently allow for
the boot-file-name to change from one request to another.
(Time to check in the latest version, I guess...)

Here is a sample bootptab entry for a diskless NetBSD client:

# Note that you need to zap the "tftp dir" (td) and set the
# home directory (hd), and hd must be common prefix string
# to which "root" or "swap" may be appended to for the reply.
walnut:tc=.subnet16:ha=walnut:sa=merlin-gw:\
	:td@:hd=/export/walnut/:

You can test the above entry using "bootptest" (part of the
bootp package).  For example:

% bootptest -f root walnut
bootptest: version 2.3.7
Sending to 192.233.16.24 (request) htype:0 hlen:0 xid:11998 \
 C:192.233.16.24 file:"root" vend-rfc1395
Recvd from 192.233.16.24 (reply) htype:0 hlen:0 xid:11998 \
 C:192.233.16.24 S:192.233.17.32 sname:"walnut" \
 file:"/export/walnut/root" vend-rfc1395 \
 SM:255.255.255.0 GW:192.233.16.15 TZ:18000 \
 DNS:192.233.16.15,192.233.16.4 \
 DNAM:"mc.com" HN:"walnut"
% 

I hope this helps more than it confuses...
Gordon Ross

------------------------------------------------------------------------------