Description of problem: anaconda may leave a system unusable (not booting) when run on a system with mixed GPT/DOS disk labels. This prevents successful installation of Fedora 29 on these machines. Version-Release number of selected component (if applicable): anaconda used in Fedora-KDE-Live-x86_64-29-1.2.iso How reproducible: Run installer with a system previously run with F28 and try to boot into the freshly installed F29 system. Workaround: - install and boot plain F28 - upgrade by pointing dnf to F29 repositories. - cleanup .rpmnew files Steps to Reproduce: 1. start installer and configure storage layout 2. select boot manager installation 3. try to select the proper target disk from the disk list 4. proceed to storage layout configuration 5. try to proceed without a GPT BIOS boot partition Actual results: - The disk the BIOS will boot from is not selectable. - Installer insists on creating a GPT BIOS boot partition. - once the installers requirements are satisfied, installation works but rebooting the system fails with the BIOS finding no OS (if BIOS is instructed to boot from sda) or the old grub MBR not finding a valid stage2 (if BIOS is instructed from sde). Expected results: Let me select the disk the BIOS will actually boot from as target for the grub MBR and load stage 2 from the /boot partition on that disk specified in storage layout. Additional info: I found this on a system with GA-870A-UD3 mainboard with rev. F5 BIOS. There are 5 disks in the system with different DISK labels and technologies: sda: GPT (HDD) sdb: DOS (HDD) sdc: DOS (HDD) sdd: DOS (HDD) sde: DOS (SDD) sdf: --- (---) For significantly higher performance, the SSD must be connected as sde or sdf. The BIOS can be configured to legacy boot from any disk, in particular sde. Fedora 28 worked well on this configuration with a /boot partition on sde and grub installed to sde's MBR. Fedora 29 produces the following issues: - in anaconda's general storage configuration tab, sde is not selectable as target for grub MBR installation. Instead, sda is selected by default and all other choices (in particular sde the BIOS will boot from) are grayed out. - in storage layout configuration, installation will not proceed without a BIOS boot partition present (on sda) - though installation will then proceed and finish successfully, the system doesn't boot as the BIOS can not handle the GPT on sda and there is no valid MBR on sde.
The issue has been (partly) resolved: The actual method to select another than the default disk as MBR target: 1. select the target list (despite the gray-out indication) 2. press the 'choose as target' button. So the installer does allow to select other disks as grub MBR target, but in a misleading way that violates usual conventions of UI design: Disk targets are presented in a checklist, suggesting the boot loader may be installed to more than one target. In addition, this checklist is greyed out, suggesting no changes are possible. Reworking the dialog to adopt widely established UI design rules would aviod such confusions. E.g. using a radio button list not grayed out, a combo box or list and a OK/Abort button.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 EOL if it remains open with a Fedora 'version' of '29'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.