Ok, so we had a brownout, and now I have a 160GB SATA hard drive that is giving errors and will not boot. The first partition is fine and grub loads correctly, but there are some errors on the 2nd partition where all the data is.

I put the drive in another linux machine and the parition in qiestion is /dev/sdb2.

when running a fsck I get this:
----snip
[root@underdog ~]# fsck.ext3 /dev/sdb2
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb2

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
snip----

So Since I dont know where the alternate super blocks are, I run mke2fs:

--snip
[root@underdog ~]# mke2fs /dev/sdb2
mke2fs 1.35 (28-Feb-2004)
max_blocks 4294967295, rsv_groups = 0, rsv_gdb = 1024
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19415040 inodes, 38807015 blocks
1940350 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=41943040
1185 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
---snip

So at this point I try "e2fsck -b $eachaltblock /dev/sdb2" for each one of the backup super blocks but still get an error:

---snip
[root@underdog ~]# fsck.ext3 /dev/sdb2
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext3: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb2
Could this be a zero-length partition?
snip---


Is my data toast?

Any help is greatly appreciated!

WHY did you run mke2fs?

I can't imagine why that would be done. You formatted the partition. Data recovery just went way beyond superblock issues.

Originally, e2fsck -b 8193 <device> might've worked. Additionally, for larger partitions, it becomes 16k or 32k. When you recreated it, it seems it was 32768.

i ran mke2fs -n that only kicks out the backup superblocks, i missed that in the message above. Also I had already tried all the backup superblocks to no avail.

AH, ok. Sorry. Was just quite surprised to see that.

None of them work? That's not a good sign... *duh*

Try running 'dumpe2fs /dev/sdb2'

[root@underdog ~]# dumpe2fs /dev/sdb2
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb2
Couldn't find valid filesystem superblock.

I guess that ended that experiment quickly.

The disk was ext2/ext3, right?

yes sir, it was in another machine so it was using software raid (LVM?).

and fdisk says the partition appears to be normal. or at least it does not report corrupption or unexpected cylander errors.

there was LVM on the partition? LVM sets up all kinds of other things. the LVM didn't span multiple partitions or anything, did it?

You *MAY* be able to use vgscan to try to get it back up and running. I'm not too familiar with LVM, only md/software raid.

i will look into it tomorrow. Thanks for the tips!

I have a very similar problem: Can't mount /dev/mapper/vg_v because of "invalid superblock" for all the superblocks listed by mke2fs -n.

But I just tried debugfs on /dev/mapper/..., and I can at least recover some of the data.

So, I suggest you give it a try. After I backup the home directories, I'll see if debugfs can "fix" the bad superblock info.

I had a similar issue;

i was getting a superblock error just like yours on /var (on it's own partition).

tried many, many things, but there was nothing that worked.

as a last resort i found some references to the gpart program and tried it. lo and behold
it worked (it looks at the actual inodes on the disk and re-writes the partition table).

i wouldn't try this until you've saved any data that you can get.

good luck!
Danimal

Well, I finally figured out the the journal file was "bad," so I used debugfs to remove the journal file (thus, of course, converting my fs from ext3 to ext2) and I can now mount the fs!

Of course, this is all from my "back-up" installation. When I finish dumping the stuff I want to save, I'll see if I can reboot the system where the "bad" fs is root.

Oh, I did try recreating the journal file, and got the "bad superblock" message trying to mount. Perhaps that disk section is bad. At some point (again, after the dump finishes) I'll see if I can create the journal file somewhere else. (Or, more likely, get a new disk drive.)

Either GRUB or the boot image expects an ext3 file system, and I get a kernal panic when I try to boot with the (now) ext2 root fs. I suppose I could figure it out, but I think, at this point, I'll just wipe the partition, recreat it, and restor it from my (currently running) dump file.

As an aside, why does dump have an output file size limit built in? It seems to think that my -f <file> is pointing to a tape drive. Strange.

---snip
Well, I finally figured out the the journal file was "bad," so I used debugfs to remove the journal file (thus, of course, converting my fs from ext3 to ext2) and I can now mount the fs!
--- snip

Exactly how did you do this? I am desperately trying to save data on a disk that got just this problem, but cannot find how to use debugfs to remove the journal file.

Any input would be greatly appreciated.

cheers,

kai