[OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs
Derrick Brashear
shadow@gmail.com
Fri, 5 Oct 2007 09:27:58 -0400
------=_Part_13782_25848326.1191590878428
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 10/5/07, Christopher D. Clausen <cclausen@acm.org> wrote:
>
> Kim Kimball <dhk@ccre.com> wrote:
> > You might also try
> > vos remove <server> <partition> <volumename>.readonly #for each
> > readonly instance
> > vos backup <volumename>
> > vos dump <volumename>.backup | vos restore <server> <partition>
> > <volumename> -overwrite full
> >
> > Use the same volume name for each instance of <volumename>
> >
> > This will give you a new volumeID for <volumename> which will be
> > reflected in the VLDB. Then "vos addsite" to replace the RO sites.
> > Then "vos release"
>
> I was going to suggest that, but I figured it may not actually clear up
> the problem and could potentially just waste a lot of time.
>
> How does one know that the 127.* IPs really are gone?
vos listvl?
-----
>
> When specifing server names, DO NOT use "localhost" or "127.0.0.1." Use
> the FQDNs of your servers.
>
> -----
>
> Hmm... would vos delent for each volume, then the vos
> changeaddr -remove, and then a vos syncvldb do the same thing and not
> take as much time for the dump / restores?
even if changeaddr -remove fails, you can changeaddr to a bogus address,
listvl and delent for the bogus address, then syncvldb. at worst you have an
orphan address in the vldb that no one is going to care about.
------=_Part_13782_25848326.1191590878428
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 10/5/07, <b class="gmail_sendername">Christopher D. Clausen</b> <<a href="mailto:cclausen@acm.org">cclausen@acm.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Kim Kimball <<a href="mailto:dhk@ccre.com">dhk@ccre.com</a>> wrote:<br>> You might also try<br>> vos remove <server> <partition> <volumename>.readonly #for each<br>> readonly instance<br>
> vos backup <volumename><br>> vos dump <volumename>.backup | vos restore <server> <partition><br>> <volumename> -overwrite full<br>><br>> Use the same volume name for each instance of <volumename>
<br>><br>> This will give you a new volumeID for <volumename> which will be<br>> reflected in the VLDB. Then "vos addsite" to replace the RO sites.<br>> Then "vos release"<br><br>I was going to suggest that, but I figured it may not actually clear up
<br>the problem and could potentially just waste a lot of time.<br><br>How does one know that the 127.* IPs really are gone?</blockquote><div><br>vos listvl?<br> <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----<br><br>When specifing server names, DO NOT use "localhost" or "<a href="http://127.0.0.1">127.0.0.1</a>." Use<br>the FQDNs of your servers.<br><br>-----<br><br>Hmm... would vos delent for each volume, then the vos
<br>changeaddr -remove, and then a vos syncvldb do the same thing and not<br>take as much time for the dump / restores?</blockquote><div><br>even if changeaddr -remove fails, you can changeaddr to a bogus address, listvl and delent for the bogus address, then syncvldb. at worst you have an orphan address in the vldb that no one is going to care about.
<br><br><br></div><br></div><br>
------=_Part_13782_25848326.1191590878428--