[gentoo-user] nfs-utils broken on ~amd64?

[gentoo-user] nfs-utils broken on ~amd64?

[walt]

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?

Re: [gentoo-user] nfs-utils broken on ~amd64?

[Alan McKinnon]

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

Re: [gentoo-user] nfs-utils broken on ~amd64?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Mon, 15 Feb 2010 22:28:08 +0200, Alan McKinnon wrote:

> 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.

Yes, but it's changing now. The reason the ebuild has changed from nonfs4
to nfs4 is that it is now possible to turn the flag on by default in the
ebuild, which is particularly useful for local flags that can't be set in
a profile.


-- 
Neil Bothwick

You have the capacity to learn from mistakes. You'll learn a lot today.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: nfs-utils broken on ~amd64?

[walt]

On 02/15/2010 12:28 PM, Alan McKinnon wrote:
> 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.

I did not include nfs4 in my kernel because it was marked 'experimental'.
(Hey, just because I choose to run ~amd64 doesn't mean I'm reckless ;o)

I set the 'nonfsv4' USE flag and recompiled nfs-utils but got exactly the
same error.

The next step is to build a new kernel with nfs4 support and unset the
'nonfsv4' flag, but at the moment I'm running a ver-r-r-y long partition
resize with gparted so that I can add more space to my experimental lvm2
volumes.  (Working great so far.)  I think I'll fall asleep before gparted
is finished, so I'll supply more information tomorrow.

Re: [gentoo-user] Re: nfs-utils broken on ~amd64?

[Keith Dart]

=== On Mon, 02/15, walt wrote: ===
> The next step is to build a new kernel with nfs4 support and unset the
> 'nonfsv4' flag, but at the moment I'm running a ver-r-r-y long
> partition resize with gparted so that I can add more space to my
> experimental lvm2 volumes.  (Working great so far.)  I think I'll
> fall asleep before gparted is finished, so I'll supply more
> information tomorrow.
===

I had this problem. My solution was to have an fstab line like this:

server:/mnt/vol1/home/home		/althome nfs		nfsvers=3	0 0

Note the nfsvers option.



-- Keith Dart

-- 

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Keith Dart <keith@dartworks.biz>
   public key: ID: 19017044
   <http://www.dartworks.biz/>
   =====================================================================

[gentoo-user] Re: nfs-utils broken on ~amd64?

[walt]

On 02/15/2010 10:51 PM, Keith Dart wrote:
> === On Mon, 02/15, walt wrote: ===
>> The next step is to build a new kernel with nfs4 support and unset the
>> 'nonfsv4' flag...
>
> I had this problem. My solution was to have an fstab line like this:
>
> server:/mnt/vol1/home/home		/althome nfs		nfsvers=3	0 0
>
> Note the nfsvers option.

Thanks, that works.  On the command line I added -o nfsvers=3, which does the same
thing.  That certainly violates the principle of least surprise, IMO.  The man
page (written in 2006) says that nfs3 is assumed if no version is specified.