[OpenAFS] orphaned root.afs problem during 1.3.80 client upgrade

[Hans-Gunther Borrmann]

On Wednesday 30 March 2005 19:44, ted creedon wrote:
> Yes, root.cell.readonly did disappear on both machines.
> Looks like it happened when a vos release on doris_disk.vol id 536870944
> was done from hiawatha . Seems to have created bogus.536870944  id
> 536870944 on nanook. The byte count on 536870944 was different on both
> machines at the time...
>
> What's the best way to repair? fs mkmounts on both machines?
>

bos salvage nanook. Then look at the salvage log. The description of the 
handling of readonly volumes is described in the following:

The bos salvage command salvages (restores internal consistency to) one or 
more volumes on the file server machine named by the -server argument. When 
processing one or more partitions, the command restores consistency to 
corrupted read/write volumes where possible. For read-only or backup volumes, 
it inspects only the volume header: 


If the volume header is corrupted, the Salvager removes the volume completely 
and records the removal in its log file, /usr/afs/logs/SalvageLog. Issue the 
vos release or vos backup command to create the read-only or backup volume 
again. 

If the volume header is intact, the Salvager skips the volume (does not check 
for corruption in the contents). However, if the File Server notices 
corruption as it initializes, it sometimes refuses to attach the volume or 
bring it online. In this case, it is simplest to remove the volume by issuing 
the vos remove or vos zap command. Then issue the vos release or vos backup 
command to create it again. 

Gunther

-- 
________________________________________________________________
Hans-Gunther Borrmann <hans-gunther.borrmann@rz.uni-freiburg.de>
Rechenzentrum der Universitaet Freiburg
Hermann-Herder-Str. 10, D79104 FREIBURG
Tel.: +49 761/203-4652
Fax:  +49 761/203-4643