Just to entertain you a bit, I found out that often (but not always), one
can manually mount the required nfs volumes and everything works again.
$ cd archive
bash: cd: archive: No such file or directory
$ ls -ld archive
lrwxrwxrwx 1 root root 32 May 8 10:19 archive ->
/fs/doom/var/lib/mythtv/archive/
(== the usual case, although with kernel 2.6.16.9).
$ mount doom:/ /fs/doom
$ mount doom:/localvol4 /fs/doom_localvol4
$ cd archive
$ # worked
So just *maybe*, what hapeons is that automount tries to mount the volume
and fails for whatever reason (it would be interesting to know it, maybe
I can find out), and then leaves the mountpoint in an unusable state till
reboot.
I think one could investigate this path, to see what happens if mounting
the volume fails in autmount. Likely it doesn't have a clean path to back
out if this happens (it might return an error in this access, but *must*
retry eventually, otherwise intermittent errors would require reboots of
clients).
Just a theory, of course. I'll try to find out what causes the mount
failure, although this will not be easy.
Peculiar are these messages:
Jun 25 12:08:02 cerebro automount[1309]: attempting to mount entry
/fs/doom/var
Jun 25 12:08:02 cerebro automount[3452]: failed to mount /fs/doom/var
Jun 25 12:08:02 cerebro automount[3452]: umount_multi: no mounts found under
/fs/doom/var
Jun 25 12:08:10 cerebro automount[1309]: attempting to mount entry
/fs/doom/root
Jun 25 12:08:10 cerebro automount[3460]: failed to mount /fs/doom/root
Jun 25 12:08:10 cerebro automount[3460]: umount_multi: no mounts found under
/fs/doom/root
As the mountpoints mentioned do not exist (/fs/doom is a mountpoint, but
not /fs/doom/something).
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
