This all started when a disk I use for archiving some data suddenly didn't mount anymore.

When I tried with terminal, is said: "The filesystem size (acording to the superblock) is 732566128 blocks The physical size of the device is 732565864 blocks Either the superblock or the partition table is likely to be corrupt!"

When I try to mount it with the Gnome-Disk-Utility, I got this error: "Error mounting /dev/dm-6 at /media/user1/3PAB: Command-line `mount -t "ext3" -o "uhelper=udisks2,nodev,nosuid" "/dev/dm-6" "/media/user1/3PAB"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/mapper/luks-c4ebeef5-7537-417e-b63b-fedc99561677, missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg | tail or so. (udisks-error-quark, 0)"

Also, syslog gave me this: "Dec 12 15:12:44 d8d kernel: [ 47.862779] EXT4-fs (dm-6): mounting ext3 file system using the ext4 subsystem Dec 12 15:12:44 d8d kernel: [ 47.863025] EXT4-fs (dm-6): bad geometry: block count 732566128 exceeds size of device (732565864 blocks)"

I don't understand why it says "mounting ext3 file system using the ext4 subsystem", when I know it's ext3 and "lsblk -f" confirms it. Although fdisk states "Microsoft basic data" but I already searched google and know this is a bug.

I've tried "fsck" and "fsck -f" more than once both, but no luck.

When I bought this disk, I actually bought two units (same size, same brand, etc), and formatted both the same exact way, and encrypted both of them with LUKS also the same.

Only the data I put into each of them was different.

So, after googling for some time, I ran this commands in both disks so I could see the differences and save all the results into txt files in case to be needed: sfdisk -luS /dev/sdg fdisk -l /dev/sdg tune2fs -l /dev/mapper/PAB

As a result, I found that the superblock size was correct, so I concluded the partition of the first disk misteriously changed to some blocks early thus creating this situation.

Device Start End Sectors /dev/sdb1 2048 5860533134 5860531087 (correct; disk 2) /dev/sdg1 2048 5860531021 5860528974 (incorrect; disk 1)

So, I thought I could solve this by manually creating a new partition table using parted and set the end at the correct sector.

I did that, but now the new partition isn't recognized as a LUKS partition. And in order not to make things worse than they are, I made this help request.

Is it possible to recover the data?

/dev/sdg: LBA, HPA, LBA48, DCO support
/dev/sdg: size 5860531055 sectors
/dev/sdg: user_max 5860531055 sectors
/dev/sdg: native_max 5860533168 sectors
/dev/sdg: dco 5860533168 sectors
Using locale 'en_US.UTF-8'.

Wed Dec 14 01:02:53 2016
Command line: TestDisk /debug /log /dev/sdg

TestDisk 6.14, Data Recovery Utility, July 2013
OS: Linux, kernel 3.16.0-4-amd64 (#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)) x86_64
Compiler: GCC 4.9
Compilation date: 2014-10-19T15:35:24
ext2fs lib: 1.42.12, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none
Hard disk list
Disk /dev/sdg - 3000 GB / 2794 GiB - CHS 364801 255 63, sector size=512 - ST3000DM001-1CH166, S/N:Z1F0R2CP, FW:CC43
/dev/sdg: Host Protected Area (HPA) present.
Partition table type (auto): EFI GPT
Disk /dev/sdg - 3000 GB / 2794 GiB - ST3000DM001-1CH166
Partition table type: EFI GPT
Analyse Disk /dev/sdg - 3000 GB / 2794 GiB - CHS 364801 255 63
hdr_lba_alt=5860531054 (expected 5860531054)
Current partition structure:
1 P Unknown 2048 5860531021 5860528974 [PABnew]

  • Just a comment on why it says "mounting ext3 file system using the ext4 subsystem": the term subsystem refers to the body of code implementing the driver for the file system. The kernel used to have a separate ext3 subsystem, but since the ext4 subsystem can also handle ext3 file systems, it was removed and now the ext4 susbystem is responsible for both file systems. Commented Dec 13, 2016 at 19:36
  • Can somebody at least give some advice? Commented Dec 15, 2016 at 22:23
  • Can somebody at least give some advice? Commented Dec 17, 2016 at 11:39
  • I think unfortunately there's no solution Commented Dec 18, 2016 at 16:15

1 Answer 1


I've found the cause of this in here:



"I suspect you motherboard set a HPA - that's what some gigabyte motherboard tend to do (or used to, at least, someone convinved me a while ago this should no longer happen"

"max sectors = 5860531055/5860533168, HPA is enabled" "what happened is that Gigabyte boards have a feature to backup the BIOS to the end of the primary HDD"

"It used to be buggy on some boards"

I still can't believe how on earth a fckng motherboard does this!!!!

I'm mad as hell and posting this in case anyone has the same problem!

I'll never again buy a Gigabyte motherboard in my life! Never!!!

  • Read also this link, for more info on HDA and why it is a curse: forums.lime-technology.com/topic/… Commented Sep 4, 2017 at 18:57
  • For anyone facing a similar problem, don't make a partiton and at the same time create a filesystem like I did (mkpart primary ext3 2048s -1s). This parted command is fine in normal conditions, but not in this cenario I had. At most, I should have created an empty partition, not a filesystem, in order to preserve the LUKS header. You can read the rest of the this story here: linuxquestions.org/questions/… Commented Sep 6, 2017 at 9:29
  • Now I know the solution for this situation was quite simple: 1st step - check if HPA is enabled: hdparm -N /dev/sdx /dev/sdx: max sectors = 78125000/78165360, HPA is enabled 2nd step - remove the HPA: hdparm -N p"max number of sectors" /dev/sdx example: hdparm -N p78165360 /dev/sdx 78165360 = denominator from fraction above done restart credits: superuser.com/questions/642637/… see also DCO Commented Jun 1, 2018 at 11:34

You must log in to answer this question.

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