Re: NFS NLM issues w/ 8.0-BETA4

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Thu, 17 Sep 2009 12:26:17 -0400 (EDT)
On Wed, 16 Sep 2009, John-Mark Gurney wrote:

> I noticed this on 7.2-R and realized that I should try this on 8.0-BETA4
> since it's about out.  I think there is an issue w/ netbooting and NFS
> locking.
>
> I setup a netboot server to export root via NFS.  I took the 8.0-BETA4
> live cd, and extracted it to the root directory of the machine.  Just
> to keep things simple, I didn't do any configuration of the image and
> booted to single user mode.  I ran rpcbind, rpc.statd and rpc.lockd.
> When I ran rpc.lockd, I get the following:
> NLM: failed to contact remote rpcbind, stat = 3, port = 28416
> NLM: failed to contact remote rpcbind, stat = 3, port = 28416
> Can't start NLM - unable to contact NSM
>
> 28416 is 111 endian swapped, but that could be an artifact of not
> swapping before printing it.
>
I think from a quick glance at the sources that you are correct, in
that it is just the printf() printing it in net byte order. (I think
a ntohs() should be added to the printf() arguement at some point.)

I don't know why it wouldn't be able to talk to the lock manager on
the server, but you might just want to try the "nolockd" option on
the root mount (I don't do diskless NFS mounts, so I don't know how
that option can be set?).

In general, I will mention that my bias is to avoid the nlm because
I believe the protocol was poorly designed. You only need it when there
are apps. that do byte range locking are accessing NFS mounted files
concurrently from multiple clients. If you don't need this, you don't
need to run rpc.statd and rpc.lockd and, if client apps. want to do
byte range locking you can use the "nolockd" option (called "nolock"
on Linux).

rick
Received on Thu Sep 17 2009 - 14:20:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:55 UTC