a way to restore my hd ?

Hello all,

I'm affraid this list is my last chance at saving my harddrive. I hope this kind of question is appropriate here and if not, my appologies.

Anyway, here's the deal. I upgraded my hardware to 1GHz Athlon with a 133 kHz FSB, Via KT133A chipset motherboard and 256 Mb of 133 sdram. I'm running a standard 2.4.3 kernel.

The memory I had was however somehow corrupt and after I got my new system booted up and used it a little it became shaky and then locked hard and I could do nothing but reset it. I suppose this was caused by the malfunctioning memory but I can't be sure, I know there has been problems with the via chipset also.

Anyway now that I try to boot up the system I get a kernel panic like this:

EXT2-fs: #blocks per group too big: 2147516416
fatfs: bodus cluster size
kernel panic: VFS: Unable to mount root fs on 03:47

So I set up another linux box and tried to run e2fsck on the partition resulting in this

debian:~# e2fsck /dev/hdb7
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Corruption found in superblock.  (frags_per_group = 2147516416).

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 -2147450879 <device>

So I tried to use the huge block size like e2fsck suggests and I get this

debian:~# e2fsck -b -2147450879 /dev/hdb7
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
e2fsck: Attempt to read block from filesystem resulted in short read while
trying to open /dev/hdb7
Could this be a zero-length partition?

This is where the human panic occured. There is data on that partition that I _really_ do not want to loose. I'm clueless and woud appreciate any help/suggestions. If some additonal information is needed I'm more than happy to deliver.

Thanks in advance

Ville

On Sat, Apr 21, 2001 at 06:52:01PM +0300, Ville Holma wrote:
...

I run in similar trouble last week after a power breakage.
My superblock was also corupted and I got also the message to try an other superbock, but I don't know at which address it was (e2fsck don't show you the correct addresses, it gives only a syntax example). Remembering that mke2fs shows it, I use it with the test option "-n" (so it only simulate the making of a filesystem) and got the addresses for the spare superblocks and was able to recover the filesystem with no data lost.

example:
pingi:~ # mke2fs -n /dev/sdb3

mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
91392 inodes, 182739 blocks
9136 blocks (5.00%) reserved for the super user First data block=0
6 block groups
32768 blocks per group, 32768 fragments per group 15232 inodes per group
Superblock backups stored on blocks:

        32768, 98304, 163840

Don't miss the -n option !!!

e2fsck -b 32768 /dev/sdb3

Here are also some howtos related to restoring data and undelete files.

Karsten Keil
SuSE Labs
ISDN development

This doesn't look like a reasonable number for an inode, you might want to try 8193 or 16385. Before doing that I'd recommend taking an image, something like dd if=/dev/hdb7 of=/tmp/backup and then using the loop device to work on that. If the partition's bigger than 2 gig you will probably need to compress it first with something like dd if=/dev/hdb7 | gzip > /tmp/backup.gz (note that if it's compressed the loop device won't work and you'll have to work on the bare hardware). If using an alternate superblock doesn't work a last ditch fix may be mke2fs -S /tmp/backup (or mke2fs -S /dev/hdb7 if the dd result was too big). This will rewrite the superblocks, you will then need to run e2fsck to clean up. This did the trick for me on a drive that got a whole bunch of bad sectors that I had to get data off.

If even that doesn't work and you're really desperate for the data and it's in text format, you can probably extract it from the backup image.

Cheers, Steve

(1) e2fsck is very good at correcting minor problems. But if something really bad happened, e2fsck will make matters only worse. If your data is valuable, keep e2fsck far away. (For example, make a copy with dd before starting to fiddle with the disk contents.)

(2) No doubt you do not really have a disk with over 2^31 blocks, so this suggestion from e2fsck is just a bug in e2fsck. Maybe -b 32768 would have been more successful.

It might be interesting to look at the contents of the superblock to see what kind of corruption occurred. Bad memory tends to change a single bit. Here your data suggests more than one corrupted bit. With disk I/O problems one often sees lots of errors - maybe blocks with all zeros or all ones, or all data shifted by one or more bits, etc.

Nod

Try e2fsck -b 8193 /dev/hdb7

(and 16384, 32768)

This is a backup copy of the superblock.

Thank You everybody who helped me solve the problem. I found a working back-up of the superblock at -b 32768 and was able to save all of my important work from the harddrive. The filesystem was however badly corrupted and lots of other files were truncated after e2fsck had finished. So I ended up just re-installing my linux distribution but didn't loose any valuable work. Lucky me.

So, again, Thank You all for the great help I received. You know who you are.

Ville

system

I

problems