At 10.32 02/04/2003 -0500, you wrote:
On Wed, Apr 02, 2003 at 04:43:26PM +0200, Daniele Palumbo wrote:
> At 13.57 01/04/2003 -0500, you wrote:
> >On Tue, Apr 01, 2003 at 08:17:10PM +0900, Stephen J. Turnbull wrote:
> >> Er ... has libdb disappeared from the most recent Coda CVS? I can't
> >> log i
On Fri, Oct 18, 2002 at 03:34:41PM +0200, Steffen Neumann wrote:
> I couldn't find this one, but I have one strange thing.
> It is not so important since that user is gone,
> but read on why I wouldn't like to erase that volume
> without prior asking what goes on:
>
> Normally every user has a v
Jan Harkes <[EMAIL PROTECTED]> writes:
> Sigh, third time I'm typing this reply, I keep losing my dialup
> connection this morning..
I edit my mail locally and then I tend to forget sending it ...
> You should be able to do 'inoder /vice/db/vicetab /vicepa header
Yup, that did it.
No important f
Sigh, third time I'm typing this reply, I keep losing my dialup
connection this morning..
On Thu, Oct 17, 2002 at 03:34:15PM +0200, Steffen Neumann wrote:
> The old filesystem had errors on a number of files:
>
>./1/5b/18: Input/output error
>./1/5b/19: Input/output error
>
Hi,
It has happened, out hard drive hosting the coda data
had tiny smoke coming from it ...
We were able to recover most of the /vicep[abc] partitions to a new
hard drive, as well as the rvm partition. Some files on /vicepa
had read errors and thus are missing on the new partition.
Main point
Hello Stefan,
> Assertion failed: vol->IsReplicated(), file "fso1.cc", line 1884
as a workaround "cfs strong" takes away the optimizations and you never
hit that problem unless the server times out. It is a bad style of Coda
usage :-) but in mission-critical cases it helps.
Regards,
--
Ivan
On Tue, May 14, 2002 at 02:06:28PM +0200, Steffen Neumann wrote:
> Here is another traceback of a venus crash,
> no data was lost, for debugging purpose only.
>
> The user did (afaik) not do any serious writes,
> but used software installed on /coda
This is that annoying startu
Hi there,
Here is another traceback of a venus crash,
no data was lost, for debugging purpose only.
The user did (afaik) not do any serious writes,
but used software installed on /coda
Yours,
Steffen
Hi,
the last two days we had venus crashing
shortly after any access. Some diagnosis is attached.
It only worked after venus -init, all volumes
were connected so no data was lost.
Yours,
Steffen
=
console.log:
-
Jeremy Malcolm wrote:
>
> OK thanks Jan, I think *maybe* we are making some progress now,
Update: I lied. After restarting venus again it has resumed reliably
crashing on both servers with the killing parent message and "Failure of
coda_cnode_make for root: error -6". Back to square one.
--
OK thanks Jan, I think *maybe* we are making some progress now, so I'm
reporting back to the list although it's still not quite fixed.
What I changed from last time is that now I am editing the
/vice/db/servers and /vice/db/VSGDB files on the first server servalan
BEFORE creating setting up the s
I am not entirely sure what is causing this, but venus is crashing on me with:
20:54:01 fatal error -- namectxt::CheckExpansion: bogus return from vproc::namev
(158)
20:54:01 RecovTerminate: clean shutdown
Assertion failed: 0, file "hdb.cc", line 2130
158 is the return code for EVOLUME as far as
I've taken some time to look at this trace.
Thanks a lot for taking the time.
> The server crash is not triggered by 'cfs cs', but the reintegration
> that starts when the servers are found to be up. The crash happens at
> the end of the reintegration phase, strangely enoug
t;
> It has probably crashed during the backfetch. I'm wondering whether it
> crashed during the SFTP transfer.
I don't know: First of all, what is SFTP?
> > With the old version everything was just fine. I actually got the first
> > crash after I updated the client and b
ng the SFTP transfer.
> With the old version everything was just fine. I actually got the first
> crash after I updated the client and before I updated the server but I
A client should not be able to crash the server that easily.
> hoped that updating the server would fix the problem and
ot;
Volume type is Replicated
Connection State is Disconnected
Write-back is disabled
There are 2 CML entries pending for reintegration
With the old version everything was just fine. I actually got the first
crash after I updated the client and before I updated the server but I
hoped that updating
s in
fact corrupted.
You can try to force the changes in the rvm log using the rvmutl
program, although that might just as well crash in the same spot. I'm at
home so I can't give you the exact commands to pass to rvmutl, but it is
something like "open ", "status", and th
I just had a file server go down fairly hard (power loss). When I try and
restart Coda, the server process aborts. /vice/srv/SrvLog has
Setting Rvm Truncate Threshold to 5.
as the last message, and SrvErr has
codasrv: rvm_logrecovr.c:2001: build_tree: Assertion `(long)log_buf->ptr
>= 0' faile
I had a kernel crash twice on me when trying to save an excel-format
file with gnumeric. I suspect gnumeric is trying to mmap a file which
is in coda, and this just doesn't work, but I don't really know either
of these things. (I am able to use gnumeric to read excel files and
save i
On trying to du a moderately large hierarchy of files (vice and venus
on some machine), I got
venus: rvm_logflush.c:92: make_pad_buf: Assertion `(length >= 0) && (length < 512)'
failed.
14:07:16 Fatal Signal (6); pid 20655 becoming a zombie...
14:07:16 You may use gdb to attach to 20655
Unfortu
> On 30 Jun 1999 16:22:17 -0400, "Robert V. Baron" <[EMAIL PROTECTED]> said:
> Doing a
> venus -init
> the first time you run 5.2.7 will fix this.
Thanks a lot Robert, this really fixed it.
--
andreas
Doing a
venus -init
the first time you run 5.2.7 will fix this.
[EMAIL PROTECTED] (Andreas J. Koenig) writes:
> After an upgrade of both server and client on my coda server machine
> from 5.2.4 to 5.2.7 venus doesn't come to life with these logmessages
> and stacktrace:
>
> 12:21:11 /us
After an upgrade of both server and client on my coda server machine
from 5.2.4 to 5.2.7 venus doesn't come to life with these logmessages
and stacktrace:
12:21:11 /usr/coda/LOG validated at size 0x500e00
12:21:11 /usr/coda/DATA validated at size 0x14023f8
12:21:12 loading recoverable store
12:21
> * More tokens
> Is it possible to have different coda tokens in separate
> shells/windows? It looks like it's the process uid that determines
> what coda token you ``have''. Is there a way around this or do I have
> to su to another user and clog admin to avoid loosing my ordinary
> token?
Yo
Greg Troxel <[EMAIL PROTECTED]> writes:
Will the laptop have different IP addresses at various places? Or
are you running some sort of mobile IP with route optimization? If
not, I suspect you'll have to do some work to have the server handle
multiple IP addresses (and changes) gra
One other thing that you may want to consider:
Will the laptop have different IP addresses at various places? Or
are you running some sort of mobile IP with route optimization? If
not, I suspect you'll have to do some work to have the server handle
multiple IP addresses (and changes) graceful
Hi,
I'm currently working at two different locations with a too poor
connection between to be able to have all my data at one of the places
to work effectively from both offices. I've just set up a machine
running venus and another running vice on FreeBSD 2.8 and 3.0
respectively to find out if C
[EMAIL PROTECTED] said:
| I started a bunch of rm -rf's on a tree under /coda, and this
| happened.
|
| The venus.log is available as http://www.cuc.ml.org/~sopwith/
| venus.log.gz (100K compressed).
|
| Hope this helps, -- Elliot
I couldn't access the logfile, but the backtrace together with the
I started a bunch of rm -rf's on a tree under /coda, and this happened.
The venus.log is available as http://www.cuc.ml.org/~sopwith/venus.log.gz
(100K compressed).
Hope this helps,
-- Elliot
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foun
29 matches
Mail list logo
