Bug 1650119 - F29 installer leaves unusuable system
Summary: F29 installer leaves unusuable system
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 29
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-15 11:47 UTC by Steffen Seeger
Modified: 2019-11-27 19:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-11-27 19:55:29 UTC
Type: Bug

Attachments (Terms of Use)

Description Steffen Seeger 2018-11-15 11:47:55 UTC
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.

- 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.

Comment 1 Steffen Seeger 2018-11-15 14:07:12 UTC
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.

Comment 2 Ben Cotton 2019-10-31 20:30:19 UTC
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.

Comment 3 Ben Cotton 2019-11-27 19:55:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.