Bug 2088113

Summary: Custom partitioning with 2 drives selected, bootloader fails to install due to one drive not having a BIOS Boot partition
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: anacondaAssignee: Vendula Poncova <vponcova>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 37CC: anaconda-maint-list, awilliam, jonathan, kellin, pboy, robatino, sgallagh, vanmeeuwen+fedora, vponcova, w
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: anaconda-37.12.4-1 anaconda-37.12.5-1.fc37 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-24 00:15:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 2009539    
Attachments:
Description Flags
anaconda.log
none
program.log
none
storage.log none

Description Chris Murphy 2022-05-18 17:59:54 UTC
Description of problem:

Choosing 2 drives for installation in Custom partitioning. Upon adding a BIOS Boot partition, the right side manual partitioning UI shows 2 devices for this partition. But two BIOS Boots are not created by the installer. Subsequently, the installer issues grub2-install on both drives, but the second command fails because its target drive has no BIOS boot partition


Version-Release number of selected component (if applicable):
anaconda 36.16.5-1.fc36

How reproducible:
Always


Steps to Reproduce:
1. boot a VM with two virtual drives, and use inst.gpt parameter
2. choose both drives in installation destination, use Custom partitioning
3. create a BIOS Boot mount point, and notice on the right side both drives are selected for this by default implying each drive will get a BIOS Boot partition
4. proceed to create a /boot on raid1 with ext4 mount point, and a / on btrfs raid1

Actual results:

Installation fails with a bootloader related error

Expected results:

The installation should succeed

Additional info:


On installation destination page, click the bottom "link" to the bootloader configuration dialog, this dialog refuses to let me choose both drives for the bootloader. So there is an additional set of bugs here : (a) the dialog doesn't let me choose both (b) never the less the installer issues grub2-install on both drives anyway.

Comment 1 Chris Murphy 2022-05-18 18:01:42 UTC
Created attachment 1881028 [details]
anaconda.log

Comment 2 Chris Murphy 2022-05-18 18:02:01 UTC
Created attachment 1881029 [details]
program.log

Comment 3 Chris Murphy 2022-05-18 18:02:13 UTC
Created attachment 1881030 [details]
storage.log

Comment 4 Chris Murphy 2022-05-18 18:27:07 UTC
When I precreate BIOS Boot on the two drives, and then just ignore them (do not delete, do not create new) in manual partioning, the installation succeeds without error. grub2-install is pointed to each drive, and each drive has a BIOS Boot so this works.

/tmp/storage.log:INFO:program:Running in chroot '/mnt/sysroot'... grub2-install --no-floppy /dev/vda
/tmp/storage.log:INFO:program:Running in chroot '/mnt/sysroot'... grub2-install --no-floppy /dev/vdb
/tmp/storage.log:INFO:program:Running in chroot '/mnt/sysroot'... grub2-install --no-floppy /dev/vda
/tmp/storage.log:INFO:program:Running in chroot '/mnt/sysroot'... grub2-install --no-floppy /dev/vdb

Not sure why these commands are being run twice each though.

Comment 5 Peter Boy 2022-05-29 10:10:18 UTC
On a physical system using server 36 DVD you can use the advanced custom GUI to create a biosboot partition on each raid drive (raid1), create the /boot partition and a LVM containing root (both in a raid 1). The installation runs without error messages, but the system is unable to boot (Error: No boot disk has been detected)

Comment 6 Fedora Blocker Bugs Application 2022-06-06 00:16:26 UTC
Proposed as a Blocker for 37-final by Fedora user chrismurphy using the blocker tracking app because:

 There's a few violations:

The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. 
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Bootloader_disk_selection

The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. 
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Disk_layouts

A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles.
https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior


Custom allows me to create bootable raid1 setup with two disks, but (a) doesn't automatically create a 2nd BIOS Boot, (b) will not let me create one, (c) subsequently fails to complete the installation as a result of the first two, and (d) doesn't boot afterward.

Comment 7 Ben Cotton 2022-08-09 13:16:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 8 Adam Williamson 2022-08-22 16:07:04 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/822 , marking accepted.

Comment 9 Adam Williamson 2022-08-22 16:13:41 UTC
However, I wonder: why does this work in openQA?

https://openqa.fedoraproject.org/tests/1386628#step/disk_custom_software_raid/13

that's openQA doing its 'custom partitioning software RAID' test. It looks like we wind up with a BIOS boot partition on only one of the two disks, but anaconda accepts that, the install completes, and the installed system boots.

Comment 10 Adam Williamson 2022-08-22 16:15:40 UTC
Hmm, maybe it's because we don't raid /boot in that test? The way the openQA test works is, we go into Custom partitioning, hit the button to create partitions automatically, then change the root partition (but not /boot) to be RAID.

Comment 11 Adam Williamson 2022-08-22 16:21:48 UTC
*** Bug 2092116 has been marked as a duplicate of this bug. ***

Comment 12 Chris Murphy 2022-08-22 18:02:22 UTC
(In reply to Adam Williamson from comment #10)
> Hmm, maybe it's because we don't raid /boot in that test?

I guess anaconda/blivet might assume BIOSBoot goes on drives only if both have /boot via RAID? I will retest.

Comment 13 Chris Murphy 2022-08-22 19:29:11 UTC
Confirmed. If /boot is single device, the problem doesn't happen. Looking at the storage.log I see:

>storage.log:INFO:program:Running in chroot '/mnt/sysroot'... grub2-install --no-floppy /dev/vda

No error happens. And the setup is bootable.

It appears that the bug needs /boot to be at least raid1 (as tested, didn't test other raid levels) to trigger.

Comment 14 Vendula Poncova 2022-09-01 14:52:23 UTC
> 3. create a BIOS Boot mount point, and notice on the right side both drives are selected for this by default implying each drive will get a BIOS Boot partition

That means that Blivet considers both disks when it schedules a new mount point, but there will be effectively only one mount point created. We are investigating possible solutions, but at this moment, it is necessary to manually create two BIOS Boot mount points, one for each disk. There are two issues related to that.

First of all, we need to fix the bug that prevents to show multiple biosboot devices on the Manual Partitioning screen. That should be fixed by:
https://github.com/rhinstaller/anaconda/pull/4305

Then, we should verify that all installation targets have a biosboot partition when we run validation checks on the scheduled partitions. Users will be asked to create missing biosboot partitions on specific disks if required. That should be fixed by:
https://github.com/rhinstaller/anaconda/pull/4307

These changes shouldn't be too disruptive and could provide a sufficient workaround for Fedora 37. They were already released on rawhide in anaconda-38.3-1.fc38.

Comment 15 Fedora Update System 2022-09-13 18:09:41 UTC
FEDORA-2022-c20d42f3bc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c20d42f3bc

Comment 16 Fedora Update System 2022-09-14 01:52:38 UTC
FEDORA-2022-c20d42f3bc has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-c20d42f3bc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c20d42f3bc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2022-09-20 01:49:51 UTC
FEDORA-2022-68907aa5e8 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-68907aa5e8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-68907aa5e8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2022-09-24 00:15:59 UTC
FEDORA-2022-68907aa5e8 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.