>>>>> "Ken" == Ken Kalafus <kkalafus@muddcs.cs.hmc.edu> writes:

Ken> I've been trying to get my 3/50 to boot from a linux machine, and have
Ken> gotten to the pointwhere it currently is able to download the boot
Ken> image, then dies:

Ken> Using IP address 134.173.48.92 = 86AD305C
Ken> No bootparam server; still trying

Ken> Obviously the problem is that there's no bootparam server running.  
Ken> The question du jour is: how do I get a bootparam server running on
Ken> the linux machine?

Does Linux have a bootparam server?  If not, you'll have to port NetBSD's.

Ken> Another problem I ran into was that the /etc/bootptab apparently isn't
Ken> being read.  The bootptab entry looks like:

Note that rpc.bootparamd (or bootparamd if it's named that) reads
/etc/bootparams, not /etc/bootptab.  bootparam and bootp are two
distinct protocols.

My /etc/bootparams file looks like this:
	slave.cygnus.com        root=orac.cygnus.com:/exports/slave/root \
		                swap=orac.cygnus.com:/exports/slave/swap
	zen.cygnus.com          root=orac.cygnus.com:/exports/zen/root \
			        swap=orac.cygnus.com:/exports/zen/swap

Ken> However, according to the syslog, the file being requested is 86AD305C
Ken> rather than /tftpboot/86AD305C.SUN3 .  As a temporary workaround, I
Ken> modified the tftp daemon:

This is normal.  The NetBSD (and Sun) tftpd has an -s (secure) option
which causes it to chdir into the directory specified on the command
line.

Ken> As long as I've still got your attention, another thing I'd appreciate
Ken> is an overview of the 3/50's diskless booting process.  I'm flying
Ken> absolutely blind without anything like a manual, and some sort of a
Ken> road map would be very helpful.

>From the NetBSD diskless(8) man page:

     When booting a system over the network, there are three phases of inter-
     action 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 machines use RARP to de-
     termine the client's IP address and then use TFTP to download a boot pro-
     gram from whoever sent the RARP reply.  Typical personal computers 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 de-
     pends on the design of the boot program.  (The design described here is
     the one used by Sun.)  The boot program:

     2.1  gets the client IP address using RARP.
     2.2  gets the client name and server IP address by broadcasting an RPC /
          BOOTPARAMS / WHOAMI request with the client IP address.
     2.3  gets the server path for this client's root using an RPC /
          BOOTPARAMS / GETFILE request with the client name.
     2.4  gets the root file handle by calling mountd(8) with the server path
          for the client root.
     2.5  gets the kernel file handle by calling NFS lookup on the root file
          handle.
     2.6  loads the kernel using NFS read calls on the kernel file handle.
     2.7  transfers control to the kernel entry point.

     In phase 3, the kernel does NFS mounts for root and swap.  The kernel re-
     peats much of the work done by the boot program because there is no stan-
     dard way for the boot program to pass the information it gathered on to
     the kernel.  The procedure used by the kernel is as follows:

     3.1  The kernel finds a boot server using the same procedure as described
          in steps 2.1 and 2.2 above.
     3.2  The kernel gets the NFS file handle for root using the same proce-
          dure as described in steps 2.3 through 2.5 above.
     3.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.
     3.4  If the kernel is configured for swap on NFS, it uses the same mecha-
          nism as for root, but uses the NFS getattr funciton to determine the
          size of the swap area.


Hope this helps.

	--jtc