25

I have a micro SD card which has a FAT32 partition and an EXT4 partition. The EXT4 partition will no longer mount. dmesg shows the following error:

EXT4-fs (sdb2): bad geometry: block count 2199023779840 exceeds size of device (524288 blocks)

I've Googled, but still don't fully understand where the problem is (in the partition table? the filesystem?) nor how to fix it. I have attempted a number of solutions:

  • Using testdisk to write the partition table
  • Using fsck to restore the superblock from the backups (I've tried all of them). e.g. fsck.ext4 -b 163840 -B 4096 /dev/sdb2
  • Using fsck -cc to check for bad blocks
  • Using resize2fs to set the size of the partition. Output: The combination of flex_bg and !resize_inode features is not supported by resize2fs.

When I run fsck, it comes up with a bunch of errors (full output below), which it claims to fix. If I run it again, however, it shows the same errors all over again, every time.

How can I fix the bad geometry issue and make my filesystem mountable again? How did this happen?

fsck output:

e2fsck 1.42 (29-Nov-2011)
One or more block group descriptor checksums are invalid.  Fix<y>? yes

Group descriptor 0 checksum is invalid.  FIXED.
Group descriptor 1 checksum is invalid.  FIXED.
Group descriptor 2 checksum is invalid.  FIXED.
Group descriptor 3 checksum is invalid.  FIXED.
Group descriptor 4 checksum is invalid.  FIXED.
Group descriptor 5 checksum is invalid.  FIXED.
Group descriptor 6 checksum is invalid.  FIXED.
Group descriptor 7 checksum is invalid.  FIXED.
Group descriptor 8 checksum is invalid.  FIXED.
Group descriptor 9 checksum is invalid.  FIXED.
Group descriptor 10 checksum is invalid.  FIXED.
Group descriptor 11 checksum is invalid.  FIXED.
Group descriptor 12 checksum is invalid.  FIXED.
Group descriptor 13 checksum is invalid.  FIXED.
Group descriptor 14 checksum is invalid.  FIXED.
Group descriptor 15 checksum is invalid.  FIXED.
/dev/sdb2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (24465, counted=24466).
Fix<y>? yes

Free blocks count wrong for group #2 (4788, counted=5812).
Fix<y>? yes

Free blocks count wrong for group #3 (8710, counted=8881).
Fix<y>? yes

Free blocks count wrong for group #8 (5682, counted=22066).
Fix<y>? yes

Free blocks count wrong (299742, counted=317322).
Fix<y>? yes

Inode bitmap differences:  -(8193--8194) -8197 -8208 -(8225--8226) -8229 -(8240--8241) -(8257--8258) -8261 -8272 -8274 -(8289--8290) -8293 -(8304--8306) -(8321--8322) -8325 -8336 -8339 -16387 -16389 -16400 -16419 -16421 -(16432--16433) -16451 -16453 -16464 -16466 -16483 -16485 -(16496--16498) -16515 -16517 -16528 -16531 -24577 -24579 -24581 -24592 -24609 -24611 -24613 -(24624--24625) -24641 -24643 -24645 -24656 -24658 -24673 -24675 -24677 -(24688--24690) -24705 -24707 -24709 -24720 -24723 -(32770--32771) -32773 -32784 -(32802--32803) -32805 -(32816--32817) -(32834--32835) -32837 -32848 -32850 -(32866--32867) -32869 -(32880--32882) -(32898--32899) -32901 -32912 -32915 -(40961--40963) -40965 -40976 -(40993--40995) -40997 -(41008--41009) -(41025--41027) -41029 -41040 -41042 -(41057--41059) -41061 -(41072--41074) -(41089--41091) -41093 -41104 -41107 -(49156--49157) -49168 -(49188--49189) -(49200--49201) -(49220--49221) -49232 -49234 -(49252--49253) -(49264--49266) -(49284--49285) -49296 -49299 -57345 -(57348--57349) -57360 -57377 -(57380--57381) -(57392--57393) -57409 -(57412--57413) -57424 -57426 -57441 -(57444--57445) -(57456--57458) -57473 -(57476--57477) -57488 -57491 -65538 -(65540--65541) -65552 -65570 -(65572--65573) -(65584--65585) -65602 -(65604--65605) -65616 -65618 -65634 -(65636--65637) -(65648--65650) -65666 -(65668--65669) -65680 -65683 -(73729--73730) -(73732--73733) -73744 -(73761--73762) -(73764--73765) -(73776--73777) -(73793--73794) -(73796--73797) -73808 -73810 -(73825--73826) -(73828--73829) -(73840--73842) -(73857--73858) -(73860--73861) -73872 -73875 -(81923--81925) -81936 -(81955--81957) -(81968--81969) -(81987--81989) -82000 -82002 -(82019--82021) -(82032--82034) -(82051--82053) -82064 -82067 -90113 -(90115--90117) -90128 -90145 -(90147--90149) -(90160--90161) -90177 -(90179--90181) -90192 -90194 -90209 -(90211--90213) -(90224--90226) -90241 -(90243--90245) -90256 -90259 -(98306--98309) -98320 -(98338--98341) -(98352--98353) -(98370--98373) -98384 -98386 -(98402--98405) -(98416--98418) -(98434--98437) -98448 -98451 -(106497--106501) -106512 -(106529--106533) -(106544--106545) -(106561--106565) -106576 -106578 -(106593--106597) -(106608--106610) -(106625--106629) -106640 -106643 -114694 -114704 -114726 -(114736--114737) -114758 -114768 -114770 -114790 -(114800--114802) -114822 -114832 -114835 -122881 -122886 -122896 -122913 -122918 -(122928--122929) -122945 -122950 -122960 -122962 -122977 -122982 -(122992--122994) -123009 -123014 -123024 -123027
Fix<y>? yes

Free inodes count wrong for group #0 (7803, counted=7804).
Fix<y>? yes

Free inodes count wrong (130683, counted=130684).
Fix<y>? yes


/dev/sdb2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb2: 388/131072 files (22.7% non-contiguous), 206966/524288 blocks

fdisk -l output:

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 heads, 32 sectors/track, 15271 cylinders, total 31275008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005ce93

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048    27080703    13539328    c  W95 FAT32 (LBA)
/dev/sdb2        27080704    31275007     2097152   83  Linux
Improve this question
2
  • Can you include the output from fdisk -l for this card?
    – Timo
    Feb 18, 2014 at 11:59
  • @Timo sorry, forgot to answer you. I've updated the question with fdisk output
    – Michael
    Feb 19, 2014 at 16:31

6 Answers 6

Reset to default
12

Same problem after truncating a SD card image where the SD had a few blocks less than the original. Repartitioned the drive with fdisk (see above), but message "Size in superblock is different from the physical size of the partition" remained. Found the solution here: http://www.linuxquestions.org/questions/linux-hardware-18/size-in-superblock-is-different-from-the-physical-size-of-the-partition-298175/

So, on the unmounted partition: e2fsck -f /dev/XXX resize2fs /dev/XXX

Improve this answer
6

I had the same problem with an image file, i. e. without any partition table, so the problem is within the file system itself. I was able to fix it by just doing a resize2fs on the image file.

Improve this answer
4
  • I had the issue on a preformatted eMMC card. resize2fs on the failing ext4 partition solved the issue.
    – Peter Gloor
    Mar 28, 2019 at 10:47
  • Mine keeps saying Please run 'e2fsck -f /dev/disk/by-label/...' first. which I did.
    – Sridhar Sarnobat
    Aug 31, 2020 at 20:03
  • 2
    Hmmm, sudo resize2fs -f /dev/sdb2 seemed to work this time (on a different physical disk).
    – Sridhar Sarnobat
    Sep 9, 2020 at 3:38
  • ...but not always (even on a new disk which I did a physical copy of an old disk of).
    – Sridhar Sarnobat
    Sep 11, 2020 at 1:23
4

The filesystem doesn't care about disk geometry; this is a partition table problem.

I suggest that you make a dump of the partition table, check the result and overwrite the partition table with this dump. That should correct the CHS entries.

sfdisk -d /dev/sdx >sdx.txt
cat sdx.txt
sfdisk /dev/sdx <sdx.txt
Improve this answer
4
  • 1
    You'll need to be root to run these commands, in case you didn't know this.
    – slm ♦
    Feb 18, 2014 at 13:01
  • 1
    Thanks for your answer. Is there a reason sfdisk should work to write the partition table where testdisk didn't? I tried it and sfdisk claims it successfully wrote the partition table, but I'm still getting the bad geometry error. The output of sfdisk -d is the same before and after writing. Have I missed something? Any other thoughts?
    – Michael
    Feb 19, 2014 at 2:05
  • @Michael To tell the truth: I neither noticed that nor did I know what testdisk is. The Internet tells me: "checks and recovers lost partitions". If that is just for lost partitions why should it repair existing partitions?
    – Hauke Laging
    Feb 19, 2014 at 14:24
  • @HaukeLaging I just asked because it said it rewrote the partition table, too. Anyway, any idea about the sfdisk results?
    – Michael
    Feb 19, 2014 at 16:29
4

I pretty much had the same issue, trying to mount gave:

$sudo mount /dev/sda2 ./oldfs/ 
mount: wrong fs type, bad option, bad superblock on /dev/sda2,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

I tried the above mentioned re-writing of the part-table, without success.

So, finally I was able to solve the issue by re-partitioning my drive via fdisk. I deleted my 2nd partition and re-created it again. 

$fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 31.4 GB, 31440502784 bytes
64 heads, 32 sectors/track, 29984 cylinders, total 61407232 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ecdca

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    20447231    10222592   83  Linux
/dev/sda2        20447232    61406208    20479488+  83  Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1-4, default 2): 
Using default value 2
First sector (20447232-61407231, default 20447232): 
Using default value 20447232
Last sector, +sectors or +size{K,M,G} (20447232-61407231, default 61407231): 
Using default value 61407231

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
Improve this answer
2
  • worked perfectly, which is ridiculous, but hey.
    – mgjk
    Aug 12, 2015 at 15:08
  • Didn't work for me.
    – Big McLargeHuge
    Sep 26, 2015 at 18:23
0

Since I wasn't able to find any other solution, I reformatted the EXT4 partition. This eliminated the bad geometry error. Wish I knew why.

Improve this answer
0

LVM issue

rhelserver1:/var/log # mount -a
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg01-lvol1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

rhelserver1:/var/log # resize2fs -f /dev/mapper/vg01-lvol1
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/vg01-lvol1 to 1274880 (4k) blocks.
resize2fs: Can't read a block bitmap while trying to resize /dev/mapper/vg01-lvol1
Please run 'e2fsck -fy /dev/mapper/vg01-lvol1' to fix the filesystem
after the aborted resize operation.

solution:

rhelserver1:/var/log # vgextend vg01 /dev/sdg
  Volume group "vg01" successfully extended

rhelserver1:/var/log # lvextend -L +100M /dev/mapper/vg01-lvol1
  Size of logical volume vg01/lvol1 changed from 4.86 GiB (1245 extents) to 4.96 GiB (1270 extents).
  Logical volume vg01/lvol1 successfully resized.
rhelserver1:/var/log # resize2fs /dev/mapper/vg01-lvol1
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/vg01-lvol1 to 1300480 (4k) blocks.
The filesystem on /dev/mapper/vg01-lvol1 is now 1300480 blocks long.

rhelserver1:/var/log # mount -a
rhelserver1:/var/log # df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   6.2G  1.1G  5.2G  18% /
devtmpfs                232M     0  232M   0% /dev
tmpfs                   244M     0  244M   0% /dev/shm
tmpfs                   244M  4.6M  240M   2% /run
tmpfs                   244M     0  244M   0% /sys/fs/cgroup
/dev/sda1              1014M  145M  870M  15% /boot
tmpfs                    49M     0   49M   0% /run/user/0
/dev/mapper/vg01-lvol1  4.8G  4.3G  312M  94% /localrepo
rhelserver1:/var/log #
Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .