GNOME Bugzilla – Bug 379482
move/resize ntfs partition containing Windows Vista makes Vista unbootable
Last modified: 2010-04-29 11:01:43 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
Windows Vista doesn't boot anymore and fails with error:
Info: The selected entry could not be loaded because the application is missing or corrupt.
Windows Vista boots successfully
Does this happen every time?
HD: Samsung SP2504C SATA drive
Motherboard chipset: NVIDIA nForce3 250 Serial ATA Controller
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.
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
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
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.
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:
It appears that this Vista problem occurs with other Partition Editors as can be seen from the following articles:
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:
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.
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.
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.
I do not have Vista myself so I haven't used it personally.
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 ?
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 ;-(
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.
sudo hexdump -C -n 512 /dev/sda
2) Provide a hex dump of the first sector of the NTFS partition.
sudo hexdump -C -n 512 /dev/sda1
Thanks in advance,
Please also provide the output of:
fdisk -l -u /dev/sda
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.
Created attachment 117619 [details]
Created attachment 117620 [details]
Created attachment 117621 [details]
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.
From researching this problem, I have discovered a useful article on Vista boot problems.
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.
(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.
> 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.
Created attachment 117976 [details]
Vista not booting
Created attachment 117977 [details]
Vista not booting
Created attachment 117979 [details]
Vista not booting
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.
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.
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
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.
NFTS boot sector knowledge:
Master Boot Record (MBR) knowledge:
(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.
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.
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.
Created attachment 118484 [details]
Files relating to comment #27
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.
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.
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.
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.
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.
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)
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
(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.
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?
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.