LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (http://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   Size in superblock is different from the physical size of the partition (http://www.linuxquestions.org/questions/linux-hardware-18/size-in-superblock-is-different-from-the-physical-size-of-the-partition-298175/)

cyberfishee 03-05-2005 11:23 PM

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:

Quote:

The filesystem size (according to the superblock) is 12453462 blocks
The physical size of the device is 10093482 blocks
Either the superblock or the partition table is likely to be corrupt!
and then I was asked to run fsck manually, which returns:

Quote:

Error reading block 10125318 (Invalid argument) while doing inode scan. Ignore error<y>?
Error reading block 10125319 (Invalid argument) while doing inode scan. Ignore error<y>?
and so on...

result of "dumpe2fs /dev/hda3":

Quote:

dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name: /
Last mounted on: <not available>
Filesystem UUID: e43b5b09-ccbb-492c-bd82-18795f417f1c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype sparse_super
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6230112
Block count: 12453462
Reserved block count: 622673
Free blocks: 10056329
Free inodes: 5959084
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16352
Inode blocks per group: 511
Last mount time: Sat Mar 5 10:18:58 2005
Last write time: Sat Mar 5 07:03:26 2005
Mount count: 17
Maximum mount count: 30
Last checked: Wed Dec 31 19:00:00 1969
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Journal backup: inode blocks
and followed by a lot of:

Quote:

Group 380: (Blocks 12451840-12453461)
Block bitmap at 12451840 (+0), Inode bitmap at 12451841 (+1)
Inode table at 12451846-12452356 (+6)
1109 free blocks, 16352 free inodes, 0 directories
and:

Quote:

dumpe2fs: /dev/hda3: error reading bitmaps: Can't read an block bitmap
I can't manage to modify superblock manually, and resizing the partition back to match the superblock-recorded size didn't work, parted returned:

Quote:

GNU Parted 1.6.9
Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.

Using /dev/hda
Information: The operating system thinks the geometry on /dev/hda is
155061/16/63. Therefore, cylinder 1024 ends at 503.999M.
(parted) print
Disk geometry for /dev/hda: 0.000-76319.085 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 95.484 primary ext3 boot
2 95.484 572.414 primary linux-swap
3 572.414 40000.078 primary ext3
4 49218.750 76319.085 primary ext3
(parted) resize 3
Start? [572.4141]?
End? [40000.0776]? 49218.749
Error: The file system is bigger than it's volume!
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)

jiml8 03-06-2005 09:18 PM

Skip parted, use sfdisk.

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

do this:
Code:

sfdisk -ls
and post the results.

cyberfishee 03-07-2005 12:13 AM

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

ksign 06-12-2008 10:46 AM

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 ?

cyberfishee 06-12-2008 02:17 PM

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

ksign 06-12-2008 07:04 PM

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...

mintaka 10-16-2008 10:06 AM

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)

deepakcoep 07-09-2009 04:00 AM

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

Raptor85 12-09-2009 04:09 AM

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.

kodos96 01-03-2010 09:05 PM

Quote:

Originally Posted by Raptor85 (Post 3785228)
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?

butney 06-28-2010 05:36 AM

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.

Zilvermeeuw 04-16-2011 09:47 AM

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

Hailey's_Comet 07-18-2011 03:23 PM

Quote:

Originally Posted by Zilvermeeuw (Post 4326339)
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:
Code:

resize2fs -f /dev/sdb1

kostya 07-31-2011 10:17 AM

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!

Thad E Ginataom 09-17-2011 03:02 AM

Quote:

Originally Posted by Hailey's_Comet (Post 4418424)
I just typed:
Code:

resize2fs -f /dev/sdb1

Another filesystem rescued today with your useful advice.

Thank you!


All times are GMT -5. The time now is 10:49 PM.