On Tue, Jul 20, 1999 at 06:28:29PM -0400, Jan Harkes wrote:
> 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.
>
I don't think that it it exactly. I rebooted and didn't starup venus. Then
I tried a venus -init and it got killed the same way.
The module doesn't seem to have any problem loading.
[ben@wythe ben]$ cat /proc/modules
nfsd 150240 8 (autoclean)
opl3 11208 0
sb 33428 0
uart401 5968 0 [sb]
sound 57324 0 [opl3 sb uart401]
soundcore 2340 6 [sb sound]
[ben@wythe ben]$ sudo /sbin/modprobe coda
[ben@wythe ben]$ cat /proc/modules
coda 51376 0 (unused)
nfsd 150240 8 (autoclean)
opl3 11208 0
sb 33428 0
uart401 5968 0 [sb]
sound 57324 0 [opl3 sb uart401]
soundcore 2340 6 [sb sound]
[ben@wythe ben]$ sudo /usr/sbin/venus
venus venus-setup
[ben@wythe ben]$ sudo /usr/sbin/venus -init
Date: Tue 07/20/99
16:49:46 /usr/coda/LOG setup for size 0x10ce02
16:49:46 /usr/coda/DATA initialized at size 0x433808
16:49:46 brain-wiping recoverable store
16:49:47 loading recoverable store
16:49:47 starting VSGDB scan
16:49:47 0 vsg entries in table
16:49:47 0 vsg entries on free-list
16:49:47 starting VDB scan
16:49:47 1 vol entries in table (0 MLEs)
16:49:47 0 vol entries on free-list (0 MLEs)
16:49:47 starting FSDB scan (1706, 40960) (25, 75, 4)
16:49:47 0 cache files in table (0 blocks)
16:49:47 1706 cache files on free-list
16:49:48 starting HDB scan
16:49:48 0 hdb entries in table
16:49:48 0 hdb entries on free-list
16:49:48 Initial LRDB allocation
16:49:48 Getting Root Volume information...
16:49:48 Venus starting...
Killed
> > 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.
>
What do you want me to check? /vice/db/ROOTVOLUME is simply "rootvol1"
which is what I expect it to be.
/vice/vol/VolumeList is:
P/vicepa Hwythe.su.varesearch.com T3cc674 F3cb4dc
and /vice/vol/AllVolumes is:
rootvol1.0 1 wythe.su.varesearch.com /vicepa 2 0 0 W 928509191 928509191 0
Are those the right files to look at? Do they look sane?
-ben
Hmm that sounds a bit more like it. How could I have done that. I don't
remember creating any volumes since I first installed the coda server. Never
mind that doesn't matter.
How can I get everything setup properly again? What files do I need to modify.
Should I do a vice-setup? I would really prefer not to loose the data that
lives in my coda volume?
> Jan
