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
I forgot to mention earlier that I'm not subscribed to the list so i'd
appreciate if the possible replies were CC'd directly to
[email protected] as well. Thanks.
On Sat, Apr 21, 2001 at 06:52:01PM +0300, Ville Holma wrote:
...
>
> 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.
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
On Sat, 21 Apr 2001, Ville Holma wrote:
> 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>
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
On Sat, Apr 21, 2001 at 06:52:01PM +0300, Ville Holma wrote:
> EXT2-fs: #blocks per group too big: 2147516416
> 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).
> 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
(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.
> 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.
Nod
> 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).
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
> > 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.
>
> Nod
>
> > 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).
>
> Try e2fsck -b 8193 /dev/hdb7
>
> (and 16384, 32768)
>
> This is a backup copy of the superblock.
>