Search:

http://www.sevenforums.com/
When it comes to Windows stuff this is a very good website.

I am curious as to how GParted was able to expand the partition to 2TB on a 1TB disk. That's very odd....

The external drive has a single NTFS partition. You may want to use Windows to do a filesystem check.
What application reported it as 2TB?

This means that the size of the partition is too small for the size of the ext4 filesystem. The ext4 filesystem
uses 4096 byte blocks whereas the disk uses 512 byte logical sectors. So 7903059...

This is a /boot partition. It may or may not be the correct one. It's worth taking a look at grub/grub.cfg.
Unfortunately, we still haven't found / or /home, tho.

ls /mnt

The error is because the size of the partition is too large for the size of the filesystem.

Doesn't look good. That partition looked like the most likely to be intact. Try the other two.

Now run

sudo fdisk -l /dev/sda
to confirm the MBR partition table is as we want.

Next, try to mount sda1 and see what it contains. It ought to look like /boot.

sudo mount /dev/sda1 /mnt

# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 280582, size= 1024000, Id=83
/dev/sda2 : start=118786048, size= 68059160, Id=83
/dev/sda3 : start=186845208, size= 63224472,...

Same mistake again - I copied the GPT partition size for sda2. The size of sda2 needs to be reduced as well.
The size of sda2 should be 68059160 to stop the overlap.

Or maybe 63224472. Or just something smaller until it works.

Oh, the total number of sectors is 250069680. I mistook 128GB for 128GiB.
Try a sda3 sector size of 63224473

Ok, the size of the last partition is too big for the size of the disk. I copied the size from the dodgy GPT table! The last sector on the disk is 268435455 so I reckon the size of sda3 should be no...

Try

sudo hdparm -z /dev/sda
before using sfdisk. This causes the kernel to re-read the disk partition table.

It may be that sfdisk now looks for the backup GPT table at the end of the disk. It has been a while since I've done this.
While I look this up, try writing the new MBR table to the disk.

Deleting the GPT header means there is no chance of using the GPT partition table to recover your data. I am assuming this doesn't work anyhow. Instead, we can create an equivalent MBR partition...

Then edit "mbrtable" to look like this:

# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 280582, size= 1024000, Id=83
/dev/sda2 : start=118786048, size=118317056, Id=83...

Oh yes. Delete the GPT header first.

sudo dd if=/dev/zero bs=512 count=1 seek=1 of=/dev/sda

Good. It is likely that either 118786048 or 186845208 are starts of usable linux ext4 partitions. Not sure why the former was 1 sector out in the GPT partition table. Anyhow, we can proceed to...

Ok, try this. This will show the byte values on the disk for 2048 bytes starting at the given sector. For example, for start sector 76255608:

sudo dd if=/dev/sda skip=76255608 bs=512 count=4 |...

I think these are potentially real partitions, although not all of them as some overlap!


GPT start end sectors size usage
1 2048 206847 ...

Would you post the output of

swapon -s
and then turn swap off

sudo swapoff -a

I am reading through this: https://help.ubuntu.com/community/DataRecovery

I am trying to figure out how to...

This is tricky. I think these three are probably real partitions:


start sector end sector sectors size use
2048 206847 204800 100.00 MiB ...

The challenge is to try to find where the original partitions started and ended. The only one that seems known is the 500MB linux.
Can you run testdisk on sda again and do a "deep search"?
See:...

Hi. Well it seems to me that you have inadvertently mangled the partition table of your disk. It doesn't look
good but it may be possible to do a manual reconstruction of the partition table.
...

Sort of normal. mdadm can create sub-partitions within a single md device. I have never used this "feature" and my brief experiments failed when trying to use normal tools to recognize the sub...