After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 379482 - move/resize ntfs partition containing Windows Vista makes Vista unbootable
move/resize ntfs partition containing Windows Vista makes Vista unbootable
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
0.3.1
Other All
: Normal blocker
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2006-11-26 15:44 UTC by Michael
Modified: 2010-04-29 11:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sda-512.hexdump (2.48 KB, text/plain)
2008-08-30 07:03 UTC, Emmanuel Galanos
Details
sda1-512.hexdump (2.48 KB, text/plain)
2008-08-30 07:03 UTC, Emmanuel Galanos
Details
sda-fdisk.txt (355 bytes, text/plain)
2008-08-30 07:03 UTC, Emmanuel Galanos
Details
sda-512-broken.hexdump (2.48 KB, text/plain)
2008-09-04 02:14 UTC, Emmanuel Galanos
Details
sda1-512-broken.hexdump (2.48 KB, text/plain)
2008-09-04 02:15 UTC, Emmanuel Galanos
Details
sda-fdisk-broken.txt (309 bytes, text/plain)
2008-09-04 02:18 UTC, Emmanuel Galanos
Details
gparted-diagnostics.tar.gz (624.95 KB, application/x-compressed-tar)
2008-09-10 22:54 UTC, Emmanuel Galanos
Details

Description Michael 2006-11-26 15:44:11 UTC
Please describe the problem:
move/resize ntfs partition containing Windows Vista makes Vista unbootable

Steps to reproduce:
1. move/resize ntfs partition 
2. boot fails with error
3. try to repair with Windows Vista installation disc fails as after initial boot screen nothing than a blank screen gets displayed

Actual results:
Windows Vista doesn't boot anymore and fails with error:

File: \Windows\system32\winload.exe 
Status: 0xc0000255
Info: The selected entry could not be loaded because the application is missing or corrupt.

Expected results:
Windows Vista boots successfully

Does this happen every time?
yes

Other information:
Comment 1 Michael 2006-11-26 15:52:58 UTC
HD: Samsung SP2504C SATA drive 

device properties:
hardwareID: SAMSUNG_SP2504C_________________________VT100-41

Motherboard chipset: NVIDIA nForce3 250 Serial ATA Controller

Comment 2 Ossi Mäntylahti 2007-06-13 05:46:34 UTC
I can confirm this at least with LiveCD. HDD had XP and Vista installed. XP worked after resize, Vista failed with the same executable (winloader).

This is rather fatal defect.
Comment 3 Laurent de Trogoff 2007-06-13 07:02:09 UTC
This version of the livecd is out of date !
BTW 0.3.1 doesnt support Vista file system, only 0.3.5 and higher
You'd better try the last release, and try to follow the doc I made about Vista :  http://gparted-forum.surf4.info/viewtopic.php?id=431
Comment 4 Marco 2007-09-06 03:47:42 UTC
Hello!

I just arrived here to comment this bug, and i found this one

My case is very very similar, i have 2 sata hard disks, one with linux and another one with vista

in vista i have c: (only for OS) and d: (files and everything)

from linux, i opened gparted and resized d: less 2 GB to add in c:, because i had low space in c: (vista complaining all the time, and comp slowing)

everything worked, but i can't load vista anymore, can't even reinstall with disk
(but i'll try re-installing vista in a diff comp with my hard disk and it should work)

the thing is, vista doesn't load, it goes to that bar that is loading vista and goes and goes, keeps going and freezing sometimes but it doesn't load

just to let you guys know
Comment 5 gg 2008-01-16 19:20:10 UTC
This is not a bug it's feature : death to Vista!

If you wish to retain at least some control over what your PC does install win2k.
Comment 6 Curtis Gedak 2008-04-22 19:51:24 UTC
Hello Michael, Ossi, and Marco,

Were you able to get your Vista partition to boot by using the Vista Installation DVD to repair the problem?

Some web surfing took me to this list of steps:
http://www.howtogeek.com/howto/windows-vista/using-gparted-to-resize-your-windows-vista-partition/


It appears that this Vista problem occurs with other Partition Editors as can be seen from the following articles:
http://channel9.msdn.com/ShowPost.aspx?PostID=277099
http://blog.danbartels.com/archive/2006/06/27/2663.aspx

These articles seem to point to a problem in the Vista registry with devices and/or drive letters.

I found this article regarding changing the drive letter on a boot device:
http://leghumped.com/blog/2007/01/09/change-drive-letter-on-a-boot-device/

This problem does not appear to occur every time because I have read posts from people that were able to resize the Vista boot partition with no problems.

Regards,
Curtis Gedak
Comment 7 Emmanuel Galanos 2008-06-29 14:47:43 UTC
I just hit this problem when using the GParted live CD 0.3.6 on a new Lenovo
laptop that came preinstalled with Vista business edition.

Vista became unbootable after attempting to shrink volume from 60 GB to 30GB.

The Lenovo "Rescue and Recovery" CD was unable to make the system bootable.

The laptop only came with the "Rescue and Recovery" CD and a full system
recovery DVD set that performs a full restore to factory default so I am
unable to test the Vista Installation DVD repair process.

Since I have no important data on the laptop at present, I am happy to help
with getting this problem fixed. Let me know what you need.
Comment 8 Curtis Gedak 2008-06-29 16:23:21 UTC
Sometimes the Vista recovery CD provided by manufacturers is not the same as the one provided when Vista is purchased directly from Microsoft.

From some googling, I found the following Vista recovery CD.

http://neosmart.net/blog/2008/windows-vista-recovery-disc-download/

I do not have Vista myself so I haven't used it personally.
Comment 9 Emmanuel Galanos 2008-06-30 12:50:19 UTC
Hi Curtis,

Thanks for the link.

Before I fix up the laptop and start actually using it, do you want me to
try any particular version of GParted or gather any useful diagnostic
information that will allow GParted to be properly fixed so as to
obviate a rescue/recovery after a resize ?
Comment 10 Curtis Gedak 2008-07-01 00:43:33 UTC
Thanks for the offer to collect additional information Emmanuel.

Unfortunately I don't know what information to collect.

For some people, after the resize of the Vista partitions there appears to be no problems.  For others, Vista will not boot until a rescue/recovery is performed.  If I could figure out what the difference was, then I may be able to guess at what additional information may be useful.  In the meantime I'm at a loss regarding this problem ;-(
Comment 11 Curtis Gedak 2008-08-26 23:31:33 UTC
I am still trying to solve this problem.

If anyone experiences this problem, would you please provide details from the following commands?

1)  Provide a hex dump of the first sector on the drive.
    E.g.,
         sudo hexdump -C -n 512 /dev/sda

2)  Provide a hex dump of the first sector of the NTFS partition.
    E.g.,
         sudo hexdump -C -n 512 /dev/sda1

Thanks in advance,
Curtis
Comment 12 Curtis Gedak 2008-08-26 23:32:39 UTC
Please also provide the output of:

    fdisk -l -u /dev/sda
Comment 13 Emmanuel Galanos 2008-08-30 07:02:25 UTC
I imaged (dd | nc) the hard disc of my laptop (after the use of the
recovery disc set) before partitioning and installing Linux.

Output of commands run against image attached.

If you need a live target to work on, I could transfer
the image across to you (though it is rather large) for
you to put into a VM.
Comment 14 Emmanuel Galanos 2008-08-30 07:03:08 UTC
Created attachment 117619 [details]
sda-512.hexdump
Comment 15 Emmanuel Galanos 2008-08-30 07:03:32 UTC
Created attachment 117620 [details]
sda1-512.hexdump
Comment 16 Emmanuel Galanos 2008-08-30 07:03:53 UTC
Created attachment 117621 [details]
sda-fdisk.txt
Comment 17 Curtis Gedak 2008-08-31 02:00:05 UTC
Thank you for this information Emmanuel.

If I understand comment #13 correctly, the hexdumps and fdisk output are from a working version of Vista.  This information is useful to me.

I still seek this same information from a Vista that does not boot due to resizing  or moving the partition.
Comment 18 Curtis Gedak 2008-08-31 02:03:50 UTC
From researching this problem, I have discovered a useful article on Vista boot problems.
http://support.microsoft.com/kb/927392


With versions of GParted prior to 0.3.8, there was a bug that incorrectly calculated disk cylinder alignment values.  This bug could cause a resize operation to also become a move operation (bug #432525).

If a move did occur, it is possible that the Vista Boot Configuration Data (BCD) might be invalidated due to the partition move.  My understanding of the Vista BCD is that contains much of the same information that the Windows XP boot.ini file contains.

Comment 19 Emmanuel Galanos 2008-09-04 02:14:01 UTC
(In reply to comment #17)
> Thank you for this information Emmanuel.
> 
> If I understand comment #13 correctly, the hexdumps and fdisk output are from a
> working version of Vista.  This information is useful to me.

Correct.
 
> I still seek this same information from a Vista that does not boot due to
> resizing  or moving the partition.

I imported by laptop disc image into a VMware VM (via nc and a Fedora
rescue CD). The VM booted normally (sans lots of expected driver problems).

I then resized it with the gparted live CD 0.3.8-9. Vista bootup failed
with the same message as reported on this bug report. hexdumps attached.
Comment 20 Emmanuel Galanos 2008-09-04 02:14:51 UTC
Created attachment 117976 [details]
sda-512-broken.hexdump

Vista not booting
Comment 21 Emmanuel Galanos 2008-09-04 02:15:18 UTC
Created attachment 117977 [details]
sda1-512-broken.hexdump

Vista not booting
Comment 22 Emmanuel Galanos 2008-09-04 02:18:07 UTC
Created attachment 117979 [details]
sda-fdisk-broken.txt

Vista not booting
Comment 23 Curtis Gedak 2008-09-04 18:29:35 UTC
Thank you Emmanuel, for collecting and posting this additional information.  :-)

It will take me some time to review the data to see if the problem lies in the boot sector area.
Comment 24 Curtis Gedak 2008-09-04 20:31:52 UTC
After comparing the good versus broken Vista files, it would appear that the only difference of significance is a possible error in the number of sectors in the volume.

Emmanuel, are you able to try hexediting the first sector of /dev/sda1 in the broken Vista to make a change?

If so could you change the 4 bytes at offset 0x0028
  from  68 a1 a9 03
    to  71 a1 a9 03

After writing the changes, try rebooting Vista to see if it works.

My initial thought is that this difference is too small to make a difference in whether Vista boots or not.


Research regarding the boot sectors follows ...

COMPARISON OF NTFS BOOT SECTORS
--------------------------------
Only two sections were found with differing hexadecimal values.

DIFFERENCE #1
The 4 bytes stored at 0x001C.  This is used for count of hidden physical sectors before the partition.

sda1-512.hexdump:        00 08 00 00 = 0x00000800 = 2048 decimal
                         => matches start sector 2048 in sda-fdisk.txt

sda1-512-broken.hexdump: 3f 00 00 00 = 0x0000003f = 63 decimal
                         => matches start sector 63 in sda-fdisk-broken.txt

DIFFERENCE #2
The 8 bytes stored at 0x0028.  This is used to store the total sectors in the volume.

sda1-512.hexdump:        af fa 73 07 00 00 00 00 = 0x000000000773faaf
                         = 125,041,327 sectors
                         => matches number of sectors in sda-fdisk.txt
                           125,041,327 sectors = 125,043,375 - 2048

sda1-512-broken.hexdump: 68 a1 a9 03 00 00 00 00 = 0x0000000003a9a168
                         =  61,448,552 sectors
                  *****  => does not match # of sectors in sda-fdisk-broken.txt
                            61,448,561 sectors = 61,448,624 - 63

COMPARISON OF MBR SECTORS
-------------------------
Only one section was found with differing hexadecimal values.  This was the 16 bytes stored at 0x01BE.  This is used for the first partition entry, and is the source of partition table information for fdisk.  Since the partition starting and ending sectors were different, it was expected that these 16 bytes would contain differences.

REFERENCES
----------
NFTS boot sector knowledge:
http://www.geocities.com/thestarman3/asm/mbr/NTFSBR.htm

Master Boot Record (MBR) knowledge:
http://en.wikipedia.org/wiki/Master_boot_record
Comment 25 Emmanuel Galanos 2008-09-05 12:47:41 UTC
(In reply to comment #24)
> After comparing the good versus broken Vista files, it would appear that the
> only difference of significance is a possible error in the number of sectors in
> the volume.
> 
> Emmanuel, are you able to try hexediting the first sector of /dev/sda1 in the
> broken Vista to make a change?
> 
> If so could you change the 4 bytes at offset 0x0028
>   from  68 a1 a9 03
>     to  71 a1 a9 03
> 
> After writing the changes, try rebooting Vista to see if it works.

I made the change and rebooted Vista. No improvement unfortunately.
Error message identical.

I'll try following the Bootrec.exe article from comment #18 and
gather further diagnostic information.
Comment 26 Curtis Gedak 2008-09-06 15:15:20 UTC
Thank you for trying out the hexedit suggestion.  I had a hunch that this small error would not be the cause of Vista's inability to boot.

Hopefully we will learn more if you have a chance to try out the bootrec.exe.

Comment 27 Emmanuel Galanos 2008-09-10 22:53:33 UTC
Using Bootrec.exe, the MBR and boot sector repair options did not allow
Vista to boot. The /RebuildBCD option allowed Vista to boot normally. I
only used the Bootrec.exe tool and did not allow the Vista recovery CD
to perform any automatic repair.

I have attached a tarball of the partition table printout, MBR, boot sector,
BCD, and BCD_Backup (using bcdedit /export) for the three states of original
system, post gparted live CD 0.3.8-9 operation (move left and shrink), and
post Vista recovery CD.
Comment 28 Emmanuel Galanos 2008-09-10 22:54:44 UTC
Created attachment 118484 [details]
gparted-diagnostics.tar.gz

Files relating to comment #27
Comment 29 Curtis Gedak 2008-09-12 23:07:56 UTC
Thank you again Emmanuel, for collecting and posting this additional information. 
:-)

It will take me some time to review the data.  I will post back here with what I learn.
Comment 30 Curtis Gedak 2008-09-22 16:52:33 UTC
There are some significant differences between the original and restored contents in gparted-diagnostics.tar.gz.

One of the most puzzling is that the fdisk output changed from 240 heads to 255 heads for the physical drive.

I know that the Cylinders/Heads/Sectors information is simulated on most modern drives and does not necessarily match the physical geometry.  Still, it is supposed to stay the same over the life of the drive.  I wonder what is causing this to happen?

When the number of heads changes, it changes the amount of information that is stored in a track, and hence changes the cylinder boundaries.

This is a mystery.
Comment 31 Johan Walles 2008-11-17 06:20:37 UTC
Can somebody please change the "Status" of this bug away from "Unconfirmed"?  It's obvious from the comments that it's a real problem...

Curtis, thanks for your link in comment #8, downloading now and will try out the rescue CD.
Comment 32 Johan Walles 2008-11-18 07:10:58 UTC
The ISO from http://neosmart.net/blog/2008/windows-vista-recovery-disc-download/ worked like a charm.

Note to anybody trying it: After "repairing" and re-booting, Vista's disk check seemed to get stuck in an infinite loop, printing the same message over and over again.  It did get out of it after a couple of minutes however, so if this happens to anybody else, please give it time.
Comment 33 Lee Parmeter 2009-01-30 15:49:52 UTC
I can confirm that this bug is still present in the 0.3.9 release. Upon a request to shrink a 185GB Vista ntfs partition, a move to the right was performed by gparted. After both operations were competed, Vista no longer booted with the unable to find "winboot.exe" error. I had to run 2 passes of the vista-recovery tool to get Vista to boot. The first time I ran it no partitions were detected. The 2nd time I ran it a ntfs partition was detected but it was set to 0 bytes. A automatic pop-up box appeared and asked for permission to fix the partition which I gladly responded with "OK". After this pass, Vista booted correctly.
Comment 34 Flávio Etrusco 2009-03-19 05:01:07 UTC
I know that when copying a partition (from one hard disk to another) Vista bootloader only works if you keep the original start sector of the partition.
Can't it be that it stores a fixed position/sector on the 1st stage (aka MBR) just like grub? (or maybe in the ESCD area)
Comment 35 Lumenos 2010-03-14 04:37:43 UTC
POSSIBLE EXPLANATION 

I hypothesize this problem is due to two new things about Vista:
 
1st: By "default" Vista uses a new 1-MiB alignment boundary. See https://secure.wikimedia.org/wikipedia/en/wiki/Logical_disk_manager#Compatibility_problems When GParted re-sizes this partition with the "round to cylinders" option checked, it moves the beginning of the partition to a "cylinder boundary" when it is only instructed to move the end of the partition. 

2nd: This changes the partitions offset and this will make the partition unbootable. "If either the signature or offset on the drive no longer match those that were written into an Object, then bootmgr will not be able to find the bootloader and so will give the error message that 'winload.exe.....is missing or corrupt'." http://www.multibooters.co.uk/bootmgr.html Unlike XP/2000, Vista's boot loader requires the start of the partition be in the same location. 

If someone would like to test this hypothesis, please try it with the "round to cylinders" option unchecked.

According to the author of http://www.multibooters.co.uk , many tools used to re-size or image partitions will move the start of the partition to a cylinder boundary and cause this same problem. See https://secure.wikimedia.org/wikipedia/en/wiki/Talk:Multi_boot#http:.2F.2Fwww.multibooters.co.uk.2Fpartitions.html
Comment 36 Lumenos 2010-03-14 05:37:39 UTC
(In reply to comment #30)
> There are some significant differences between the original and restored
> contents in gparted-diagnostics.tar.gz.
> 
> One of the most puzzling is that the fdisk output changed from 240 heads to 255
> heads for the physical drive.
> 
> I know that the Cylinders/Heads/Sectors information is simulated on most modern
> drives and does not necessarily match the physical geometry.  Still, it is
> supposed to stay the same over the life of the drive.  I wonder what is causing
> this to happen?
> 
> When the number of heads changes, it changes the amount of information that is
> stored in a track, and hence changes the cylinder boundaries.
> 
> This is a mystery.

You are sort of incorrect to think that the CHS is supposed to stay the same on the drive. Fdisk and Ranish Partition Manager will attempt to use the CHS alignment that is used in the partition table as opposed to one it may get from the drive's hardware or something (fdisk can get it from the kernel, I'm not sure where the kernel gets it). Fdisk will allow you to set any CHS alignment that you want and any "good" partition editor should detect and use the CHS alignment that you chose, so that your partition table uses the same cylinder/track boundaries for all partitions. 

In your case, fdisk may not have changed, what may have changed was your partition table. If you used different partition editors on your disk they may not have chosen the same alignment and thus caused fdisk to follow their alignment. I would think that they should choose the same alignment, so in that sense you are correct to say the alignment should stay the same. But Vista's and Windows 7's partitioners, completely ignore CHS alignments in favor of a 1 MiB alignment, so they could cause other partitioners to ("incorrectly") detect any sort of CHS alignment because there is no consistent CHS alignment to the partition table, at that point.

I hope to to make a Wikipedia article entitled "partition table alignment", to explain how to edit partition tables.
Comment 37 Curtis Gedak 2010-03-14 18:28:27 UTC
Thank you all for the additional information each of you have provided.

Moving the start sector of the partition does appear to cause Vista to not boot.

To address this problem, GParted 0.4.4 was the first version to include the following bug fix:

Bug #571151 - GParted moves partition start on resize even if start is unchanged

As such, the starting sector of a partition will not be changed if the start value is not changed, even with "Round to cylinders" selected.

This should address the problem of Vista not booting after a person chooses to resize (not move) the partition.

Of course a move will still have this problem, and this will require the user to perform a repair with the Vista install / repair media.


Can anyone confirm that a resize (not move) operation using the latest GParted version (currently 0.5.2) leaves Vista bootable?
Comment 38 Tobias Mueller 2010-04-29 11:01:43 UTC
Closing as FIXED as per last comment. Feel free to reopen if it's still an issue or to set to VERIFIED if it is indeed fixed.