Bug 476413
Summary: | Resizing NTFS boot partition damages Windows boot? | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kurian John <dtlabz> |
Component: | gparted | Assignee: | Deji Akingunola <dakingun> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | aaron.hamid, dakingun, gedakc, nick-bugzilla, rwc |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-18 07:17:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kurian John
2008-12-14 12:49:37 UTC
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 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! Disk Information **************** [root@shiFed 2.6.27.5-117.fc10.i686]# 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 2.6.27.5-117.fc10.i686]# 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 #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,1)/boot/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.27.7-134.fc10.i686) root (hd0,1) kernel /boot/vmlinuz-2.6.27.7-134.fc10.i686 ro root=UUID=da758c3b-977e-461e-9786-40064cd15846 rhgb quiet initrd /boot/initrd-2.6.27.7-134.fc10.i686.img title Fedora (2.6.27.5-117.fc10.i686) root (hd0,1) kernel /boot/vmlinuz-2.6.27.5-117.fc10.i686 ro root=UUID=da758c3b-977e-461e-9786-40064cd15846 rhgb quiet initrd /boot/initrd-2.6.27.5-117.fc10.i686.img title WindowsXP rootnoverify (hd0,0) chainloader +1 (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. 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. 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. 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 7c7 < (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 /dev/mapper/vg_gerry1nho-lv_root 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 #boot=/dev/sda #boot=/dev/sda3 default=0 timeout=60 splashimage=(hd0,2)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.29.5-191.fc11.i586) root (hd0,2) kernel /vmlinuz-2.6.29.5-191.fc11.i586 ro root=/dev/mapper/vg_gerry1nho-lv_root rhgb quiet initrd /initrd-2.6.29.5-191.fc11.i586.img title Fedora (2.6.29.4-167.fc11.i586) root (hd0,2) kernel /vmlinuz-2.6.29.4-167.fc11.i586 ro root=/dev/mapper/vg_gerry1nho-lv_root rhgb quiet initrd /initrd-2.6.29.4-167.fc11.i586.img title Windows rootnoverify (hd0,0) chainloader +1 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: https://bugzilla.gnome.org/show_bug.cgi?id=571151 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. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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. |