[OpenAFS] AFS fsck problems - strange

Derrick Brashear shadow@gmail.com
Tue, 24 Jun 2008 00:54:12 -0400


------=_Part_20818_12390541.1214283252713
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Jun 23, 2008 at 10:23 PM, Jeff Blaine <jblaine@kickflop.net> wrote:

> We recently re-imaged a fileserver (Solaris 9).  For
> every slice of our old /vicep data, we are getting
> the following error at boot time.  Here's one example:
>
>  # /usr/lib/fs/afs/fsck -o b=512272 /dev/dsk/c3t6006016012341600D86B14C
>> 7E294DA11d0s0
>>
>> ----Open AFS (R) openafs 1.4.6 fsck----
>
>
A change (fix) to parsing of alternate superblock arguments to fsck is in
1.4.7.


>> Alternate super block location: 0
>> ** /dev/dsk/c3t6006016012341600D86B14C7E294DA11d0s0
>> BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
>> ALTERNATE USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION;
>> eg. fsck [-F ufs] -o b=# [special ...]
>> where # is the alternate super block. SEE fsck_ufs(1M).
>>
>
> No matter what superblock alternate is specified... same error.
>
> The /usr/afs portion was selectively copied from another
> fileserver of the same architecture after the host in question
> was reimaged (no sysid, no logs, no fssync.sock, no salvage.lock).
>
> The fun part is, the partitions get mounted just fine and
> everything is peachy.  Lucky for us.
>
>

------=_Part_20818_12390541.1214283252713
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">On Mon, Jun 23, 2008 at 10:23 PM, Jeff Blaine &lt;<a href="mailto:jblaine@kickflop.net">jblaine@kickflop.net</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We recently re-imaged a fileserver (Solaris 9). &nbsp;For<br>
every slice of our old /vicep data, we are getting<br>
the following error at boot time. &nbsp;Here&#39;s one example:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
# /usr/lib/fs/afs/fsck -o b=512272 /dev/dsk/c3t6006016012341600D86B14C<br>
7E294DA11d0s0<br>
<br>
----Open AFS (R) openafs 1.4.6 fsck----</blockquote></blockquote><div><br>A change (fix) to parsing of alternate superblock arguments to fsck is in <a href="http://1.4.7.">1.4.7.</a> <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Alternate super block location: 0<br>
** /dev/dsk/c3t6006016012341600D86B14C7E294DA11d0s0<br>
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION;<br>
eg. fsck [-F ufs] -o b=# [special ...]<br>
where # is the alternate super block. SEE fsck_ufs(1M).<br>
</blockquote>
<br>
No matter what superblock alternate is specified... same error.<br>
<br>
The /usr/afs portion was selectively copied from another<br>
fileserver of the same architecture after the host in question<br>
was reimaged (no sysid, no logs, no fssync.sock, no salvage.lock).<br>
<br>
The fun part is, the partitions get mounted just fine and<br>
everything is peachy. &nbsp;Lucky for us.<br>
<br></blockquote></div><br>

------=_Part_20818_12390541.1214283252713--