recovering FC3 from a bad superblock

aluminumsulfate at earthlink.net aluminumsulfate at earthlink.net
Wed May 18 01:25:01 EDT 2005


   From: Greg Rundlett <greg.rundlett at gmail.com>
   Date: Mon, 16 May 2005 13:23:37 -0400

   My work system is a dual-boot laptop running FC3 and Windows (don't
   actually use it).  The battery ran out, and it seems like the cache

First, it's just asking for data loss to run window$ and linux on the
same machine.  I've lost many gigabytes to window$ thinking it knew
what to do with a linux partition and *quickly* learned to use
removable drives.  IMHO (and, probably, in fact) window$ is too dumb
and arrogant to coexist peacefully with Linux. (A comical, but
telling, example: The only Y2K bug I had was a result of McAfee
thinking LILO was a virus.)

   got dumped onto the superblock b/c the next time I booted, it refused

Onto the *superblock*??  Does the superblock lie in the area where
that cache would have landed?

<snip>

   mkdir test; mkdir test2; mount -r /dev/hda1 /test; mount -r /dev/hda2 /test2

   And 
   ls -al test2 
   shows me that there is a complete linux filesystem there, including
   the boot directory

The fact that *this* happens is important.  If mounting with the
rescue disk works without complaint, your superblock is probably *in
tact*.  Instead, it may be mount and/or e2fsck which have somehow
become corrupt....  As others have said, if you see a filesystem
there, copy it. :)

   I am kinda lost on what to do to try to repair the superblock.  If I
   try running e2fsck (read-only) on that partition, it doesn't complain.
    So, forcing it
   e2fsck -f -n /dev/hda2 
   tells me there are errors

If, due to whatever hardware/software failure has occured,
mount/e2fsck have become corrupt, then it is likely that other
filesystem structures have also.  I had my X libraries disappear once,
because of a (only very slightly) bad stick of RAM.

   Using the so-called backup superblocks [block-size (8192 *n) +1], it
   reports a 'bad magic number'
   e2fsck -b 16384 -n /dev/hda2

You may also want to check this formula.  From what I remember, the
actual formula e2fs uses isn't linear.

   How should I go about fixing the 'errors' while the filesystem is not
   mounted?  Or, how should I mount the filesystem properly so that it
   can be fixed, but not 'used' during the fix?

<to those who have advised not to>: Can it hurt to repair a filesystem
while it's mounted read-only?

   I am reading a grub howto now, but any help would be appreciated.
   http://www.linuxquestions.org/questions/showthread.php?s=&postid=1413211

One thing which hasn't been mentioned on this thread is imaging the
disk.  If you can't access all the data you need from the parts of the
filesystem which are still intact, you can image the drive (either to
another drive, DVD, or whatever) and work on that later.  That way,
you could safely wipe/mess with/reinstall on the original drive and
get running again in the interim.

There are some docs on e2fs layout, e2fs recovery, and tools for
editing and/or recovering data from e2fs filesystems (at least one is
even automated).  If you want to do some real studying, you could
probably recover your data.  But it would (guaranteed) take a Very
Long Time(TM).  Ask: Is it worth it?  If so, there are also
professional data recovery services (Excalibur in MA comes to mind).
But they'll cost your shirt... and your pants... and y....

I've heard that the IDERAW features of kernels 2.4+ allow you to
microstep your hard drive, so you can recover data that has actually
been overwritten on the disk.  Has anyone heard of software that is
able to make use of this functionality?

   Thanks
   _______________________________________________
   gnhlug-discuss mailing list
   gnhlug-discuss at mail.gnhlug.org
   http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss




More information about the gnhlug-discuss mailing list