Bug 537155
Summary: | anaconda removes previous bootable flag: system unbootable after install | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gianluca Cecchi <gianluca.cecchi> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | anaconda-maint-list, apodtele, hdegoede, vanmeeuwen+fedora, vedran |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-11-17 12:15:53 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
Gianluca Cecchi
2009-11-12 17:05:53 UTC
Actually the presence of more partitions with bootable flag could be itself a problem. I tried the same with another PC where on sda1 there is Windows XP with its boot loader in MBR. I'm going to install F12 on sda2. Install completes, anaconda moves bootable flag from sda1 to sda2. I add bootable flag to sda1, so that now both partitions have the flag. PC is unable to boot. it gives the network pxe boot option....., as it wouldn't recognize the disk at all. After booting into rescue and set bootable flag only to sda1, PC is able to boot from Windows XP boot loader again. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Hi, I'm afraid there is nothing we can do to fix this, esp. not when installing to the boot sector of a partition instead of to the mbr. Parted agrees with you that only one bootable flag should be set, so when setting a bootable flag, the flag automatically gets cleared on any other partition which may have it. And when installing to the bootsector of a partition and assuming default mbr boot code (*), which will boot the first active partition, is present in the mbr, then we must set the active / bootable flag, otherwise one might very well end up with a not bootable system. The fact that the XP bootloader installs an mbr which does check the active flag, but then can only chainload itself and won't chainload grub, is a bug in the mbr written by the XP bootloader, not in Fedora. Either the Xp bootloader should install an mbr which does not care about the active flag (like grub does), or it should properly chainload the bootsector of the active partition. *) as written by dos for eons and as written by parted when creating a fresh mbr. ### As for warning about when selecting to install grub into a partition, normally you don't even get the choice! You explictly selected: 1) To configure disk yourself 2) To configure advanced bootloader options That seems plenty of warning that when you enter this path you are assumed to know what you are doing. ### As for warning that installing into the mbr may make your current / other os unbootable, well for normal systems it should not do that, I know we have an issue where we will point the other os / windows entry in grub.conf to the rescue partition, see bug 534066, which I acknowledge is a real bug and we are working on fixing this. Regards, Hans Fixed actually, see bug 533658 (In reply to comment #4) > Fixed actually, see bug 533658 Correct, further evaluation of this issue has lead to the conclusion that the removal of the active flag from an existing partition indeed is unwanted behavior. So I've just changed this, and for F-13 we will no longer do that, see: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=0c0559f6f187815521364cb6d5118ad9faf24cc9 Changing resolution of this bug to match. *** This bug has been marked as a duplicate of bug 533658 *** |