Bug 740986
Summary: | Custom partitioning could warn the user that any GPT-labelled disk without a BIOS boot partition will not be bootable directly | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | anaconda-maint-list, camilo, jonathan, matthias, smithj, the.ridikulus.rat, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-14 00:52:58 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
Adam Williamson
2011-09-24 06:22:28 UTC
I think it's important to keep focus on the basics. I know there has been a tendency to make the installer simpler and more easy to use, which is a good thing. Also that the grub->grub2 and BIOS->UEFI/GPT change introduces complexity. But the basic feature of Anaconda, I think, is to make a system bootable. It is far too easy to make a system that will not boot and I think that shouldn't be acceptable. So if there is a redesign for F17 I hope that either * all the GPT grub placement issues are ironed out so it's guaranteed that BIOS boot partition + grub is flawlessly made without any user input, or * some check is added to Anaconda to ask the user how they plan to boot a system where it appears that there is deviation from the stuff that we know works. Ideally this would catch the naive user who is trying to custom partition but isn't aware of the need for a BIOS boot partition. There is an expectation that, if you choose custom partitioning, you should know what you're doing. 'Knowing what you're doing' is a quality that needs updating over time, as well. "all the GPT grub placement issues are ironed out so it's guaranteed that BIOS boot partition + grub is flawlessly made without any user input" may be convenient, but you asked for *manual* partitioning, so in a way, it's sort of wrong for anaconda to go around creating partitions for you... I was wondering this bug report is just dealing with the "custom partitioning" scheme as I experienced a very similiar problem with the F16 Beta when choosing the "Use whole disc" option in the installer without any manual partitioning. It seems like the BIOS boot partition is missing then and systems without EFI remain unbootable after the installation. Can anyone confirm this? matthias: there are various bugs that can look similar. did you have *another* disk connected to the machine in question? in Beta, that can cause the requirement for the BIOS boot partition to be (incorrectly) waived. generally, avoid testing Beta now, and get a Final RC instead, we have made many many changes in this area for Final and it ought to be more robust. http://dl.fedoraproject.org/pub/alt/stage/ (psst, psst: RC5 is actually F16 Final). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Adam, actually I did my tests with one of the latest nightly builds (I guess 5 days ago). As I booted the installer from an USB stick this was also recognized as a disc and presented as an optional installation target (which I did not choose). Anyway, I will repeat the install tomorrow with RC5. Thanks, Matthias Hi, regarding my previous posting: the installation with the "use whole disc" option ran perfectly with the RC5. Seems the problem disappeared. Thanks, Matthias 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. |