[This is an abbreviated version, for the list, of what I sent directly
to the poster.]

>> if you can capture the packet contents somehow and get them to me,
>> I'll be glad to unpack them and see if I can see anything.
> Ok; this is really verbose, so I'm a bit wary of sending it to the
> list,

Well, that's (part of) why I said send them to _me_.

> but in the hope that it'll be useful, here's the tail end of
>  tcpdump -i ed1 -vv -s 192 -x
> while booting.  The slab of NFS reads is the kernel load, that works fine.

tcpdump (a) seems to be truncating packets and (b) throwing away
critical information.  At least, _something_ chopped about a thousand
bytes off the end of the second packet you quoted (fortunately, nothing
but the end of the data portion of an NFS read reply seems to have been
lost); and it's stripped off the Ethernet header, including the
Ethernet type field, so I can't unpack anything but the IP packets, and
I'm having to guess which ones those are.  _Full_ packet contents would
have been helpful.  In any case, the relevant thing seems to be the
last two packets:

09:58:01.896846 salty.1023 > lovely.679: udp 92 (ttl 64, id 7)
	45                       ip_hl=5 ip_v=4
	00                       ip_tos [Routine]
	00 78                    ip_len [120]
	00 07                    ip_id
	00 00                    ip_off [0]
	40                       ip_ttl [64]
	11                       ip_p [UDP]
	50 6a                    ip_sum
	ca 00 4b 02              ip_src [202.0.75.2]
	ca 00 4b 01              ip_dst [202.0.75.1]
	03 ff                    uh_sport [1023]
	02 a7                    uh_dport [679]
	00 64                    uh_ulen [100]
	b0 a5                    uh_sum
	                         RPC packet
	ff ff ff 08              xid 0xffffff08
	00 00 00 00              type 0 [CALL]
	00 00 00 02              RPC version 2
	00 01 86 a5              Program 100005 [mount]
	00 00 00 01              Program version 1
	00 00 00 01              Procedure 1
	00 00 00 01              Credentials type 1 [AUTH_UNIX]
	00 00 00 14              Credentials length 20
	00 00 00 00              Credentials stamp 0x00000000
	00 00 00 00              Credentials machine name len = 0
	                                   Credentials machine name string
	00 00 00 00              UID 0
	00 00 00 00              GID 0
	00 00 00 00              Group count 0
	00 00 00 00              Verification type 0 [AUTH_NULL]
	00 00 00 00              Verification length 0
	                         mount MNT request
	00 00 00 19              dirpath len = 25
	2f 6c 6f 63 61 6c 32 2f  /local2/
	65 78 70 6f 72 74 2f 73  export/s
	61 6c 74 79 2f 73 77 61  alty/swa
	70                       p         dirpath string
	ff ff ff                 dirpath padding
09:58:01.915274 lovely.679 > salty.1023: udp 28 (ttl 64, id 16159)
	45                       ip_hl=5 ip_v=4
	00                       ip_tos [Routine]
	00 38                    ip_len [56]
	3f 1f                    ip_id
	00 00                    ip_off [0]
	40                       ip_ttl [64]
	11                       ip_p [UDP]
	11 92                    ip_sum
	ca 00 4b 01              ip_src [202.0.75.1]
	ca 00 4b 02              ip_dst [202.0.75.2]
	02 a7                    uh_sport [679]
	03 ff                    uh_dport [1023]
	00 24                    uh_ulen [36]
	cf ef                    uh_sum
	                         RPC packet
	ff ff ff 08              xid 0xffffff08
	00 00 00 01              type 1 [REPLY]
	00 00 00 00              Status 0 [ACCEPTED]
	00 00 00 00              Verification type 0 [AUTH_NULL]
	00 00 00 00              Verification length 0
	00 00 00 00              Accept status 0 [SUCCESS]
	                         mount MNT reply
	00 00 00 02              status = 2 [No such file or directory]

The NFS server (more precisely, the mount daemon on the NFS server) is
refusing to give out a file handle for /local2/export/salty/swap,
claiming ENOENT.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu