From: Iain Barker (ibarker@aastra.com)
Date: Fri Nov 21 2003 - 10:24:10 EST
The problem was strictly an automount issue, manually mounting a filesystem
worked fine, but through the automounter the system would hang because the
NFS mounts were timing out.
Checking the automount daemon logs showed that the file containing the
NIS-wide direct map table shared between Sun, Alpha etc. hosts wasn't being
loaded properly by 5.1b
All our maps use the syntax "auto.xxx", but the automounter was looking for
"auto_xxx". Strange that the auto.xxx format worked OK for Tru64 5.1a but
failed on 5.1b...
Adding an /etc/auto_master file locally to tell the system to use the
"auto.xxx" maps, and restarting the automount daemon has everything seems to
be working now.
-----Original Message-----
From: Iain Barker
Sent: Thursday, 20 November, 2003 18:04
To: tru64-unix-managers@ornl.gov
Subject: Changing automount NFS default from v2 to v3 for Tru64 5.1b
upgrade ?
Hi managers,
I'm trying to do an upgrade-install of a system from Tru64 5.1a to 5.1b and
in the process I had to remove a couple of layered products that blocked the
upgrade.
Now I find that 5.1b is running OK, but all the NFS filesystems are
automounting using V2 not V3.
This is causing hangs with "NFS2 server <hostname> not responding still
trying" for any connections across to the Suns (hosting user home
directories etc) in our network.
My guess is that one of the removed products replaced some NFS config file
with a default version, and that got picked up by the upgrade script and
used for the 5.1b install.
Where is the default value for v2 versus v3 configuration set? This could
be specific to automount, or to NFS I guess - neither of which I have much
experience with I'm afraid.
I could start over with a new install, but I'm sure this is just a config
option I missed someplace.
thanks!
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:44 EDT