nfs mounts should have the 'nolocks' option
Bjoern Brill <brill@samson.math.uni-frankfurt.de> writes:
> I the following came up while testing m68k boot floppies, but I
> think should be discussed on -boot, not -68k.
I agree.
> On 19 Apr 2000, Chris Baker wrote:
> > I'm guessing you didn't mount /var with the `nolocks' option? Or
> > maybe it's a different problem....
>
> It is this problem. dbootstrap doesn't mount /var with the "nolocks"
> option (I can of course change fstab manually before booting
> the new system, but dbootstrap should really take care about that).
> The problem then is that locking fails on /var and, consequently, apt and
> dselect fail when the new system is booted the first time to complete
> the installation.
>
> NFS mounted partitions served by the Linux user space NFS server can't
> use real NFS locks at all, so dbootstrap should include the "nolocks"
> option into fstab. NFS mounted partitions served by the Kernel NFS server
> or other Unices can use NFS locking, but AFAIK only if nfs-common (namely
> rpc.statd) goes into base; this isn't the case at the moment.
>
> A possible solution would be:
> dbootstrap just puts nolocks in fstab for every NFS mount.
This seems feasible. Are there any foul implications of doing this?
I.e., does it really apply to all architectures? What about NFS root
situations?
It seems like a bit of a drastic change and that worries me.
> A better solution would be: nfs-common goes into base and on the
> boot-floppies (it's really small). When the user tries to mount a
> NFS share, dbootstrap creates a temporary file on the share and
> tries to (NFS) lock it. If this succeds, we have a server that
> supports NFS locking and don't use "nolocks" in fstab. Otherwise,
> we put "nolocks" in fstab.
It doesn't seem feasible to accomplish this at this time.
> Warning: the combination rpc.statd running and /var NFS mounted
> without "nolocks" but from a server that doesn't support the locking
> protocols (like the user space server) bombed my console with so many
> error messages I couldn't even use a text editor and also broke the
> shutdown scripts.
Oy.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: