Red Hat Bugzilla – Bug 539886
preupgrade of F11 to F12 has changed bootable flag from 1sth to 3thd partition
Last modified: 2014-01-21 18:12:27 EST
Description of problem: preupgrade of F11 to F12 has overwritten my boot sector. now I am unable to boot my windows partitions anymore! The previous GRUB boot sector belonged to the start of the partition on which the Fedora Linux has been installed leaving the original boot manager from Windows Vista on the boot sector of the primary first drive/partition.
Version-Release number of selected component (if applicable):
Currunt version now is preupgrade-1.1.3-1.fc12.noarch, however, this is the version from F12 that has replace the preupgrade version from F11 so I am unable to report which version that was in the first place.
How reproducible: Always when preupgrade on a system with grub installed on the linux partition instead of the primary boot sector on the first boot drive/partition.
Steps to Reproduce:
Actual results: System now happily boots only to Linux OS and I am unable to boot my windows partitions anymore
Expected results: Grub should have stayed on the boot sector of the linux partition (/dev/sda3) instead.
I am very disappointed about this and hope somebody is able to tell me shortly which steps I have to follow to restore my previous boot manager (nt) on the primary boot sector of the system so that my other OS's are available again.
From the Grub bootmanager, I am now able to boot the bootmgr from Vista. From the bootmgr of Vista I also am able to boot the Fedora partition (like it was before the preupgrade) back again.
Should I perform a "bootrec /FixBoot" from within Vista? So that my previous boot manager from Vista will be enabled again?
If so, will future updates to grub overwrite the primary bootsector again?
Here is my grub config:
# 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,2)
# kernel /boot/vmlinuz-version ro root=/dev/sda3
# initrd /boot/initrd-version.img
title Fedora (126.96.36.199-134.fc12.i686.PAE)
<------>kernel /boot/vmlinuz-188.8.131.52-134.fc12.i686.PAE ro root=LABEL=/ rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
title Fedora (184.108.40.206-127.fc12.i686)
<------>kernel /boot/vmlinuz-220.127.116.11-127.fc12.i686 ro root=LABEL=/ rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
title Fedora (18.104.22.168-127.fc12.i686.PAE)
<------>kernel /boot/vmlinuz-22.214.171.124-127.fc12.i686.PAE ro root=LABEL=/ rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
title Fedora (126.96.36.199-96.fc11.i586)
<------>kernel /boot/vmlinuz-188.8.131.52-96.fc11.i586 ro root=LABEL=/ rhgb quiet
title Fedora (184.108.40.206-90.fc11.i586)
<------>kernel /boot/vmlinuz-220.127.116.11-90.fc11.i586 ro root=LABEL=/ rhgb quiet
Eddie, let me see if I understand this correctly, after doing an upgrade from
F-11 to F-12, using pre-upgrade to download the installer and the necessary files,
your machine now no longer starts with the NT-bootloader, but instead starts with grub?
I have a hunch that this is the same issue as bug 533658, can you please run:
parted /dev/sda p
And then paste the output here ? Thanks.
Here is the output of "parted /dev/sda p":
Model: ATA ST3160815AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 41.9GB 41.9GB primary ntfs
2 41.9GB 83.9GB 41.9GB primary ntfs
3 83.9GB 122GB 37.7GB primary ext3 boot
4 122GB 160GB 38.4GB extended
5 122GB 123GB 1612MB logical linux-swap(v1) swap
6 123GB 160GB 36.8GB logical fat32
So I need to toggle the bootable flag back to number 1?
Yes, that will probably fix things, can you give that a try please ?
Ok, I set the bootable flag to partition Nr. 1. and it is solved now.
Thanks for testing. This means that this bug is a duplicate of bug
533658, which I'm happy to report has been fixed for F-13 (see bug 533658 for details).
*** This bug has been marked as a duplicate of bug 533658 ***