Common error messages
From Codawiki
| Table of contents |
|
|
Server
Command-line errors
Cannot mount /vicepa partition
Contrary to the old documentation, you may fsck a coda partition if that partition is anything other than a "raw" partition, such as ext2 or ext3.
Log Messages
SFS:No Inode summary for volume 0x1000009; skipping full salvage
SalvageFileSys: Therefore only resetting inUse flag
Says Jan in this message http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2002/4538.html:
This should be normal for any volume without files, we have a bunch of these when servers are started.
Client
Initialization errors
LogInit/RVM alloc failed
This is likely if the directories /usr/coda/etc or /usr/local/coda/etc do not exist. If these are created, then the likely problem is that the incorrect user has permissions to create log files within them. In cygwin, the Windows user SYSTEM runs all services and requires r/w permissions on all log files. In linux, this user would be root. The following commands fix the problem in cygwin:
[user@host ~]$ chmod -R 664 /usr/coda [user@host ~]$ chown -R SYSTEM /usr/coda
In Windows, changing the "venus" service to start automatically and rebooting Windows will correctly load Venus.
Behavior errors
find command doesn't traverse volumes
If you are in your root realm directory and the only subdirectories are volumes and you run find . the find command will not traverse down into the subdirectories. To get find to drill down into volumes, use the -noleaf option, like this:
find . -noleaf
The noleaf workaround is no longer necessary as of Coda-6.0.9. It disabled an optimization in find, where it takes the directory linkcount, subtracts 2 ('.' and '..' entries) and then subtracts one for each subdirectory it encounters. Once the counter hit zero it assumes everything else will be a file and as such doesn't call stat(2) on the remaining directory entries. This optimization was broken for Coda as our volume mountpoints are represented by 'magic' symlinks and do not add to the directory linkcount. However for applications they are still visible as a subdirectory. We now return a linkcount of 1 for directories, find then subtracts 2 and ends up at -1. This way it will not hit zero and will end up calling stat(2) on every directory entry. --Jan Harkes 17:26, 9 Jun 2005 (CEST)
Conflict Repair Errors
You still need a dorepair because the Version state is different
VIOC_REPAIR /coda/realm/conflict/path: Resource temporarily unavailable
Repair failed.
This may be due to a version mismatch between the server and the cached replica objects. Try flushing the cached replica objects by following these steps:
cfs br /coda/realm/conflict/path # expand the conflict cfs getfid /coda/realm/conflict/path/* # show version vectors cfs fl /coda/realm/conflict/path/* # flush cached replicas cfs getfid /coda/realm/conflict/path/* # refetch and show vvs cfs er /coda/realm/conflict/path # collapse the conflict
If the version vectors changed, then you should try the repair process again.
Too few directory entries; Could not allocate replica list; beginrepair failed
If running the repair command results in this:
# repair repair > beginrepair filename Too few directory entries Could not allocate replica list beginrepair failed.
And running
cfs beginrepair filename
results in a global file that is a broken link, you probably have "a combination of a server-server (resolution) conflict and a local-global (reintegration) conflict."
Jan Harkes explained the problem and the solution to the mailing list (http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2005/7825.html):
cfs purgeml should get rid of the local-global (reintegration) conflict. At this point you would only have the server-server conflict left, if this is a file it can be completely removed with removeinc passwd_manage or repaired with, cfs beginrepair passwd_manage cp passwd_manage/some_replica /tmp/passwd_manage.recovered cfs endrepair passwd_manage filerepair passwd_manage /tmp/passwd_manage.recovered
Command-line errors
My data disappeared and now there's a broken symlink
There has been a conflict. See the Dealing with conflicts page.
ls: permission denied
This can be caused by a lot of things. Check ctokens to see if you are authenticated, then check cfs la . to see if the user you're logged in as has rights to read the current directory (or whatever directory you can't read). If the cfs la command returns, Connection timed out, then it is likely that you or that volume are disconnected due to a network problem or a conflict. Type
cfs lv /path/to/directory
and look at the results. It will tell you if you are write-disconnected and if there are conflicts.
Log Messages
CacheFile::ValidContainer: 00/00/00/2B invalid
Found in venus.log.
From an e-mail to the coda mailing list by Jan Harkes: This was probably an open-for-write file, during recovery the size doesn't match the recorded size in RVM. We only get to see the new size when the file is closed.
Local inconsistent object at ???/blah/blah, please check
Found in the console log file. This means that prior to mounting a volume was found to have a conflict and is not being mounted. The ??? indicates that the mount point is not yet known for this volume.
worker::main got bogus opcode 35
Harmless error message, it will be either opcode 35 or opcode 36. The kernel simply checks if the Coda client is capable of handling the CODA_STORE/CODA_RELEASE upcalls. If the client returns an error the kernel will fall back to CODA_CLOSE. The only problem is that at the time CODA_CLOSE is sent, we can no longer propagate errors back to the application. However most applications don't even check for errors on close(2), so this is really not such a big problem.
Venus already takes the safe route and assumes nobody bothers to check for close(2) errors. When we fail while writing data back to the servers it will switch the volume to write-disconnected (or even disconnected) mode and commit the store operation locally in the modification log. When the following reintegration fails we mark the object as a conflict. --Jan Harkes 17:34, 9 Jun 2005 (CEST)
VLDBLookup: No or bad vldb.
You've forgotten to make a root volume: Quick_Server_Action#Run_Coda_Server
