Hide Forgot
Description of problem: My F15 installation had grub installed on the partition and was chainloaded by another partition. After preupgrade to F16, grub2 is now installed on the MBR and I've lost access to my other OS installations. Version-Release number of selected component (if applicable): grub2-1.99-12.fc16.x86_64 How reproducible: 1 for 1 Steps to Reproduce: 1. Start with F15 installation chainloaded from another partition 2. Upgrade to F16 3. Actual results: grub2 now installed to MBR Expected results: grub2 installed to partition, just as grub1 was. Additional info: I know I can use the os-prober to add chainload entries for the other OS installs, that's not the point. The installation stepped outside of what it previously owned and effectively trashed a multi-boot setup.
Anaconda controls where it decides to install grub2. Reassigning.
I had a situation this week where grub overwrote the mbr on an windows disk, but because it was done assuming that grub is flawless. The result was that one could boot Fedora, but no longer boot Windows. Is it annaconda or grup that requires some enhancements. One which I am thinking and recommending is to Take a copy of the MBR that will be overwritten. If there is a need to undo a faulty choice that grub made, at least with a simple action, a repair can be done. Using a restore MBR command. Futunately I found a CD titled SUPERGRUB and it had a command to restore a Windows mbr. Even the author of this lifesaver CD recommended grub be improved upon to allow a MBR restore.
It it new grab2 time with Fedora 17 and Fedora 18. The problems I identified above no longer exist for me. grub2 does not modify the mbr, that is the role of anaconda. However, anaconda should backup the mbr to the /etc/grub directory, and allow grub2-mkconfig to restore the mbr. Ditto if the disk is formatted msdos or efi or whatever.
(In reply to comment #3) > grub2 does not modify the mbr, that is the role of anaconda. No, not exactly; grub2-install installs the bootloader in mbr ... but anaconda invokes grub2-install. > However, > anaconda should backup the mbr to the /etc/grub directory, and allow > grub2-mkconfig to restore the mbr. I consider it a good design decision that anaconda use external specialized tools for making the actual changes. Anaconda should not try to do something like this. It could perhaps make sense that grub2-install made a backup somewhere before actually writing to the sectors ... but there is no good place to place the backup and it could easily become outdated and dangerous to use. grub2-mkconfig will only modify grub.cfg - it will never install or touch the boot loader code. > Ditto if the disk is formatted msdos or efi or whatever. I assume you mean gpt, not efi. efi systems do not use mbr for booting, and Fedora on efi do not use grub2-install at all.
I have 4 different operating systems (3 different Linux and Windowss). You mentioned that grub2 will not be used with gpt. However, will the shim loader or what is coming be able to manage multi-boot? I already have a problem that Debian based on recent grub2 does not recognize Fedora and vice-versa, And mlink14 is not recognized by either. Sigh, 8 months ago, grub2 worked properly, listing all operating systems, permitting me to load the ones I required for my testing. For what I am doing, true non VM operation is desired.
(In reply to comment #5) > You mentioned that grub2 will not be used with gpt. No. I said that mbr and grub2-install not will be used on EFI systems. > I already have a problem that Debian based on recent grub2 does not > recognize Fedora and vice-versa That would be a different issue in grub2-mkconfig or os-prober.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.