Size in superblock is different from the physical size of the partition
 

hello,

After I resized my root partition (/dev/hda3) using parted when its still mounted (Knoppix didn't come into my mind at that time, so I believed that there is no way to run parted when it's not mounted), I got the following error message:

and then I was asked to run fsck manually, which returns:

and so on...

result of "dumpe2fs /dev/hda3":

and followed by a lot of:

and:

I can't manage to modify superblock manually, and resizing the partition back to match the superblock-recorded size didn't work, parted returned:

running Debian Testing (Sarge)
any help is appreciated, or is any more information needed to be given?
I am a linux newbie (1 year of experience or so)

Skip parted, use sfdisk.

Actually, I do have one question. Is there a partition on the drive after the partition you resized?

do this:
and post the results.

hmmm haha thank you for your reply

but I already re-did partitioning from the beginning, since I have backup copies of my data .

just read the manual entry for sfdisk.. sounds like a great tool, cus parted doesnt support ext3 so far... and with a lot of segmentation faults

haha thank you for spending your time on my problem, and thank you for introducing me to sfdisk XD

same problem, different reason
 

I have exactly the same problem on my brand new eeepc after following the steps to remove unionfs (http://www.antharius.com/blog/?p=293).
Since it does exactly the same even if I restore my eeepc with the factory cd, I think there might be something wrong on their image.

here is the sfdisk -ls of my poor eeepc...

/dev/sda: 1953504

Disk /dev/sda: 243 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sda1 0+ 186 187- 1502046 83 Linux
/dev/sda2 187 240 54 433755 83 Linux
/dev/sda3 241 241 1 8032+ c W95 FAT32 (LBA)
/dev/sda4 242 242 1 8032+ ef EFI (FAT-12/16/32)

for your information,
sda1 is their system partition
sda2 is the user one
sda3 called the boot partition is a user restoration partition
sda4 is called efi as mentioned above

here is the fsck while booting on gparted (my sda becomes hdc)

$fsck /dev/hdc

fsck 1.40.2 (12-Jul-2007)
Couldn't find ext2 superblock, trying backup blocks...

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>

the same occurs with e2fsck -b 8193 /dev/hdc
and now fsck on /dev/hdc1

$fsck /dev/hdc1

fsck 1.40.2 (12-Jul-2007)
The filesystem size (according to the superblock) is 1502048 blocks
The physical size of the device is 1502046 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no

Superblock last mount time is in the future. Fix? no

SYSTEM contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 117946, i_blocks is 4, should be 2. Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

SYSTEM: ********** WARNING: Filesystem still has errors **********

SYSTEM: 67322/188416 files (0.8% non-contiguous), 1499169/1502048 blocks

is there a way to dd the image that is on the factory cd in a way to respect my sda size ?

wow. I had the problem 3 years ago, though =). But as you can see, I didn't end up getting a solution.

I think every problem has a solution.
I only hope this one has more than one because if not I would have to find a good image to be able to get rid of it...

Change physical size
 

I had same problem while migrating on software raid

My solution:
on unmounted partition
e2fsck -f /dev/XXX
resize2fs /dev/XXX

(where XXX is name of partition)

Warning. Can destroy some data, so low-level backup is recomended.
(for backuping can be used program dd)

finding where inode table is stored from super block details
 

Hello
How anyone can find the where inode table is located when he knows only the details of superblock.
please suggest complete solution

For the sake of anyone else who decided it was a good idea to use parted to shrink a filesystem, and found this thread of questions lacking answers to be the only help on the internet, the fix is to run "mke2fs -S /dev/xxx && fsck /dev/xxx", it will rebuild the correct superblock size and check your filesystem.

I had this exact issue after using parted to shrink an ext3 fs+partition, and I followed this advice, and it didn't turn out well.

After doing the shrink operation, my filesystem was actually mountable and apparently intact, it just thought that it was still its old size (larger than the partition) - if I manually mounted it it would mount without complaining - everything was still there, just showing way more free space than it should have had... since it was marked as having errors, fedora wouldn't automount it though, and fsck wouldn't run because of the fs/partition size mismatch.

So tried the mke2fs -S trick to write a new superblock, ran fsck, and now the filesystem is the right size and mounts fine, but everything just got dumped into lost+found.

Is there any way I can fix this and get my data back? At least get it back to its previous state so I can mount it ro and copy my data off? Is my old superblock backed up somewhere, or does e2fsk update the backup superblock as well? Would my old superblock even help, or did the fsck trash my inode structure?

Currently I think I have all my data, just dumped in lost+found without filenames - is there any way to salvage anything from that?

I too was suffering this exact problem. After shrinking a ext3 partition the partition mounted and all my data was present. However the next day when the file systems were being checked at boot time, my shrunk file system failed with:

The filesystem size (according to the superblock) is 10485760 blocks
The physical size of the device is 10477568 blocks
Either the superblock or the partition table is likely to be corrupt!

As I could not get to the data anyway, I simply resized my file system to the same number of blocks as the device size using the command

resize2fs /dev/VolGroup00/LogVol_Oracle 10477568

Running e2fsck no longer reported errors.

I had to do "resize2fs -f /dev/md0 10477568" and after the reboot, a filecheck was initiated. All my data was still present!

Everyone seems to forget the -f (to force) for resize2fs, if it refuses at first. I forgot too, until I read this. The input of size is not needed to make it match the partition table, though.

I just typed:

Yea this advise here is as great as it is simple!
I've got the same problem from resizing my ext4 partition on a GPT disk using gparted (parted clean refused to do it!). After resizing the partition size according to the superblock would exceed the actual size of the device.
Running resize2fs corrected the thing altogether, so now I can mount and access it!

Great thanks!

Another filesystem rescued today with your useful advice.

Thank you!

A lightning stroke damaged my disk. I dd'ed the image to another disk an ran fsck on the image. I got:
Is there anything that is likely to work that I can do to rescue data from the disk?

I have had EXACTLY the same issue as others in this thread, AND my compliments to Mr. Hailey's_Comet . . . the only thing I would add to the line is sudo. But the resize2fs command IS the one that SOLVED my problem. Compliments again to HC.

I found this solution by searching on the clause "Either the superblock or the partition table is likely to be corrupt" . . . the message from a forced fsck. I had tried TestDisk and a few other remedies that DIDN'T work.

For those of us that mess around with GParted trying to shrink partitions and screw up, this is a likely solution (or at least it was for me and a few others here.) Thanks very much HC.

i also did: and then and it WORKED. many thanx.

On a sidenote: my problem appeared on a ,now, faulty external case. so after i took the disk out and into my pc i restored the partition with gparted to max size. Apparently the external case saw the disk of less capacity than the partition, and even so many errors occured later on on transfers. i found in the past that using ext2 works quite well, (journals get dropped). Nevermind, i guess its time has come, so i'm now using that disk as an internal one.

Either the superblock or the partition table is likely to be corrupt!
 

I make a resize of my logical disc, /dev/mapper and I found the error:

Either the superblock or the partition table is likely to be corrupt!

Ok the solution is to make this order with the corrupt partition:

[root@localhost]# mke2fs -S /dev/mapper/VolGroup-lv_home && fsck /dev/mapper/VolGroup-lv_home

and that's all...

source:

novell support