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