[snipped]

hi Greg,

Do you have an rpc.bootparam configured with parameters for your
diskless host?


Substituting the raw addresses makes things easier, thianks.  But for
the ARP and RARP problems, we really need the MAC addresses too.  You
can get that with "tcpdump -n e [...]", i think.  Anyway, the NetBSD
diskless boot needs to do two things to mount a root filesystem.

First it needs to talk to an rpc.bootparamd server which specifies
where to find the root (and, for -current, optionally) swap.
rpc.bootparams gets its data from /etc/bootparams.  An /etc/bootparams
file that works for me is:

	client1   root=server:/export/nfsclient/client1.root/ \
	        swap=server:/export/nfsclient/client1.swap/

(delete the leading tabs.)

To find a bootparam server, the diskless machine does a broadcast RPC
to port 111, the portmapper's port, asking the portmapper to call the
rpc.bootparams server and send back the response.


This doesn't seem to be working in your setup.  The ICMP unreachable
from 131.181.17.81 is bogus, *if* 131.17.255.255 is a broadcast
address on your local net. Is it?  Or is that machine misconfigured?
And where is your rpc.bootparams server running?  What happens if you
restart it with -d (at least on NetBSD, that turns on debugging.)

Once that is fixed you can try  make more progress.


The next thing the client has to do is to contact the NFS mountd and
ask the mountd for an initial file handle.  TO do *that* it needs to:
	* contact the SunRPC portmapper on the NFS server for its
	  root partition and ask the portmapper where the mountd is
	* send the mountd an NFS mount request via SunRPC.
	* extract the initial filehandle from the mountd reply,
	  and do the local in-kernel work necessary to do the mount.
	  At that  point the root is mounted, the kernel should
	  stat the filesystem.

This doesnt' seem to be working; my guess is the client has some
totally erroneous idea of its root path.  It may not check the reply
it gets at all and just take the 



>> Are you sure? that sounds very suspicious to me. What is your subnet
>> and subnetmask?  What broadcast address are you using?

>How is that specified through rpc.bootparamd?

No, I meant what is it *really*?  Is 131.181.255.255 really your local
broadcast address? It looks to me like the kernel should really be
using 255.255.255.255 at that point instead.  Confusing. But I'd make
sure an rpc.bootparamd server is running, that it knows about your
client (Ultrix doesn't need this!) and then fixing whatever causes the
machine 131.181.17.81 to send an ICMP unreachable in response to a
broadcast.