recovery after power outage

Jerry McAllister jerrymc at
Wed Feb 14 01:54:13 UTC 2007

On Mon, Feb 12, 2007 at 08:14:28PM -0500, Marty Landman wrote:

> On 2/12/07, Jerry McAllister <jerrymc at> wrote:
> >
> >On Fri, Feb 09, 2007 at 04:48:44PM -0500, Marty Landman wrote:
> >
> >> >>> Information from DOS bootblock is:
> >> >>> The data for partition 1 is:
> >> >>> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> >> >>>    start 63, size 490223412 (239366 Meg), flag 80 (active)
> >> >>>        beg: cyl 0/ head 1/ sector 1;
> >> >>>        end: cyl 1023/ head 254/ sector 63
> >>
> >> >What does bsdlabel show for it?
> >> >
> >> >> As root, do:    bsdlabel ad1s1
> >>
> >> %sudo bsdlabel ad1s1
> >> # /dev/ad1s1:
> >> 8 partitions:
> >> #        size   offset    fstype   [fsize bsize bps/cpg]
> >>  c: 490223412        0    unused        0     0         # "raw" part,
> >don't
> >> edit
> >> %
> >>
> >> So where do I stand?
> >
> >Hmmm.   Well, that looks like a slice that has not been partitioned -
> >which is essentially what you have been telling us it is.  That is
> >not 'dangerously dedicated'.  It is instead an incompletely partitioned
> >and build slice.
> This HD was working fine for months until the system crashed due to a power
> outage.  My point is I think it had been done right to begin with but the
> drive's data has been corrupted now. Since fsck isn't able to deal with it
> wonder if the data is essentially gone now.
> It has type 'unused' which is what the 'c' partition should be and
> >as such, should not be used.
> Are you saying I should not have set this drive up as the c partition?
> Instead it should have been something like ad1s1a for example?

That is true.  You should not use the 'c' partition.  That is
documented.   Too late now, but yes, ad1s1a would be better.
 -- next time.

> I am wondering what would happen it you tried to mount /dev/ad1s1
> >without the 'c'.
> %sudo mount /dev/ad1s1
> mount: /dev/ad1s1: unknown special file or file system
> %sudo mount /dev/ad1s1c
> mount: /dev/ad1s1c: unknown special file or file system
> %

I am presuming you actually gave it a mount point in those 
mount commands and just didn't reproduce it here.
> I don't know if fsck might work on that.  You might try it (as /dev/ad1s1)
> >with a '-d' flag to see what it might try without actually writing
> >anything
> >to the drive and potentially wrecking something.   Make sure it is not
> >mounted before trying the fsck.
> %sudo fsck -d /dev/ad1s1
> fsck: Could not determine filesystem type
> %sudo fsck -d /dev/ad1s1c
> start (null) wait fsck_unused /dev/ad1s1c
> %

Well, it is not finding something it needs, probably in the 
partition label.

> Did you build a filesystem on this slice with newfs?
> I believe that's how I did it.
> If so, you can try looking for superblocks.
> How do I do that?

You will have to read up on that.   I pulled about some superblocks
about 9 years ago, but don't remember much about that.  Anyway, they
point the filesystem and there are a lot of duplicates.  If one is
bad, it is sometimes possible to use the next one or so to get things
repaired.   You can read up the superblock with 'dd'  just like
below.   You can put in a skip count in dd to skip what you don't want
to read and then read up just the length you need.  You will have to
look that up.

> If you have space for it somewhere, you could also try to dd some of
> >the drive.
> >  dd if=/dev/ad1s1 of=some_file_on_another_disk bs=512 count=10000
> Ok that works, and there is data there.
> That would copy 5 MB    Then you could play with that data in hex
> >or with some debugger (hexdump??) that lets  you muck with it a byte
> >at a time in hex, ASCII, octal, etc and see what you can find.
> ^@%s: not a directory.
> ^@Not ufs
> ^@format^@Invalid %s
> ^@/boot.config^@%s: %s^@/boot/loader^@/boot/kernel/kernel^@
> FreeBSD/i386 boot
> Default: %u:%s(%u,%c)%s
> boot: ^@^H ^H^@No %s
> ^@yes^@no^@Keyboard: %s
> ^@slice^@label^@partition^@%c^H^@error %u lba %u
> Ok I haven't taken to picking apart the bits in this, but that's the stuff
> that looked like English in the plaintext version.
> Are you saying Jerry that if fsck won't deal with this data then my only
> option is to learn/pick apart the internals of the data on that disk myself?

Pretty much, that's it.

> I mean what else can I try? Could I - since have already saved the first 5
> MB of the data - try writing a new mbr and see if that let's fsck fix the
> rest?

Well, it is not an MBR that you need.  That is for booting although it
would not hurt to have one.  But the slice table or the partition label 
might be clobbered.  The slice table is written by fdisk and the partition 
label is written by bsdlabel.   I don't know if you can manage to 
rewrite those in place without making the rest of thing inaccessible
or if it would just go there and happily point to where it used to.
I have never tried that.   If I were to be contemplating that sort of
thing, I would try it on another disk first to see what would happen.
Build a disk the same way you did this one and put a few files one it.
They use fdisk and bsdlabel to rewrite the slice table and label. (but
don't do the newfs as that would definitely wipe things)  Then see
if the files are still there and readable.   It wouldn't need to be
a disk as big as the one your are trying to recover, just any old
drive laying around that you can use to prove concept.

> Pretty much over my head here, would rather not lose this 50 GB of data but
> not sure what more I can do.

Well, I would try the experiment mentioned above with a spare drive.
If it works, then maybe that can get you going.   If not, read up
on superblocks.   You can dd everything off to somewhere and try
following pointers.   That is awfully tedius, but I bet once you
got past the first couple, the rest will be just fine.  Then you 
could try patching up what got corrupted and using dd to write it
all - including slice table and partition label to a drive and 
try to read it.   If you use dd on a device rather than a file
it reads or writes on a sector by sector basis rather than by the
file chain so if you are lucky, you can pull stuff off, rewrite
the munged spots if you can find them and then write it all out
again (i'd I would use a spare drive to write to if possible) and
see if it works.

I would try the slice table and partitino label rewrite experiment
first though.   It does sort of sound like what got smoched is
something in the label.   Otherwise it wouldn't say 'unused' - or
I don't think it would.   I would expect a different error.


> Marty
> -- 
> Web Installed Formmail -
> Webmaster's BBS -

More information about the freebsd-questions mailing list