(Illustration by Gaich Muramatsu)
I've just started getting the following error from a Linux box running Coda 4.6.6; when I upgraded to Linux kernel 2.1.130, I started getting the following message in /usr/coda/etc/console whenever I restarted venus (though not on the initial startup, oddly enough!): 13:25:28 /usr/coda/LOG validated at size 0x8dc00 13:25:28 /usr/coda/DATA validated at size 0x235e70 13:25:28 fatal error -- Recov_InitRVM: RVM_INIT failed, internal error Current time before last recorded - check kernel date 13:25:28 Fatal Signal (11); pid 308 becoming a zombie... 13:25:28 You may use gdb to attach to 308 and ls /coda shows the feared NOT_REALLY_CODA. I attached a gdb to process 308 and did a backtrace, but it couldn't resolve any of the symbols. (I've got the coda-debug-client package installed, so I'm a little confused! Shouldn't I have gotten a nice backtrace?) Returning the box to the last working version of the kernel, 2.1.127, does not fix the problem, oddly enough. Upon a reboot, I can explore most of /coda (cache maybe?) but a cfs la /coda/somedir gives a Connection timed out error and in /var/log/kern.log I get: Nov 30 13:19:50 beowulf kernel: coda_pioctl: Venus returns: -107 for (0x7f000002 ,0x1,0x1) and Nov 30 13:20:01 beowulf kernel: coda_pioctl: Venus returns: -110 for (0x7f000002 ,0x13,0xa) What's really bizarre is that a venus client running on a separate box that is not the main Coda server has no problems whatsoever. I'm guessing this might just be my impatience showing, and I just need to wait for venus to initialize upon the initial reboot. However, one would think that killing the venus process and umounting /coda and restarting venus would not give an error like internal error Current time before last recorded - check kernel date. :) Anyone know why this might happen? Ben -- Brought to you by the letters Y and P and the number 2. "Make a little birdhouse in your soul." -- They Might Be Giants Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.Received on 1998-11-30 16:49:57