Wes Brown wrote:
> The console then gives me the entire comment header (that I did not get a
> chance to copy down) and stuff that looks like this:
> 
> Boot: [netbsd][-s][-a][-d] :-
> boot: client IP address: 129.22.56.15
> bootparamd: 'whoami' call failed

> My questions:  Is this thing actually booting?  (At least halfway?)  Just a
> Yes to that question will make me happy.

Yes :-> It's got as far as completing the rbootd sequence, I think.
It's only done the small half, though...

> Making a swap area on an NFS exported drive:  Do I just need to export and
> empty directory?

You need to create a file of the correct size (use dd from /dev/null).
Be aware that the standard kernel will probably fall over if it tries
to swap to an NFSmounted Linux box (I could make my compiled kernel
available, I suppose; it might suit your config. I'm not about to
compile a generic+1K NFS though - kernel compile time is >3 hours...)

> Does network traffic effect this boot situation?

Pass. My HP now seems to not boot until you run tcpdump to see what's
stuck! 

>  Does this box need to have an HP-IB drive attached to it?  

Well, mine doesn't. It should just boot straight from network if
you've got no drives.

> rpc.bootparamd is giving this in debug mode:
> whoami got question for 129.22.56.15
> This is host snowhite.eeap.cwru.edu
> Returning snowhite   (none)    127.0.0.1

This seems to be right as far as it goes. After this you should get:
getfile got question for "tiroth" and file "root"
returning server:dram path:/export/hp/root/ address: 192.168.1.1
getfile got question for "tiroth" and file "swap"
returning server:dram path:/export/hp/swap address: 192.168.1.1

as it requests the root filesystem and swap.

What does tcpdump say is actually going on on the network?
After the rbootd stuff you should have something like:
22:02:02.790155 rarp who-is 8:0:9:3:24:1 tell 8:0:9:3:24:1
22:02:02.790155 rarp reply 8:0:9:3:24:1 at tiroth
22:02:02.940162 tiroth.1023 > 255.255.255.255.sunrpc: udp 96
22:02:03.270177 mnementh.sunrpc > tiroth.1023: udp 76
22:02:03.410183 arp who-has mnementh tell tiroth
22:02:03.410183 arp reply mnementh is-at 0:0:1b:24:90:1
22:02:03.500187 tiroth.1022 > mnementh.666: udp 80
22:02:03.500187 mnementh.666 > tiroth.1022: udp 72
22:02:03.660194 tiroth.1021 > mnementh.sunrpc: udp 76
22:02:03.690195 mnementh.sunrpc > tiroth.1021: udp 28
22:02:03.780199 tiroth.1021 > mnementh.755: udp 80
22:02:04.310223 mnementh.755 > tiroth.1021: udp 60
22:02:04.420228 tiroth.1021 > mnementh.sunrpc: udp 76
22:02:04.420228 mnementh.sunrpc > tiroth.1021: udp 28
<nfs stuff starts here>

Make sure the HP's arp request to find out the server is satisfied.
If there are arp requests from the server asking for the HP's 
ethernet address, you've forgotten to put it in the server's arp table.
I seem to recall that this is the behaviour you get in this instance,
but I could be wrong. Don't like the look of that xmit error, either.

Peter Maydell
[who isn't feeling too awake; take this advice with caution :-> ]