nfs-utils broken on ~amd64?
 

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.

nfs-utils broken on ~amd64?
 

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.

nfs-utils broken on ~amd64?
 

=== 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/>
================================================== ===================

nfs-utils broken on ~amd64?
 

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.