Incorrect super block on a disk

Paul English penglish at
Mon May 5 14:04:44 PDT 2003

On Sun, 4 May 2003, Greg 'groggy' Lehey wrote:

> > it tries for an alternate superblock, fails and then I try doing
> > fsck -b 32 (as recommended in the manpages) and I get the same error.
> >
> > Is there anything I'm doing wrong or something else to try?
> It seems pretty certain that whatever they sent back from the data
> recovery house is not a UFS file system.  You should try to find out
> how they got the data there.  I can't imagine them creating a new file
> system.  Until you know that, there's not much point trying
> alternatives, though some of them exist.

I will check with them - it looks like they don't have someone I can talk
to on Saturday. I believe though that they just did a bit-for-bit or
byte-for-byte copy. The partition table information is still there - the
output of disklabel shows what appears to me to be a valid disk label for
all of the partitions, this one included.

> > Can I somehow regenerate the super block?
> Regenerating super blocks is simple: that's what newfs(8) does.  The
> trick is keeping your data.


Fortunately they still have the source data, and I can also do a dd of the
partition to another drive before I go mucking with newfs.

I don't suppose that newfs has a special option to just try to regenerate
superblocks and save the data? In my web searching for solutions, it looks
like Linux has a -S option for mke2fs that will attempt to rebuild
superblocks while saving the data.

Are there any other alternate superblocks? Again it appears that Linux
saves them every 8K clusters, but the fsck manpage on freebsd only
mentions that block 32 is usually an alternate.


More information about the freebsd-questions mailing list