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
Run installer with a system previously run with F28
and try to boot into the freshly installed F29 system.
- 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
- 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).
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.