> From: "Kathryn L. Madison" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Thu, 27 Jan 1994 13:34:54 -0500
> Subject: problems with AFS 3.2 server
>
> We upgraded to AFS 3.2 on 10 of our server machines; most came up
> without any problem (well, not any problems that are relevant here),
> but one now says:
>
> afsd: Can't mount AFS on /afs(2)
>
> it then starts up the afs server and serves files (altho i have since
> taken it out of production). Yes, we tried deleting /afs and recreating
> it -- it is owned by root, group is system, permissions are drwxr-xr-x
> any ideas?
>
> thanks
> ka
"Can't mount AFS on %s(%d)" -- the stuff in ()'s is an errno.
2 means "ENOENT", so trying to recreate /afs certainly made
sense. "afsd" has a -verbose option that might be slightly
helpful here, but probably it will just complain after it
says:
%s: Mounting the AFS root on '%s', flags: %d.
AFS vfs slot number is %d
which won't tell you much more.
It looks like the mount process can return ENOENT if something
about accessing the root volume fails. Some things to try include:
(1) delete all the files in the cache on the workstation,
(2) make sure there's enough free disk space for the
cache on the workstation
(3) restart it.
If that doesn't succeed, then the next thing might to be to
start suspecting something weird in AFS. Perhaps the volume
is somehow damaged (if it's replicated, perhaps other copies
aren't affected.) The "-rootvol" parameter of afsd can be used
to select another volume to mount; that might change things.
It would also make sense to review any other considerations.
If the network configuration got damaged, perhaps it
doesn't know where the local router is, or some other weirdness.
Tools such as "rxdebug", "cmdebug" and "xstat_cm_test" might
also give you more information on what's happening, "rxdebug"
can be used to tell what servers the machine is talking to.
"cmdebug" can be used to remotely examine the cache.
"xstat_cm_test" returns a vector of call counts, which might be
useful in telling where the kernel part is hanging. If the long list
of calls in <afs/afs_stats.h> doesn't make sense, then
"xstat_cm_test" is probably not for you, and it might make the
most sense to just reload the machine from backups.
This all applies to the *CLIENT* side of of AFS. You say
"server"-- it would not make sense to see this message on
an AFS file server unless you were mounting /afs on it,
which would be a rather odd configuraton for a production
AFS file server. If the message did appear on the server,
it would certainly make sense that it would not affect its
operation as an AFS file server. If it tries to start up the
cache manager before it starts serving files, & it's trying to
mount root.afs off of itself, it would certainly make sense
that the mount operation would fail. In that case,
consider just not running afsd at all.
-Marcus Watts
UM ITD RS Umich Systems Group
