nfs-utils broken on ~amd64?
 

Anyone else having problems mounting nfs shares with nfs-utils-1.2.1?

'mount.nfs' complains I'm passing it a bad nfs option no matter what
options I give it, including no options.

Strace shows that nfs.mount is passing a weird-looking IP address
string to the 'mount' system call (man 2 mount), e.g.:

mount("k2:/media/d", "/mnt/nfs", "nfs", 0, "addr=192.168.0.100,vers=4,client"...) = -1 EINVAL
^^^^^^^^^^^^^^

When I revert back to nfs-utils-1.1.4-r1 the IP address string is
back to normal and the mount works correctly, e.g.:

mount("k2:/media/d", "/mnt/nfs", "nfs", 0, "addr=192.168.0.100") = 0

Something is tacking on those extra chars after the IP address, but
I'm not sure yet where that string is actually generated.

Any ideas?

nfs-utils broken on ~amd64?
 

On Monday 15 February 2010 21:23:54 walt wrote:
> Anyone else having problems mounting nfs shares with nfs-utils-1.2.1?
>
> 'mount.nfs' complains I'm passing it a bad nfs option no matter what
> options I give it, including no options.
>
> Strace shows that nfs.mount is passing a weird-looking IP address
> string to the 'mount' system call (man 2 mount), e.g.:
>
> mount("k2:/media/d", "/mnt/nfs", "nfs", 0,
> "addr=192.168.0.100,vers=4,client"...) = -1 EINVAL


At first glance I suspect you have nfs v4 support and the server does not like
it.

The USE flag changed at 1.1.6-r1 from nonfsv4 to nfsv4 so if you did not
change USE you will get the exact opposite support between the earliest and
most recent version in portage.

<pet hate>
Don't you just hate negative USE flags on the lines of no* ? You have to
switch then on to not get something. Far better to have a positive flag and
enable it by default in the profile. Not to mention the confusion that
changing it later causes, witness this case here.





> ^^^^^^^^^^^^^^
>
> When I revert back to nfs-utils-1.1.4-r1 the IP address string is
> back to normal and the mount works correctly, e.g.:
>
> mount("k2:/media/d", "/mnt/nfs", "nfs", 0, "addr=192.168.0.100") = 0
>
> Something is tacking on those extra chars after the IP address, but
> I'm not sure yet where that string is actually generated.
>
> Any ideas?

--
alan dot mckinnon at gmail dot com