1 (edited by idoc 2009-12-18 11:16:51)

Topic: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

I attempted to resize a NTFS partition and it failed with the now well know bug. I though the new live cd was patched but apparently it is not.  Below is the log, I have reposted it as a new topic as requested.

GParted 0.5.0

Libparted 1.9.0

Move /dev/hda3 to the right and shrink it from 36.31 GiB to 25.13 GiB  01:08:41    ( ERROR ) 
     calibrate /dev/hda3  00:00:03    ( SUCCESS ) 
     path: /dev/hda3
start: 80148285
end: 156296384
size: 76148100 (36.31 GiB) 

calculate new size and position of /dev/hda3  00:00:01    ( SUCCESS ) 
     requested start: 103603185
requested end: 156296384
requested size: 52693200 (25.13 GiB) 
new start: 103603185
new end: 156296384
new size: 52693200 (25.13 GiB) 

check file system on /dev/hda3 for errors and (if possible) fix them  00:00:01    ( SUCCESS ) 
     ntfsresize -P -i -f -v /dev/hda3 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 38987825664 bytes (38988 MB)
Current device size: 38987827200 bytes (38988 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15330 MB (39.3%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 21893 MB 0
Multi-Record : 19477 MB 416
$MFTMirr : 19494 MB 1
Ordinary : 35248 MB 1745
You might resize at 15329005568 bytes or 15330 MB (freeing 23658 MB).
Please make a test run using both the -n and -s options before real resizing!



shrink file system  00:01:38    ( SUCCESS ) 
     run simulation  00:00:04    ( SUCCESS ) 
     ntfsresize -P --force /dev/hda3 -s 26978918399 --no-action 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 38987825664 bytes (38988 MB)
Current device size: 38987827200 bytes (38988 MB)
New volume size : 26978910720 bytes (26979 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15330 MB (39.3%)
Collecting resizing constraints ...
Needed relocations : 178662 (732 MB)
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
The read-only test run ended successfully.



real resize  00:01:34    ( SUCCESS ) 
     ntfsresize -P --force /dev/hda3 -s 26978918399 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 38987825664 bytes (38988 MB)
Current device size: 38987827200 bytes (38988 MB)
New volume size : 26978910720 bytes (26979 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15330 MB (39.3%)
Collecting resizing constraints ...
Needed relocations : 178662 (732 MB)
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/hda3'.
You can go on to shrink the device for example with Linux fdisk.
IMPORTANT: When recreating the partition, make sure that you
1) create it at the same disk sector (use sector as the unit!)
2) create it with the same partition type (usually 7, HPFS/NTFS)
3) do not make it smaller than the new NTFS filesystem size
4) set the bootable flag for the partition if it existed before
Otherwise you won't be able to access NTFS or can't boot from the disk!
If you make a mistake and don't have a partition table backup then you
can recover the partition table by TestDisk or Parted's rescue mode.




shrink partition from 36.31 GiB to 25.13 GiB  00:00:01    ( SUCCESS ) 
     old start: 80148285
old end: 156296384
old size: 76148100 (36.31 GiB) 
new start: 80148285
new end: 132841484
new size: 52693200 (25.13 GiB) 

check file system on /dev/hda3 for errors and (if possible) fix them  00:00:01    ( SUCCESS ) 
     ntfsresize -P -i -f -v /dev/hda3 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26978910720 bytes (26979 MB)
Current device size: 38987827200 bytes (38988 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15329 MB (56.8%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 21893 MB 0
Multi-Record : 19477 MB 416
$MFTMirr : 19494 MB 1
Ordinary : 20322 MB 1745
You might resize at 15328641024 bytes or 15329 MB (freeing 11650 MB).
Please make a test run using both the -n and -s options before real resizing!



grow file system to fill the partition  00:00:04    ( SUCCESS ) 
     run simulation  00:00:03    ( SUCCESS ) 
     ntfsresize -P --force /dev/hda3 --no-action 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26978910720 bytes (26979 MB)
Current device size: 38987827200 bytes (38988 MB)
New volume size : 38987821568 bytes (38988 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15329 MB (56.8%)
Collecting resizing constraints ...
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
The read-only test run ended successfully.



real resize  00:00:01    ( SUCCESS ) 
     ntfsresize -P --force /dev/hda3 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26978910720 bytes (26979 MB)
Current device size: 38987827200 bytes (38988 MB)
New volume size : 38987821568 bytes (38988 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15329 MB (56.8%)
Collecting resizing constraints ...
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/hda3'.




calculate new size and position of /dev/hda3  00:00:01    ( SUCCESS ) 
     requested start: 103603185
requested end: 156296384
requested size: 52693200 (25.13 GiB) 
new start: 103603185
new end: 156296384
new size: 52693200 (25.13 GiB) 

check file system on /dev/hda3 for errors and (if possible) fix them  00:00:01    ( SUCCESS ) 
     ntfsresize -P -i -f -v /dev/hda3 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 38987821568 bytes (38988 MB)
Current device size: 38987827200 bytes (38988 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 15330 MB (39.3%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 21893 MB 0
Multi-Record : 19477 MB 416
$MFTMirr : 19494 MB 1
Ordinary : 20322 MB 1745
You might resize at 15329005568 bytes or 15330 MB (freeing 23658 MB).
Please make a test run using both the -n and -s options before real resizing!



move file system to the right  01:06:48    ( SUCCESS ) 
     perform read-only test  00:20:23    ( SUCCESS ) 
     using internal algorithm 
read 52693200 sectors 
finding optimal blocksize 
     read 65536 sectors using a blocksize of 128 sectors  00:00:03    ( SUCCESS ) 
     65536 of 65536 read 
3.27186 seconds 

read 65536 sectors using a blocksize of 256 sectors  00:00:03    ( SUCCESS ) 
     65536 of 65536 read 
2.87146 seconds 

read 65536 sectors using a blocksize of 512 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
2.20214 seconds 

read 65536 sectors using a blocksize of 1024 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
2.24713 seconds 

read 65536 sectors using a blocksize of 2048 sectors  00:00:03    ( SUCCESS ) 
     65536 of 65536 read 
2.57334 seconds 

read 65536 sectors using a blocksize of 4096 sectors  00:00:03    ( SUCCESS ) 
     65536 of 65536 read 
2.72122 seconds 

read 65536 sectors using a blocksize of 8192 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
2.37375 seconds 

read 65536 sectors using a blocksize of 16384 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
2.2495 seconds 

read 65536 sectors using a blocksize of 32768 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
1.91634 seconds 

read 65536 sectors using a blocksize of 65536 sectors  00:00:02    ( SUCCESS ) 
     65536 of 65536 read 
1.87684 seconds 

optimal blocksize is 65536 sectors (32.00 MiB) 

read 52037840 sectors using a blocksize of 65536 sectors  00:19:59    ( SUCCESS ) 
     52037840 of 52037840 read 

52693200 sectors read 

perform real move  00:46:25    ( SUCCESS ) 
     using internal algorithm 
copy 52693200 sectors 
finding optimal blocksize 
     copy 65536 sectors using a blocksize of 64 sectors  00:00:07    ( SUCCESS ) 
     65536 of 65536 copied 
7.43551 seconds 

copy 65536 sectors using a blocksize of 128 sectors  00:00:07    ( SUCCESS ) 
     65536 of 65536 copied 
6.69612 seconds 

copy 65536 sectors using a blocksize of 256 sectors  00:00:07    ( SUCCESS ) 
     65536 of 65536 copied 
7.02595 seconds 

copy 65536 sectors using a blocksize of 512 sectors  00:00:07    ( SUCCESS ) 
     65536 of 65536 copied 
6.79999 seconds 

copy 65536 sectors using a blocksize of 1024 sectors  00:00:07    ( SUCCESS ) 
     65536 of 65536 copied 
7.04899 seconds 

copy 65536 sectors using a blocksize of 2048 sectors  00:00:06    ( SUCCESS ) 
     65536 of 65536 copied 
5.87084 seconds 

copy 65536 sectors using a blocksize of 4096 sectors  00:00:05    ( SUCCESS ) 
     65536 of 65536 copied 
5.48953 seconds 

copy 65536 sectors using a blocksize of 8192 sectors  00:00:06    ( SUCCESS ) 
     65536 of 65536 copied 
5.32998 seconds 

copy 65536 sectors using a blocksize of 16384 sectors  00:00:04    ( SUCCESS ) 
     65536 of 65536 copied 
4.66536 seconds 

copy 65536 sectors using a blocksize of 32768 sectors  00:00:05    ( SUCCESS ) 
     65536 of 65536 copied 
4.30795 seconds 

copy 65536 sectors using a blocksize of 65536 sectors  00:00:04    ( SUCCESS ) 
     65536 of 65536 copied 
4.05939 seconds 

optimal blocksize is 65536 sectors (32.00 MiB) 

copy 51972304 sectors using a blocksize of 65536 sectors  00:45:20    ( SUCCESS ) 
     51972304 of 51972304 copied 

52693200 sectors copied 


move partition to the right  00:00:01    ( SUCCESS ) 
     old start: 80148285
old end: 132841484
old size: 52693200 (25.13 GiB) 
new start: 103603185
new end: 156296384
new size: 52693200 (25.13 GiB) 

update boot sector of ntfs file system on /dev/hda3  00:00:00    ( SUCCESS ) 
check file system on /dev/hda3 for errors and (if possible) fix them  00:00:01    ( ERROR ) 
     ntfsresize -P -i -f -v /dev/hda3 
     ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda3
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 38987821568 bytes (38988 MB)
Current device size: 26978918400 bytes (26979 MB)
ERROR: Current NTFS volume size is bigger than the device size!
Corrupt partition table or incorrect device partitioning?



libparted messages    ( INFO ) 
     The kernel was unable to re-read the partition table on /dev/hda (Device or resource busy). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/hda. 



========================================

Grow /dev/hda2 from 35.09 GiB to 46.28 GiB 

========================================

OUTPUT OF REQUESTED  fdisk -l -u and parted

Disk /dev/hda 80.0 GB 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units + sectors of 1 * 512 = 512 bytes
Disk identifier: 0x34fe34fd
    Device Boot             Start                     End                    Blocks          Id      System
/dev/hda1                         63           6554519                3277228+        12     Compaq diagnostics
/dev/hda2  *             654520          80148284             36796882+          7     HPFS/NTFS
/dev/hda3            103603185       156296384             26346600            7     HPFS/NTFS

2

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

parted output for above post

http://www.freeimagehosting.net/uploads/th.6b02c7dd66.jpg

3

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

Thank you idoc for the detailed report and creating a new post.  I will delete the previous post entries.  smile

idoc wrote:

I attempted to resize a NTFS partition and it failed with the now well know bug. I thought the new live cd was patched but apparently it is not.

We thought it was fixed too.  The new Live CD does contain a patched version of parted-1.9.0.
Unfortunately there appears to be something else that also causes this problem.  It is more random in nature and does not occur on every resize operation and is proving difficult to find.
This new problem is being tracked in the following bug report:
Bug 604298 -  Problems resizing file systems with gparted-live-0.5.0-3

Now on to solving your problem.


You can capture the Master Boot Record in a file with the following command:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda-idoc.mbr bs=512 count=1

where hda-idoc.mbr is the name of the file that will need to be uploaded.


You can capture the NTFS Partition Boot Records in files with the following commands:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda2-idoc.pbr bs=512 count=1 skip=654520

where hda2-idoc.pbr is the name of the file that will need to be uploaded.

dd if=/dev/hda of=hda3-idoc.pbr bs=512 count=1 skip=103603185

where hda3-idoc.pbr is the name of the file that will need to be uploaded.


Then upload these files to a media sharing site, such as mediafire, and post the link to these files in this forum post.

4

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

Testdisk quickscan

http://i.imagehost.org/t/0146/Testdisk_Quickscan.jpg
http://i.imagehost.org/t/0963/quicksearch.jpg

Can somone offer help recovering files?

If a do a deeper search I can list the files in the directory, but if I hit continue testdisk gives me an invalid partition structure error.

5

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

just saw your post above, working on a small screen!! I will post the files and await your reply thanks!

6

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

To recover ALL of your data we will need the data outlined in post 3.
Do not apply any changes from testdisk.

7

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

Here are links to the files you requested
http://www.mediafire.com/?zky5id0oxd5
http://www.mediafire.com/?mnfynz5q2zz
http://www.mediafire.com/?gkdtnx2mmmk

gedakc wrote:

Thank you idoc for the detailed report and creating a new post.  I will delete the previous post entries.  smile

idoc wrote:

I attempted to resize a NTFS partition and it failed with the now well know bug. I thought the new live cd was patched but apparently it is not.

We thought it was fixed too.  The new Live CD does contain a patched version of parted-1.9.0.
Unfortunately there appears to be something else that also causes this problem.  It is more random in nature and does not occur on every resize operation and is proving difficult to find.
This new problem is being tracked in the following bug report:
Bug 604298 -  Problems resizing file systems with gparted-live-0.5.0-3

Now on to solving your problem.


You can capture the Master Boot Record in a file with the following command:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda-idoc.mbr bs=512 count=1

where hda-idoc.mbr is the name of the file that will need to be uploaded.


You can capture the NTFS Partition Boot Records in files with the following commands:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda2-idoc.pbr bs=512 count=1 skip=654520

where hda2-idoc.pbr is the name of the file that will need to be uploaded.

dd if=/dev/hda of=hda3-idoc.pbr bs=512 count=1 skip=103603185

where hda3-idoc.pbr is the name of the file that will need to be uploaded.


Then upload these files to a media sharing site, such as mediafire, and post the link to these files in this forum post.

8

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

Question about testdisk, I can  get to the damaged partition with testdisk, I believe testdisk allows me to copy the files without altering the disk to another disk or storage device, do you recommend this, have you used this before applying the repair ??

9

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

"the repair" I am refering to in the above post is not testdisk repair but  the repair instructions I am awaiting from you.

10

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

"The repair" should completely fix the problem with no loss of data whatsoever.

Of course it is always prudent to have a backup.  smile


NOTE:  The file for hda2-idoc.pbr does not look like the NTFS Partition Boot Record.

From the MBR file you provided, I can see that the second partition starts at 6,554,520 and not at 654,520 as stated at the end of the first post.

As such we will need the correct copy of the NTFS PBR for partition 2.

You can capture the NTFS Partition Boot Record in a file with the following command:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda2-idoc-2ndtry.pbr bs=512 count=1 skip=6554520

where hda2-idoc-2ndtry.pbr is the name of the file that will need to be uploaded.

11

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

Thanks I will get that right to you. BTW I can boot and access windows (on the second partition) the first NTFS partiton, the first partiton is fat32 Pqservice OEM restore partiton put there by acer, the third partiton (acerdata) is the one I was trying to shrink and the one I can't access.

12

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

File as requested
http://www.mediafire.com/?myf0yrmmtnu

awating instructions.


gedakc wrote:

"The repair" should completely fix the problem with no loss of data whatsoever.

Of course it is always prudent to have a backup.  smile


NOTE:  The file for hda2-idoc.pbr does not look like the NTFS Partition Boot Record.

From the MBR file you provided, I can see that the second partition starts at 6,554,520 and not at 654,520 as stated at the end of the first post.

As such we will need the correct copy of the NTFS PBR for partition 2.

You can capture the NTFS Partition Boot Record in a file with the following command:

NOTE:  Be extra careful to type this command in properly, otherwise loss of data could result.

dd if=/dev/hda of=hda2-idoc-2ndtry.pbr bs=512 count=1 skip=6554520

where hda2-idoc-2ndtry.pbr is the name of the file that will need to be uploaded.

13

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

From the files provided I have been able to determine the following:

There is no problem with partition 2.
73,593,764 sectors in size for the NTFS volume which fits perfectly inside partition 2.
73,593,765 sectors in size for partition 2 (hda2).

However, there is a problem with partition 3:
76,148,088 sectors in size for the NTFS volume.
52,693,200 sectors in size for partition 3 (hda3)

To fix this problem we can decrease the NTFS volume size to fit within the partition.

The change I have made to the file is from a length of 76,148,088 sectors:
00000020   00 00 00 00  80 00 80 00  78 ED 89 04  00 00 00 00
To a new length of 52,693,199 sectors:
00000020   00 00 00 00  80 00 80 00  CF 08 24 03  00 00 00 00

Note:  The NTFS volume size is always 1 sector less than the total number of sectors in the partition table entry because the NTFS backup sector is not considered part of the NTFS volume.

To apply this change:

1) Download the new NTFS PBR: hda3-idoc_new.pbr

2) Load the new NTFS PBR on your hard disk.
NOTE:  Be extra careful when entering the commands.  Data loss could result otherwise.

dd if=hda3-idoc_new.pbr of=/dev/hda bs=512 count=1 seek=103603185

3) Reboot the computer

4) Check that the file system is recognized in GParted

5) If all seems fine then I would advise booting into Windows and running "chkdsk /f /r" multiple times, until there are no more faults.

14

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

The drive is now working and all partitions are accessable.  I still need to grow partiton 2 to use the unpartitioned space.  Is it safe to do this, should I use Parted Magic or an earlier version of gparted live?? what is the best solution for now?

Thank you for the help repairing my partitons.

gedakc wrote:

From the files provided I have been able to determine the following:

There is no problem with partition 2.
73,593,764 sectors in size for the NTFS volume which fits perfectly inside partition 2.
73,593,765 sectors in size for partition 2 (hda2).

However, there is a problem with partition 3:
76,148,088 sectors in size for the NTFS volume.
52,693,200 sectors in size for partition 3 (hda3)

To fix this problem we can decrease the NTFS volume size to fit within the partition.

The change I have made to the file is from a length of 76,148,088 sectors:
00000020   00 00 00 00  80 00 80 00  78 ED 89 04  00 00 00 00
To a new length of 52,693,199 sectors:
00000020   00 00 00 00  80 00 80 00  CF 08 24 03  00 00 00 00

Note:  The NTFS volume size is always 1 sector less than the total number of sectors in the partition table entry because the NTFS backup sector is not considered part of the NTFS volume.

To apply this change:

1) Download the new NTFS PBR: hda3-idoc_new.pbr

2) Load the new NTFS PBR on your hard disk.
NOTE:  Be extra careful when entering the commands.  Data loss could result otherwise.

dd if=hda3-idoc_new.pbr of=/dev/hda bs=512 count=1 seek=103603185

3) Reboot the computer

4) Check that the file system is recognized in GParted

5) If all seems fine then I would advise booting into Windows and running "chkdsk /f /r" multiple times, until there are no more faults.

15

Re: (SOLVED)Problem Resizing NTFS with new live 5.03 disk

I am glad to hear that all is now well with your system.  smile

To aid other users searching for solutions to topics such as this, it is useful to prefix "SOLVED" in the title of this thread.  To do this you just edit the first post and add "SOLVED" to the beginning of the title.

As for which version of GParted to use, please see the following post which is tracking this problem:
WARNING! Problem Resizing File Systems with GParted