This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 476413 - Resizing NTFS boot partition damages Windows boot?
Resizing NTFS boot partition damages Windows boot?
Product: Fedora
Classification: Fedora
Component: gparted (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Deji Akingunola
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-14 07:49 EST by Kurian John
Modified: 2009-12-18 02:17 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 02:17:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kurian John 2008-12-14 07:49:37 EST
Description of problem:
Resizing the NTFS boot parition on a Windows XP machine damages the Windows boot loader. GRUB installs properly to /dev/sda, and Linux boots fine. However, if the Windows option is selected from GRUB, a blank screen with a blinking cursor is seen. No error messages are shown.
The data in the resized disk appears to be intact, but windows cannot be booted.

Version-Release number of selected component (if applicable):
gparted 0.3.9
parted 1.8.8

How reproducible:
This can occur when a Windows XP boot partition is resized using gparted from the Fedora 10 livecd.

Steps to Reproduce:
1. Start Fedora 10 livecd
2. Resize boot parition using gparted to create space for the Fedora installation
3. Start installation
3. Install boot loader to /dev/sda
4. Complete install and reboot
Actual results:
Selecting the "Windows" option from the GRUB boot menu results in a blank screen. Booting does not progress.

Expected results:
User should be able to load the Windows OS successfully even after resize and install.
Comment 1 Deji Akingunola 2008-12-14 08:40:47 EST
Can you please run on the terminal (as root) '/sbin/fdisk -l /dev/sda', and report the output. Also attach or paste the content of your /boot/grub/grub.conf
Comment 2 Kurian John 2008-12-14 09:04:30 EST
This happened on my cousin's laptop and I've asked him to run the commands. 
From what I know, he has a single 150G hard drive, which initially had a single 150G NTFS partition. We used gparted to resize it to 100G and used the remaining 50G for Fedora. 

GRUB was installed to /dev/sda. When we noticed the Windows boot problem, we tried running ms-sys to fix the MBR, but we ended up with no GRUB and no windows, just a blinking cursor.

I'll post the outputs as soon as it's available... Thanks!
Comment 3 Kurian John 2008-12-14 19:43:04 EST
Disk Information
[root@shiFed]# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x89b3acc6

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       12764   102526798+   7  HPFS/NTFS
/dev/sda2           12765       19391    53231377+  83  Linux
/dev/sda3           19392       19456      522112+  82  Linux swap / Solaris

Contents of grub.conf
[root@shiFed]# cat /boot/grub/grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,1)
#          kernel /boot/vmlinuz-version ro root=/dev/sda2
#          initrd /boot/initrd-version.img
title Fedora (
    root (hd0,1)
    kernel /boot/vmlinuz- ro root=UUID=da758c3b-977e-461e-9786-40064cd15846 rhgb quiet
    initrd /boot/initrd-
title Fedora (
    root (hd0,1)
    kernel /boot/vmlinuz- ro root=UUID=da758c3b-977e-461e-9786-40064cd15846 rhgb quiet
    initrd /boot/initrd-
title WindowsXP
    rootnoverify (hd0,0)
    chainloader +1
Comment 4 Deji Akingunola 2008-12-14 21:12:34 EST
(In reply to comment #3)
> Disk Information
> ****************

Nothing jumps out at me as being wrong with your grub configuration, however I'm inclined to think this is rather a anaconda/grub bug. Gparted resizes from right to left of the partition table, and I don't know how that can affect the Windows boot loader.
Has you tried to re-installed the grub and attempt the windows' boot again? You will need a Fedora rescue disk to do that. Once on terminal (in rescue mode), run '/sbin/grub-install /dev/sda'. Let me know if you need further help booting into rescue mode.
Comment 5 Kurian John 2008-12-14 21:31:47 EST
I tried re-installing grub to /dev/sda, but that hasn't helped either.

The only out of ordinary procedure (as compared to a normal install) we followed was resizing the boot partition with gparted and that is why I suspected that it was a gparted issue.
Comment 6 Aaron Hamid 2009-04-24 17:41:14 EDT
Hi, was this ever solved or at least MBR restored?  I'd like to install F10 on my XP laptop, but I don't want to brick it.
Comment 7 Rogers W. Claggett 2009-07-21 00:30:21 EDT
I did a F11 DVD install (over F10) on a dual-boot, single drive XP laptop (ThinkPad T61). Results are as described above:
- F11 is fine
- XP hangs (blinking cursor only)

Some info referenced in comments above is listed below.  I mounted the two XP partitions before doing the "df" command.  I think /media/ServiceV002 contains the XP boot info.

I executed this command in since my /boot is mounted as /dev/sda3, not /dev/sda (didn't help):

  grub-install --root-directory=/ /dev/sda3

The only change was the grub stage2 file:

  diff ./pre-fix/stage2.strings ./stage2.strings
  < (hd0,2)/grub/grub.conf
  > /grub/grub.conf 

Still stuck and would appreciate help getting XP back!

----- some related info ----

[root]# /sbin/fdisk -l /dev/sda

Disk /dev/sda: 120.0 GB, 120034123776 bytes
240 heads, 63 sectors/track, 15505 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Disk identifier: 0xd746a2b1

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         907     6856888+  27  Unknown
/dev/sda2             908        7857    52542000    7  HPFS/NTFS
/dev/sda3            7858        7885      204800   83  Linux
/dev/sda4            7886       15505    57607200    5  Extended
/dev/sda5            7886       15505    57607168   8e  Linux LVM

[root]# df

Filesystem           1K-blocks      Used Available Use% Mounted on
                      54702524   2672916  51474524   5% /
/dev/sda3               197657     22265    165186  12% /boot
tmpfs                   501244       532    500712   1% /dev/shm
/dev/sda1              6856700   6108832    747868  90% /media/ServiceV002
/dev/sda2             52541996  39181692  13360304  75% /media/9A58587D58585A59

[root]# cat /boot/grub/grub.conf 

# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,2)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_gerry1nho-lv_root
#          initrd /initrd-version.img
title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=/dev/mapper/vg_gerry1nho-lv_root rhgb quiet
	initrd /initrd-
title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=/dev/mapper/vg_gerry1nho-lv_root rhgb quiet
	initrd /initrd-
title Windows
	rootnoverify (hd0,0)
	chainloader +1
Comment 8 Curtis Gedak 2009-10-20 17:02:48 EDT
Versions of GParted prior to 0.4.4 would many times move the partition start on a resize operation even if the start was not changed.  The details of this problem can be found in the following bug report:

The logic of GParted was reworked so that the resize/move dialog will only move the start sector of a partition IF the space before value is changed.

This problem was fixed in GParted 0.4.4.

Please not that if the start position of a boot partition is moved (by accident, or on purpose) then the user will need to take action to restore the proper boot code and configuration using the operating system boot disks, or other rescue disks.
Comment 9 Bug Zapper 2009-11-18 04:41:01 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:
Comment 10 Bug Zapper 2009-12-18 02:17:32 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.