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