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?
ADDING TESTDISK LOG:
/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_size=92
hdr_lba_self=1
hdr_lba_alt=5860531054 (expected 5860531054)
hdr_lba_start=34
hdr_lba_end=5860531021
hdr_lba_table=2
hdr_entries=128
hdr_entsz=128
Current partition structure:
1 P Unknown 2048 5860531021 5860528974 [PABnew]
