See bug #479884 for previous discussion of this problem.
The locking problem with 2.6.19 kernels and later is not really a
problem. Locking is still used for the real NFS mounts, it's only the
am-utils NFS intercept which doesn't use locking. In earlier Linux
kernels, the failure to parse the am-utils nasty hostname was ignored,
and the lock manager just didn't do any locking for the am-utils
intercept point (which isn't a problem because the am-utils intercept
does not contain any actual files, and the only thing writing to it is
amd itself, and so locking is not required there).
In the more recent kernels which report the error about locking, and
cause am-utils to fail, this is fixed by patching am-utils to
explicitly request nolock in the am-utils intercept points, which
restores the previous behaviour. This patch was part of the 6.1.5-10
release, which is why I am somewhat surprised that you reported it
again, because 6.1.5-10 is working fine for me with recent kernels.
Can you give me exact instructions to reproduce what you are now
seeing? Otherwise I'm going to merge this bug with #479884, because
as far as I know, it's already been fixed (at least as a quick fix, if
not a permanent one, which would probably involve a lot more work in
modifying the am-utils code for what it calls the mount point)
Tim
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
