On Sun, 7 Nov 1999, Evan Brewer wrote:

> nfs_boot: bootparam whoami, error=60

> something on the NFS server, as for what? I cannot tell.

It is trying t access bootparamd.  The boot sequence is:

RARP with hwaddr ->
                 <- reply with ipaddr
bootparam whoami ->
                 <- hostname
bootparam 
 getfile 'root'  ->
                 <- ipaddr and path of root FS
bootparam 
 getfile 'gateway'->
                 <- ipaddr of default router and subnet mask

So, your bootparamd is not working at all if you get stuck at whoami.  
Try adding your clients' and servers' hostnames to the /etc/hosts file.  
If that doesn't work, you'll have to debug bootparamd.  If you know how to
write code, you can recompile it and use gdb on rpc.bootparamd--this
helped me a bit, with a problem on the alpha a while back.  You might also
try tcpdump, but i'm not sure it would tell you much.  Lastly you might
turn on some debugging in portmap, to see if you can verify that the
client is at least getting rpc.bootparamd's port number from the
portmapper.

you could look for errors in how bootparamd is set up, or try running your
bootparamd server of a SunOS or NetBSD box instead of Linux--it probably
doesn't get much testing on the Linux platform, since Linux (a) mostly
doesn't support being netbooted, and (b) never uses bootparamd when it
does netboot.

> this next item isnt stopping me, but is slowing
> the boot process down considerably: 
> 
> getfile got question for "client" and file "gateway"
> getfile failed for client

This was discussed on the list a few days ago i think.  The fix is to use
something like

rynn	root=/export/netbsd-nfsroot/rynn \
	gateway=192.168.0.1:255.255.255.0

where 192.168.0.1 and 255.255.255.0 are your default router and subnet
mask respectively.

Incidentally, I think the reason Sun punts and uses -r instead of gateway=
like we do, is that in the Sun Master Plan you have bootparams in a NIS
map, and you run one bootparamd on each subnet.  so, presumably default
routers are uniform across a given subnet, and needn't be part of the NIS
map--anyone who asks the question on Wire X should get Answer Y, therefore
no need to store the information higher up.  but, i do like our way
better.  the Sun Master Plan is a pain.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US