Re: [BUG?] Maybe NFS bug since 2.6.37 on SPARC64

[Lukas Razik <linux@razik.name>]

> Lukas Razik wrote:

> 
>   The next thing is:
>   Really all working kernels (<=2.6.36.4) first output
>    Looking up port of RPC 100003/2 on 137.226.167.241
>   then
>    Looking up port of RPC 100005/1 on 137.226.167.241
>   and then the mount is successful
>    VFS: Mounted root (nfs filesystem) on device 0:15.
>   
>   So what about >=2.6.37?
>   Why don't these kernels try other ports, too?
>   Or why do the old kernels try more than one port?
>   Why is there no output (even in the nfsdebug mode) that the kernel tries to 
> connect to the RPC service?
>   Is there a "easy" possibility to change port 100003 to 100005 in 
>> =2.6.37?
> 
> Those are the rpc numbers.  The kernel is trying to find the port numbers
> for those services.  100003 is nfs, 100005 is mount.
> I guess at this point
> I would use wireshark to find out what requests are actually being made and
> responded to in both cases.  Are you sure portmap is working on the server
> and not being blocked by a firewall?
>

When I boot from hard disk and try to mount the same exports from cluster1 on cluster2 by
# mount -t nfs cluster1:[...]
then it works immediately and without errors.

There's no firewall. But I've done a test to check it:
---
root@cluster2:~# telnet cluster1 111
Trying 137.226.167.241...
Connected to 137.226.167.241.
Escape character is '^]'.
TEST
TEST
Connection closed by foreign host.
---
So it's no problem to connect to the portmapper of cluster1 from cluster2.