gparted freeze during NTFS partition resize

Question

As mentioned in the title, Gparted froze whilst in the middle of shifting an NTFS partition to the left and increasing it in size to fill the disk space to its right.

The last operation it was performing was moving sectors with a block size of 16Mb.

Is there any way I can get it to resume moving or manually do the rest of it? For an example of what I mean see this post: http://gparted-forum.surf4.info/viewtopic.php?pid=25907#p25907

EDIT: I've now discovered the following information:

• The exact sector at which the copy operation was interrupted is no. 2,529,216,511.
• According to the disk's MBR the partition's first sector is 202,390 MiB from the start of the disk and has a length of 1,705,337 MiB - which is what I was supposed to end up with.
• The extended BPB in the NTFS partition claims the size of the partition is 1,293,319 MiB. This is wrong and presumably should have been updated when the copying completed.

Solution

OK, so I finally fixed this!

This solution should also work for other filesystems if GParted does the same 'direct copy'. Obviously you'll need to use something other than chkdsk at the end.

Anyway, here's the procedure for solving the problem for the benefit of anyone who's as unlucky/stupid* as me:

1. Before you start, relax - go get yourself some coffee or a mug of hot chocolate!

   Your data is still on the disk, you just need to look for it. Spending time calmly checking things over won't harm you. Rushing and being impulsive might.

2. Read this through thoroughly and make sure you understand each step. If you then decide to follow these instructions it's probably a good idea to make a backup on a separate disk using dd. It's easy to make mistakes and a backup would give you a safety net.

3. Make sure you make a note of any information about the last thing GParted was doing. You'll want to know how far the copy operation got (as precise as possible) and how far backwards/forwards it was copying things.

4. Work out the exact location where the copy finished. I've written two Python scripts to help with this but they've only been tested on ubuntu (definitely won't work in Windows) and need modification for your specific case.

   • Firstly use this to find a single matching sector on the disk: findDuplicateSector.py

   • Then use this to find the last matching sector (i.e. where the operation was interrupted): findCopyInterruptLocation.py

   • Read the code and make sure you understand it. I've tested it briefly but there may be bugs. All numbers given are absolute offsets from the start of the partition/file, i.e. offset 0 is the first sector in the partition and offset n is the n+1^th sector.

5. Use dd or something similar to complete the copy operation, taking care not to get the input and output offsets confused. Here's the syntax for dd:

   sudo dd bs=512 skip=<input_offset> if=<partition> seek=<output_offset> of=<partition> count=<num_sectors_to_copy>
   

   This step will take a long time (it took me 8 hours). If you want to see how its progressing, run this in a separate terminal and dd will give you an update on its progress in its own terminal window:

   sudo kill -s USR1 <PID_of_dd>
   

6. Check the following and correct if necessary:

   • The Master Boot Record (MBR)'s partition table entries should match what you told GParted to do (see the wikipedia article, it's very informative). Specifically check the value for the LBA of the first sector of the partition and its total number of sectors.

   • The Partition Boot Record of the partition you're modifying should match MBR (in my case it didn't). For NTFS the total partition size in sectors should be at offset 40 from the start of the partition. I don't think NTFS records what the offset of the partition relative to the start of the disk is though.

7. Run chkdsk in read-only mode, i.e. with no command line arguments other than the drive name to check that it can find all the files in the partition. If it fails to verify the file indexes then DO NOT continue. Don't worry if it complains about the $Bitmap file containing errors.

8. If, and only if step 5 succeeded, run chkdsk /f to fix for example the $Bitmap file. If you run this while file indexes are still wrong it may end up deleting them, making things much more difficult for you.

9. You might want to run chkdsk in read-only mode again to make sure it worked, just for peace of mind.

_{*Actually I'm too arrogant - we're not stupid. But seriously - make backups!}

Comments

[randomperson1]

@Braiam - he lost his data and tried to recover it without modifying the original disk (as you pointed out with little success). He then followed the procedure in the post I mentioned and seems to have recovered all his data.

[Andrea Lazzarotto]

Awesome answer. To easily see the progress, one could use dcfldd with the same syntax.

[RecursiveCursive]

Hi, I had a similar issue with an ext4 partition, my live boot crashed when I was moving the partition to the left. When I try to find a matching sector at the start, it says that the first few sectors contains 0's and the first sector containing non-zero data doesn't match with anything. Do you have any idea, how that can be resolved? On a side note, shouldn't the partition name be /dev/sda since we are seeking to the start of the partition anyway?