On Mar 25, 2011, at 3:24 AM, Belisko Marek wrote: > On Wed, Mar 23, 2011 at 3:54 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> On Mar 23, 2011, at 10:30 AM, Belisko Marek wrote: >> >> The server is advertising NFS over UDP. Why can't a client access your server via UDP? What happens if you perform a normal post-boot mount of this file system via UDP? > Strange (rootfs mounted from SD card and try to mount nfs always fail) > > mount -t nfs -o udp 10.146.1.21:/home/open-nandra/rootfs /mnt > svc: failed to register lockdv1 RPC service (errno 111). > lockd_up: makesock failed, error=-111 > mount: mounting 10.146.1.21:/home/open-nandra/rootfs on /mnt failed: > Connection refused > # mount -t nfs -o tcp 10.146.1.21:/home/open-nandra/rootfs /mnt > svc: failed to register lockdv1 RPC service (errno 111). > mount: mounting 10.146.1.21:/home/open-nandra/rootfs on /mnt failed: > Connection refused The client system isn't running a portmapper that its NFS client (specifically lockd) can talk to. That "connection refused" is due to an incorrect client configuration. A simple workaround might be to specify the "nolock" mount option for this test. > >> >>>>> 100227 2 udp 2049 >>>>> 100227 3 udp 2049 >>>>> 100005 1 udp 58278 mountd >>>>> 100005 1 tcp 37178 mountd >>>>> 100005 2 udp 58278 mountd >>>>> 100005 2 tcp 37178 mountd >>>>> 100005 3 udp 58278 mountd >>>>> 100005 3 tcp 37178 mountd >>>> >>>> Can you boot if you specify either the "tcp" or "proto=tcp" NFSROOT mount options? >>> When add proto=tcp to bootargs it boot fine >>> (....nfsroot=10.146.1.21:/home/open-nandra/rootfs,proto=tcp....). >>>> Perhaps a network trace would be probative. Capture on the server with "tcpdump -s0 -w /tmp/foo ip 10.146.1.199" (untested, but I think you get the idea) while the client is attempting to boot, and post. >>> Log is attached in attachment (too big 4.8M). Correct form is: tcpdump >>> -s0 -w /tmp/foo host 10.146.1.199 >> >> Received. I should have been clear: Please capture a non-working client boot attempt. To reduce the size of the attachment, strip the TFTP packets before sending, and please gzip the file. > tcpdump log from wrong attemp in attachment. According to the trace, the mount succeeds, and NFS requests are working. However, the server's replies to READ requests are not being seen by the client. Something on the client host or in the network is dropping them. I see successful 16KB reads, but 32KB reads do not work. Check your client for packet filtering (either intentional filtering, or accidental filtering due to configuration issues). I'll revisit the mount option defaults for NFSROOT again. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
