[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 667
  • Last Modified:

Corrupt Superblock

I run RedHat Linux 4.1 on a 486 machine with all the usual stuff.  This morning, I had a kernel panic due to a disk error on my boot partition, and now I can't reboot.

I booted from my "rescue" disk, and was able to mount the suspect partition.  When I try to run fsck on it, it tells me that I have a corrupt superblock, and that I should use fsck -b <alternate superblock number> /dev/hda4, and suggested that I try block 8193, a common location for alternate supeblocks.  Unfortunately, that didn't work.

So here is the question:  Is there some way to find out where my alternate superblocks are located?  If not, is there some other strategy to rescue this disk?

Thanks

Justin Harlow
0
harlow
Asked:
harlow
  • 3
  • 2
1 Solution
 
jlmsCommented:
Assuming you have a ext2fs filesystem , then try mke2fs -S (see man page first), and the the fsck command.


0
 
harlowAuthor Commented:
I looked at the man page for mke2fs -S, and it makes the operation sound pretty scary.  Is that mostly lawyerspeak, or is it probable that I am going to totally hose my files system by trying this?  I realize that nothing is certain in messing with filesystems, especially corrupt ones, but what's your guess as to the odds of success here?

I am curious about the algorithm used to decide where to hide backup superblocks (right... I didn't copy them down when I built the filesystem long ago...)  Where is this documented for e2fs?  I'd like to try to figure out where my duplicates are, and use e2fsck -b before I risk blowing the whole thing away.

Thanks

JEH

0
 
jlmsCommented:
Well, my Linux says it just show things without actually afecting anything, I will check later because my Linux box is not here now.  My guess is than most of the times one gets this problems the posibilities of loss are unfortunately high :(


0
 
jlmsCommented:
Sorry, you have reason to be scared, this command actually rewrites things (without modyfing inodes), and as the man page says, is practically the last resource.
In Linux I have not done something of this sort; with other UNIXes it works and most times allows you to make some recovery work. Dont forget to make a filesystem check after this.

0
 
harlowAuthor Commented:
Thanks.  I have sort of readched the same conclusion, namely, that my partition is hosed beyond salvage.  I was not even able to run mke2fs -S, which is supposed to rewrite the superblock and leave the inodes alone.  It aborts, saying that there is no file or directory called "stat".  The documentation is silent on what that file might be, or where it is supposed to be.  Even if this were to work, I think I am still stuck, because a lot of the kernel panics I get involve the inability to read certain specific inodes.  That is probably not totally a superblock problem.

As it stands, I have been able to mount the bad partition, and have successfully copied off almost all of its contents to another disk.  Unfortunately, the parts I cannot copy are /etc and parts of /var, so a full restoration is probably not likely even after reformatting the partition.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now