"Cannot find file system superblock" error - how to recover?

[Malcolm Kay]

On Tue, 6 Jan 2004 15:05, Sergey 'DoubleF' Zaharchenko wrote:
> On Tue, 6 Jan 2004 13:29:26 +1030
>
> Malcolm Kay <malcolm.kay at internode.on.net> probably wrote:
> > On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote:
> > > Sorry for the delay... holidays had me busy.
>
> Me too:)
>
> > > Hopefully you're still around
> > > and interested in picking up where we left off. I think we're
> > > definitely onto something...
> >
> > Looking back over some of your e-mails I find:
> > QUOTE
> > su-2.05b# disklabel -r /dev/ad6s1c
> > # /dev/ad6s1c:
> > 8 partitions:
> > #        size   offset    fstype   [fsize bsize bps/cpg]
> >   c: 156344517       63    unused        0     0         # "raw" part,
> > don't edit
> >   e: 156344517       63    4.2BSD     2048 16384    89
> > partition c: partition extends past end of unit
> > disklabel: partition c doesn't start at 0!
> > disklabel: An incorrect partition c may cause problems for standard
> > system utilities
> > partition e: partition extends past end of unit
> >
> > That doesn't look good.
> > ENDQUOTE
> >
> > The 63 offset is spurious. I've seen this before somewhere but can't
> > remember the details -- i.e the value 63.
>
> I know where you've seen this. The normal offset for the first *slice*
> is 63 sectors, for some historical reasons (those extra sectors were to
> be used for bad block replacement or something like that).
>

Yes, I expect it in the output from fdisk.
Ignoring for the moment that the BIOS ideas of geometry has nothing 
to do with the physical reality; all slices start at sector 1 of a track so having
used sector 1 of the first track (cylinder 0 head 0) for the MBR, the first slice
must start at cylinder 0 head 1 sector 1; usually an offset of 63 with the assumed
virtual geometry.
(Nothing to do with bad block replacement which on modern drives is almost 
completely hidden)

But I have seen the 63 before in corrupted disklabels, not just slice positions.

> Not sure how the 63 made it into the disklabel, though.

Neither do I.

Malcolm Kay