nfs-utils-2.1.1

[bdubbs@…]

This needs investigating. We have now 1.3.4.

[bdubbs@…]

nfs-utils-2.1.1 has just been released. This is a major release because the configuration of the NFS server has fundamentally changed.

All the daemon configurations now go through one file, /etc/nfs.conf. See nfs.conf(5).

The command line interface in the systemd service files have been removed. This means the configuration file under /etc/sysconfig or /etc/defaults will no longer work.

I'm leaving it up to the distros to figure out how to deal with the backwards compatibility issue if/when they adopt this version.

I believe this is right way to go. There are a number of external projects looking to configure the NFS server and having one file to deal with is a good thing...

The release also contains a number of bug fixes and improvements.

[ken@…]

Bruce asked me for comments on this - it will take a while before I can complete looking at it (too much else of high priority), but here are my first four comments:

1. My own script still had a sed which is no-longer in BLFS. I've now removed that, it was in the daemon part of the file so irrelevant to a client.
2. Before noticing that, I built it on a desktop (client) system with a toolchain from August. Rebooted, nfs3 r/w mounts working.
3. I then went back to another system and did a DESTDIR install to create the nfs.conf.5 manpage. BUT /etc/nfs.conf did NOT get installed. There is an nfs.conf in the top level of the source, with everything commented - I am guessing those are the default values (and anything commented will be ignored even if this file was installed). In particular, nfs v4 and gssapi are mentioned. At the moment, I'm guessing we do NOT want to install /etc/nfs.conf.
4. Things might differ in systemd, but I see that Arch has now moved to 2.1.1 and that wiki does not mention /etc/nfs.conf under nfs, although there is an existing reference to such a file (but apparently with very different content) on OSX clients in the NFS Troubleshooting page. So, if it works ok on sysv then it will probably also work on systemd.

I still need to build it on my test server, and then try mounting (nfs v3) from both old and new clients.

[ken@…]

Bad news.

I've added the following line to /etc/fstab on both old and new systems:

testserver:/home/ken/crap /home/ken/nfs-testing nfs rw,hard,noauto,user 0 0

The old desktop system was able to mount that with the testserver running the old version of nfs-utils, and after I upgraded the version on the testserver it was still able to mount it.

The new desktop system continues to mount the normal old nfs systems from my main server, although I now notice that there is an error message to the effect that rpcbind is not running (the mount seems ok).

But the new desktop system fails to mount the newserver:

mount.nfs: an incorrect mount option was specified

I tried to force version 3, but it didn't like that. This all sounds suspiciously like past problems. No time to try to work around this for the moment, this is a BLOCKER.

[bdubbs@…]

I just installed this version on both my workstation and development system. My workstation is rarely rebooted so that is the server. The exported fs is /srv/src (about 100G of data). On the client:

sudo mount.nfs lfs78:/srv/src /srv/src

worked just fine. I'll automate that a little bit later, but a vanilla install using book instructions seems ok to me.

[ken@…]

Got back to the old desktop (the bootscript is the client version from the current BLFS scripts). Made sure my build exactly matched the current book, rebuilt 2.1.1. Rebooted - again the message about rpcbind not running. Booted the test server, tried to mount it, the same error from mount.nfs.

Changed my script to build 1.3.4 by the book, did that, rebooted. No change. My automatic mounts from a 1.3 server continue to work but the bootscript still tells me rpcbind is missing and needed, and trying to mount as a user from the test server running 2.1.1 still fails in the same way.

I tried using -V option with mount.nfs to prove I was back to 1.3.4, but it just lists the short options (including -V) it claims to support. I'm now somewhat worried, because my build with a sed and a switch to disable ipv6 previously worked and I had not noticed the rpcbind error - not saying it didn't happen, only that I first noticed it on this machine after the changes.

[bdubbs@…]

Did you build and run rpcbind?

$ ps -ef|grep rpc
root        79     2  0 13:15 ?        00:00:00 [rpciod]
root       656     1  0 13:15 ?        00:00:00 /sbin/rpcbind
root       682     1  0 13:15 ?        00:00:00 /usr/sbin/rpc.statd --no-notify

It's needed for both the client and server.

[bdubbs@…]

Fixed at revision 18208.

[ken@…]

Replying to bdubbs@…:

Did you build and run rpcbind?

$ ps -ef|grep rpc
root        79     2  0 13:15 ?        00:00:00 [rpciod]
root       656     1  0 13:15 ?        00:00:00 /sbin/rpcbind
root       682     1  0 13:15 ?        00:00:00 /usr/sbin/rpc.statd --no-notify

It's needed for both the client and server.

Yes, of course.

from boot.log

Jan 25 03:50:18 +00:00 ac4tv  Starting rpcbind OK
Jan 25 03:50:18 +00:00 ac4tv  Starting NFS statd... OK
Jan 25 03:50:18 +00:00 ac4tv  Starting CUPS Printserver... OK
Jan 25 03:50:18 +00:00 ac4tv  Initializing kernel random number generator... OK
Jan 25 03:50:19 +00:00 ac4tv  Starting ntpd... OK
Jan 25 03:50:19 +00:00 ac4tv  Mounting network volumes... OK

and from ps aux | grep rpc

root        40  0.0  0.0      0     0 ?        S<   03:49   0:00 [rpciod]
root       854  0.0  0.0   8660   200 ?        Ss   03:50   0:00 /sbin/rpcbind
root       999  0.0  0.0  11148  1920 ?        Ss   03:50   0:00 rpc.statd --no-notify
ken       6828  0.0  0.0 115136  2052 pts/4    R+   04:13   0:00 grep rpc

I had not intended to reply for the moment, but since you posted that comment and then made the change and closed the ticket -

I looked at git to see what/when I changed in my build scripts. The key part appeared to be:

commit 07bff8446e18e448fe457aa2211c9e8363de1776
Author: ken <ken@linuxfromscratch.org>
Date:   Sun Feb 22 01:08:09 2015 +0000

    nfs-utils : try to make it work.

    1. turn off ipv6, to reduce error messages from the bootscript.

    2. sed the build to allow it to start - apparently this also affect
    nfsv4 on systemd, but perhaps it does not affect nfsv2.

So apparently I had not followed through on the need for that with nfs v3 - ISTR you do not use tcp for nfs and you enable ipv6 in your kernel. Anyway, FWIW the sed is/was

sed -i "/daemon_init/s:\!::" utils/statd/statd.c

But rebuilding 1.3.4 with both of those added has gained me nothing. At some point I will have to watch carefully when I boot the other (7.10) desktop, to make sure that I haven't been overlooking the spurious error messages.

Meanwhile, on this (LFS-20160808, BLFS-20160804) box I still cannot mount the 2.1.1 server.

For the moment this is a low priority for me (the new version is now in the book), I'm rebuilding firefox on this box.

[bdubbs@…]

I thought I had disabled ipv6, but checking config, it is enabled. Looking at my logs

grep -i ipv6 kern.log

Jan 24 13:15:48 frodo7a kernel: [    6.607071] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
Jan 24 13:15:48 frodo7a kernel: [    9.679101] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 24 13:15:51 frodo7a kernel: [   12.579312] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Generally I follow the book's instructions pretty closely, so yes, I'm running nfs using udp. nfs is working quite well for me.

[ken@…]

Just in case anybody who cares finds this from google, a closure:

I have _no_idea_ what broke my system from August 2016, reverting nfs-utils (as noted above) and updating the bootscripts did not help. That system has (had) two problems:

1. The message about rpcbind during the boot was coming from the initial mount, the later start of rpcbind, followed by mounting nfs, was fine.

2. The error messages from trying to mount the new share were a different problem (and the showstopper).

I tried updating util-linux to current (2.29.1), and all the possible variations for trying to force v3 in fstab for user mounting and even trying to force udp (root could mount it, it fell back to udp). Nothing made any difference.

Then I looked at a different box where all my old released systems live - the oldest which I still claim to maintain is 7.7, the newest 7.10. On all of those, the old nfs-utils succeeded in mounting from my test server running 2.1.1. After that I went back to the previous system on the problematic machine (June 2015) - again, old nfs can mount from the test server running new nfs.

I've given up and moved my builds to 2.1.1 : At the moment I'm part-way through a new build on the problematic machine (got past firefox, so I can post this) : everything is working.

That system from August 2016 is now dead to me, still no idea why it broke, but I'm moving on.