of Kiss Coda Wiki
updatesrv won’t start and /vice/srv/UpdateSrvLog says cannot bind to rpc2portmap.
Most likely your /etc/hosts file is not properly setup to refer localhost lookups to the loopback interface. Make sure you have a line like this:
127.0.0.1 localhost localhost.localdomain
See this thread for details: http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2005/7318.html
Contrary to the ancient documentation, you may fsck a coda partition if that partition is anything other than a “raw” partition, such as ext2 or ext3.
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.
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.
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)
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.
If running the repair command results in this:
# repair repair > beginrepair filename Too few directory entries Could not allocate replica list beginrepair failed.
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
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
There has been a conflict. See the Dealing with conflicts page.
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.
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.
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.
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)
You’ve forgotten to make a root volume: Quick_Server_Action
At its former host wikidev.net this page has been accessed 9090 times.
Last modified: Thu Jun 26 07:37:01 UTC 2014