Well, for the first time I've actually set up a NetBSD client to boot
off a NetBSD server.  Unfortunately it's left a lot to be desired over
my experiences of using SunOS-4 on the server.

First off I should mention that I'm using NetBSD-971112 on Sun-3's.

The diskless(8) manual page is incomplete and in some cases misleading,
and other cases just plain wrong.  Hopefully I'll be able to send-pr a
more specific list of details and fixes on this soon.

My most pressing bug is not knowing what's going on here:

Nov 19 15:26:26 sometimes rpc.bootparamd: whoami got question for 204.92.254.3
Nov 19 15:26:26 sometimes rpc.bootparamd: This is host very.weird.com
Nov 19 15:26:26 sometimes rpc.bootparamd: Returning very.weird.com   weird.com    204.92.254.6
Nov 19 15:26:27 sometimes rpc.bootparamd: getfile got question for "very.weird.com" and file "root"
Nov 19 15:26:27 sometimes rpc.bootparamd: returning server:sometimes path:/export/root/very address: 204.92.254.6
Nov 19 15:26:27 sometimes rpc.bootparamd: getfile got question for "very.weird.com" and file "gateway"
Nov 19 15:26:27 sometimes rpc.bootparamd: getfile failed for very.weird.com

The last two lines repeat seven more times and cause the client machine
to complain "nfs_boot: timeout...".  It works, but it's definitely not
clean or fast.

I've tried adding a "gateway=204.92.254.5" entry to my /etc/bootparams
to specify a default router, but this made no difference.  I'm at a loss
as to what else it might want, though I must admit I've not yet looked
at the source in any detail.  I will note that it doesn't do this during
the netboot phase, but only during the kernel's repeat of the nfs root
mount.

A second minor but extremely time-consuming problem was that
/etc/bootparams seems unable to support truely generic continuation
lines like the SunOS version does (and though the manual page makes this
claim and gives an example of using continuation lines).  I'll send-pr
this ASAP too, though unfortunately without a fix, assuming it's not
already been reported.

In the end I booted with this in /etc/bootparams

very.weird.com root=sometimes:/export/root/very swap=sometimes:/export/swap/very gateway=204.92.254.2

Being that I must support multiple server and client architectures on my
network I started out trying to set up a /export/{share,exec,root}
scheme just like SunOS-4 has.  Unfortunately I wasn't very successful
because of limitations in mountd and /etc/exports, such as the refusal
to export a symlink, and the inability to export sub-trees with
different options, such as exporting /usr read-only, and then exporting
/usr/share read-write (to allow clients to re-format manual pages...).
I ended up with just this:

/var/root.export/root/very -maproot=root very.weird.com
/var/root.export/swap/very -maproot=root very.weird.com
/usr -maproot=root -ro very.weird.com

These restrictions may be due to security issues, but I can't think of
any real reason for them.  The first (re: symlinks) is mentioned in the
manual page (though without justification), but the latter is not and
may be a bug.  They certainly cramp one's ability to build a regularized
client support system without wasting disk space for a second copy of
the server's architecture and OS type files.

Finally I found it an extremely time-consuming and error prone procedure
to build the client root directory.  Admittedly I was working off the
sun3 snapshot distribution and not a real distribution, but it seems as
if it would be a good idea to include a procedure for building a
'prototype' root from either the running system or from the build
directory, and to include an 'installclient' script ala SunOS-4.  Simple
things, such as /usr, were missing after the unpacking....  I dare say I
wouldn't want to have to hand-hold someone who wasn't an experienced
unix systems programmer through the current procedure.  Unfortunately I
don't think I'll have time to write any such tools in the near future.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>