In https://bugzilla.redhat.com/show_bug.cgi?id=738964 we dealt with the issue of bootloader installation for the non-custom install paths, mostly, but a few issues remain for the custom path. This is one of them. This will be overhauled for F17, I believe, but in F16, if you choose custom partitioning, the bootloader location selection screen comes well after partitioning is finalized. By the time you reach this screen, it's too late to realize you should have put a BIOS boot partition on the GPT-labelled target disk if you didn't do it already. anaconda won't let you out of the custom partitioning screen without a BIOS boot partition, but only if there's no other disk that might be a 'valid' location for the bootloader. If there is such a disk - even if it's one you're unlikely to want to use - anaconda won't warn you at all. It might be good if anaconda popped up a skippable warning (not a compulsory one, like in the case where there's no other disk) if you're about to leave the partitioning phase with a GPT-labelled disk with no BIOS boot partition. It could just say 'You will not be able to install the bootloader to the MBR of disk /dev/XXX unless you create a small (1MB) partition with the "BIOS Boot" type. Do you really wish to continue installation without such a partition?' or something similar (refer to the language in the other warning, I forget what we came up with in the end).
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.