On Tue, Jul 20, 1999 at 03:20:59PM -0700, Ben Woodard wrote:
> I did a cfs checkservers and then venus discovered that it had a
> server to talk to and promptly died. This wasn't you normal "venus
> recieved such and such signal and now will hang around for someone to
> come along with gdb" sort of crash this is a "I'm gone crash". I tried
> brain wiping the venus but it didn't work.
> 
> I tried doing another venus setup and that didn't work. It was like
> poof gone. The startup looks something like this:
<snip>
> 08:03:20 Venus starting...
> Killed

/coda couldn't be mounted, and the child process killed its parent. This
happens AFTER the rootvolume information is fetched from the server.
That's why you see the connection. Check if the coda module is loaded,
and if it has a refcount. If so, kill any hanging 'venii', and unmount
/coda. If that doesn't clear the refcount you need to reboot.

If the module is not loaded, try 'modprobe coda', to see whether the
module is correctly compiled/installed.

> 07:57:06 GetVolObj: VGetVolume(1) error 103
> 07:57:06 ViceAllocFids: GetVolObj error Volume not online
>
> My guess is that something is still a bit screwed up in the codasrv
> and the volume is not attached but I am not sure what that means. I
> also think that there is a bug in venus that is causing it to crash
> and burn when there are no volumes attached.

Btw. venus seems to try to get access to a volume that doesn't exists.

Did you create the rootvolume (with the same name as in /vice/db/ROOTVOLUME).
It could be that when venus cannot get the rootvolume information, it
passed some bad info to the child that attempts to mount /coda.

Jan