On Thu, Mar 16, 2000 at 05:06:32PM -0000, fsg.student4_at_bt.com wrote:
> There's one strange message in SrvLog-sf3 (that's the SCM):
> 
> 16:28:54 SFS: There are some volumes without any inodes in them
> 16:28:54 SalvageFileSys:  unclaimed volume header file or no Inodes 
>          in volume 2000001
> 16:28:54 SalvageFileSys: Therefore only resetting inUse flag
> 16:28:54 SalvageFileSys completed on /vicepa

This is probably because the volume is still empty (btw this is not on
the SCM ;)

> > and consequently is the VRList on the SCM good?
> 
> Seems good to me:
> coda:root 7F000000 1 3000001 0 0 0 0 0 0 0 E0000100
> coda:repl 7F000001 2 3000002 2000001 0 0 0 0 0 0 E0000104

Looks perfect. Run 'volutil makevrdb /vice/vol/VRList' on the SCM and
check the date of /vice/db/VRDB to see if it got updated.

Also check if the server logs show `New Databases arrived' or something.
The updateclnt/srv should detect the new VRDB and inform the server to
read it.

The problem is that 7F000000 is a replicated volume-id which should be
translated into the replica volume-id '3000001' as the VGetVolume rpc2
call enters the server. This is done using the information in the VRDB,
and therefore that file is suspect.

At least venus is talking to the right server. Maybe it has a problem
with all the 0's in 7F000000. You could try to change the
/vice/db/ROOTVOLUME file to contain 'coda:repl'. Then reinitialize the
client ('venus -init') and it should try to mount the replicated volume
7F000001 as rootvolume.

Jan