Re: [bisect] kernel 2.6.38 regression with root nfs mounting
From: Belisko Marek
Date: Fri Mar 25 2011 - 03:25:19 EST
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:
>
>> On Wed, Mar 23, 2011 at 3:06 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>>>
>>> On Mar 23, 2011, at 9:46 AM, Belisko Marek wrote:
>>>
>>>> On Wed, Mar 23, 2011 at 2:44 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>>>>>
>>>>> What does "rpcinfo -p 10.146.1.21" output look like? ÂIs NFS over UDP enabled on your server?
>>>> program vers proto  port
>>>>  Â100000  Â2  tcp  Â111 Âportmapper
>>>>  Â100000  Â2  udp  Â111 Âportmapper
>>>> Â Â100024 Â Â1 Â udp Â40517 Âstatus
>>>> Â Â100024 Â Â1 Â tcp Â51397 Âstatus
>>>> Â Â100021 Â Â1 Â udp Â44516 Ânlockmgr
>>>> Â Â100021 Â Â3 Â udp Â44516 Ânlockmgr
>>>> Â Â100021 Â Â4 Â udp Â44516 Ânlockmgr
>>>> Â Â100021 Â Â1 Â tcp Â55152 Ânlockmgr
>>>> Â Â100021 Â Â3 Â tcp Â55152 Ânlockmgr
>>>> Â Â100021 Â Â4 Â tcp Â55152 Ânlockmgr
>>>>  Â100003  Â2  tcp  2049 Ânfs
>>>>  Â100003  Â3  tcp  2049 Ânfs
>>>>  Â100003  Â4  tcp  2049 Ânfs
>>>>  Â100227  Â2  tcp  2049
>>>>  Â100227  Â3  tcp  2049
>>>>  Â100003  Â2  udp  2049 Ânfs
>>>>  Â100003  Â3  udp  2049 Ânfs
>>>>  Â100003  Â4  udp  2049 Ânfs
>
> 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
>
>>>>  Â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.
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>
regards,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com
Attachment:
nfs_server_tcpdump.gz
Description: GNU Zip compressed data