# [SOLVED] Lost my partition table!!

## Emopig

I just attempted to move and resize a partition using GParted and everything seems to have gone fine except the partition table update and now GParted isn't recognizing *any* partitions on the drive.

http://andrew.nelless.net/gparted_details.htm

Please for the love of God tell me this can be fixed, i've investing too much time in my system for a seemingly trivial part (changing the partition table) of a tricky (resizing a ntfs filesystem) operations to mess it all up now.

I haven't rebooted yet.

----------

## elgato319

You can try to use gpart to rescue your partition table.

 *Quote:*   

> 
> 
> sys-block/gpart
> 
>      Available versions:  0.1h-r1
> ...

 

----------

## Emopig

gpart is masked as -amd64!

----------

## timeBandit

Have you exited GParted yet or is it still running? Does fdisk -l /dev/sda tell you the same thing GParted does (no partitions)?

----------

## Emopig

No fdisk returns a partition table but it is not correct and very confusing.

```
Disk /dev/sda: 300.0 GB, 300069052416 bytes

255 heads, 63 sectors/track, 36481 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *           1        3264    26218048+   7  HPFS/NTFS

/dev/sda2            3265        6528    26218080   83  Linux

/dev/sda4            9793       36481   214379392+   f  W95 Ext'd (LBA)

/dev/sda5           15016       20237    41945683+   7  HPFS/NTFS

/dev/sda6           23502       26112    20972826    7  HPFS/NTFS

/dev/sda7   ?        3442       38067   278124702+  e7  Unknown

Partition table entries are not in disk order
```

The output of testdisk /list seems to make a little more sense 

```

isk /dev/sda - 300 GB / 279 GiB - CHS 36481 255 63

Current partition structure:

     Partition                  Start        End    Size in sectors

 1 * HPFS - NTFS              0   1  1  3263 254 63   52436097 [Windows x64]

 2 P Linux                 3264   0  1  6527 254 63   52436160

 4 E extended LBA          9792   0  1 36480 254 63  428758785

 5 L HPFS - NTFS          15015   1  1 20236 254 63   83891367 [Software]

   X extended             23501   0  1 26111 254 63   41945715

 6 L HPFS - NTFS          23501   1  1 26111 254 63   41945652 [Music]

   X extended             29376   0  1 36480 254 63  114141825

test_logical:

Partition sector doesn't have the endmark 0xAA55
```

The last "X extended" line from testdisk looks vaguely like what my last partition was before i attempted to resize it but i can't be sure, are these numbers cylinders or what? This was the move I was attempting:

```
calculate new size and position of /dev/sda7  00:00    ( SUCCES )

        

requested start: 460230120

requested end: 586067264

requested size: 125837145 (60.00 GiB)

new start: 460230183

new end: 586067264

new size: 125837082 (60.00 GiB)
```

----------

## timeBandit

Actually those partitions tables (fdisk cf. testdisk) are in complete agreement except for sda7. fdisk cylinder numbering starts at 1, testdisk at 0--adjust for that and they match up. I have no personal experience with testdisk so I'm not sure what it's telling you with those double-listed partitions.

Do partitions sda1 through sda6 make sense? If yes, I'd consider using either tool to just fix sda7. If they're all wrong, I'm not sure what to recommend, because I would've suggested testdisk, and if it's giving you bad data I'm not sure what good news I can offer.

----------

## Emopig

OK timeBandit, I just noticed this too. 

The good news is I know the numbers for how to correct sda7 but I think it's in the wrong unit. 

From gparted's log:

```

new start: 460230183

new end: 586067264

*snip*

old start: 471925503

old end: 586067264
```

To me the output of testdisk /list seems to be correct for the pre-resized state of sda7 (there was a gap between Music and the next partition for expansion of Music):

```
 6 L HPFS - NTFS          23501   1  1 26111 254 63   41945652 [Music]

   X extended             29376   0  1 36480 254 63  114141825
```

Given that the music partition and it's previous extended partition are the same size i'm guessing the pre-resized size of sda7 was 29376-36480, which is a difference of 7104, the old size according to gparted was 586067264->471925503 which is a difference of 114141761. 114141761 divided by 7104 is 16068 which isn't a nice number so i'm still in the dark on how to map between the units or whether it's even possible.

All I know is the numbers from gparted seem be blocks of 512 kilobytes from a calculation using partition size.

```
ziggy Desktop # hdparm -g /dev/sda

/dev/sda:

 geometry     = 36481/255/63, sectors = 586072368, start = 0
```

----------

## Emopig

OK being a dumbass I found the option on fdisk to list in sectors instead of cyliners. So i guess i should erase the sda7 partition and recreate it.

But fdisk is giving me the following errors:

```
Warning: ignoring extra data in partition table 7

Warning: ignoring extra data in partition table 7

Warning: ignoring extra data in partition table 7

Warning: invalid flag 0xffffc318 of partition table 7 will be corrected by w(rite)
```

Which would explain where gparted found c318 :/

----------

## i92guboj

This saved my ass in the past a few times. There is an statically linked version, so you can use it from anywhere.

http://www.cgsecurity.org/wiki/TestDisk

----------

## Emopig

FIXED!

I corrected it manually using fdisk (you can switch the units with 'u') and rewrote my partition table using the numbers gparted said it was going to use. Everything is peachy and my ntfs hosted data seems to be intact.

Thank heavens and thank you all so much for rushing your attention my panicky flapping self  :Smile: 

Testdisk did actually prove better than fdisk at reading the existing partition table properly. I can't understand why gparted would have choked on such a simple part of the operation, presumeably because my partition table was corrupted to start with....

----------

## timeBandit

 *Emopig wrote:*   

> FIXED! 

 Great!

 *Emopig wrote:*   

> Given that the music partition and it's previous extended partition are the same size i'm guessing the pre-resized size of sda7 was 29376-36480, which is a difference of 7104, the old size according to gparted was 586067264->471925503 which is a difference of 114141761. 114141761 divided by 7104 is 16068 which isn't a nice number so i'm still in the dark on how to map between the units or whether it's even possible.

 I'll just answer this then: You were close, you just forgot to count the first cylinder of the partition. Panic probably affected your math.  :Smile: 

sda7 = 36480 - 29376 + 1 = 7105 cylinders. From fdisk:

```
255 heads, 63 sectors/track, 36481 cylinders 

Units = cylinders of 16065 * 512 = 8225280 bytes
```

(16065 = 255 * 63.) So the size would be 7105 * 16065 = 114141825 sectors. Gparted said sda7 used to end at sector 586067264, minus 114141825, plus 1 gives a starting sector of 471925440. (I subtracted from the end because that's the way you laid out the partition & grew it.)

This is off by 63 from what Gparted reported as the old start (471925503 - 471925440). According to your disk geometry, that's exactly one "track." The discrepancy means either your original partition didn't begin exactly on a cylinder boundary, or the last "track" of the last cylinder is inaccessible (quite possible), and these were cylinder-based calculations. It's easily cross-checked using Gparted's sector numbers:  (586067264 - 471925503) / 16065 = 7104.996. Clsoe enough.  :Smile: 

EDIT: Fixed my own off-by-one error.   :Laughing:  :Rolling Eyes: 

----------

## i92guboj

 *Emopig wrote:*   

> FIXED!
> 
> I corrected it manually using fdisk (you can switch the units with 'u') and rewrote my partition table using the numbers gparted said it was going to use. Everything is peachy and my ntfs hosted data seems to be intact.
> 
> 

 

Glad it's working, I would stay away from gparted and qtparted. They only brought problems. Regular parted of fdisk from command line are much more reliable.

 *Quote:*   

> Testdisk did actually prove better than fdisk at reading the existing partition table properly. I can't understand why gparted would have choked on such a simple part of the operation, presumeably because my partition table was corrupted to start with....

 

Testdisk is pretty solid. I have seen that program recover with a few keystrokes partition tables that were really really messed up. Of course, if you have enough info the manual method it always the best. But otherwise, testdisk was always a good solution for me.

Regards.

----------

## Emopig

6thpink:

Testdisk is definitely staying emerged. It was finding partitions I had long deleted, but that just impresses me more so  :Smile:  I think it'll be healthy for me to learn the command line parted.

The NTFS resize doesn't seem to have worked right anyway! According to Windows the partition is still it's original size of 54.4GB, whereas Linux reports it as 60 GB. I think I'll make a fresh ext3 file system of the same size, copy it all alove, and just blow NTFS away entirely. Quit while I'm ahead  :Wink: 

timeBandit:

Thanks for the explanation of the math, very educational  :Smile: 

----------

