Bug 2088113 - Custom partitioning with 2 drives selected, bootloader fails to install due to one drive not having a BIOS Boot partition
Summary: Custom partitioning with 2 drives selected, bootloader fails to install due t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vendula Poncova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 2092116 (view as bug list)
Depends On:
Blocks: F37FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-05-18 17:59 UTC by Chris Murphy
Modified: 2022-11-04 01:41 UTC (History)
10 users (show)

Fixed In Version: anaconda-37.12.4-1 anaconda-37.12.5-1.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-24 00:15:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda.log (52.88 KB, text/plain)
2022-05-18 18:01 UTC, Chris Murphy
no flags Details
program.log (14.64 KB, text/plain)
2022-05-18 18:02 UTC, Chris Murphy
no flags Details
storage.log (816.43 KB, text/plain)
2022-05-18 18:02 UTC, Chris Murphy
no flags Details
screenshot of successful partitioning with recent F37 nightly (108.71 KB, image/png)
2022-10-11 08:45 UTC, Adam Williamson
no flags Details

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.

Comment 19 Peter Boy 2022-10-11 07:59:48 UTC
I just tested Fedora Server branch 20221009 (which is proposed as a test version) and unfortunately couldn't see any improvement. Either the fix didn't find its way into the Fedora Server Edition, or it doesn't work and does not fix the issue. The situation is still the same as described by Chris in the initial report or as described in #2088113 marked as a duplicate.

When you install Fedora Server on a biosboot System and choose "Custom" to install an SW Raid. 2 disk marked for installation, you can create 1 biosboot partition, but not specify the disk. You can't create a biosboot on the other disk. When you specify /boot and the LVM including the root FS, Anaconda complains at the end and advises  to create a second biosboot partition. But offers no way to do that.

The exact process to reproduce is described at https://pagure.io/fedora-server/issue/87 The only difference is, that a warning message appears, when you click "Done" after specifying the partitions, and not later during software installation.

An additional question is, how the 2 or more biosboot partitions get updated.

Comment 20 Adam Williamson 2022-10-11 08:45:12 UTC
Well, I was able to do it. See attached screenshot. This is how I did it:

1. Create /boot partition, set size, change type to RAID (RAID-1)
2. Create / partition, set size, change type to RAID (RAID-1)
3. Create biosboot partition, set size, click the "Modify..." button at top right under "Device(s):" and select *only* vda, click "Update Settings"
4. Create biosboot partition, set size, click the "Modify..." button at top right under "Device(s):" and select *only* vdb, click "Update Settings"

This resulted in the config shown in the screenshot - /boot and / as RAID-1, and two BIOS Boot partitions, one on each disk. With this config I am able to return to the hub with no errors, and start the system installation. The install has made it past partitioning and is now installing packages, so I think it's going to be OK.

Comment 21 Adam Williamson 2022-10-11 08:45:48 UTC
Created attachment 1917240 [details]
screenshot of successful partitioning with recent F37 nightly

Comment 22 Adam Williamson 2022-10-11 10:09:06 UTC
And indeed the system installed and booted OK. I am not sure of the answer to the "how do they get updated" question.

Comment 23 Peter Boy 2022-10-11 11:56:08 UTC
Well, I checked again and take it all back and say the opposite.

But I say instead, the GUI is not misleading at this point, but at least a bit irritating. If you first click on the Device item, both Disks are marked and trigger the assumption that both disks will be configured. There is no indicator that only one disk gets the partition, nor that you can select anything at all. But that's not an issue for now. When Anaconda gets the new GUI, we will hopefully get it fixed. 

How can we resolve the issue of the update? This is not directly part of this bug, but how can we clear it up?

Comment 24 Adam Williamson 2022-10-11 12:04:48 UTC
The UI is fun, but it's the same UI we've had all along and following all the same conventions. If you have more than one disk selected for a device that can't actually be spread across all of them (e.g. a RAID device), what that means is "anaconda will decide for you which disk this should go on".

Arguably there is still kind of a buglet here: in this specific situation, if you create two BIOSboot partitions and leave both disks selected for both of them, anaconda should arguably be smart enough to figure out that it should put one on each disk, not two on one disk. But I don't think that needs to be a blocker or anything.

For the update case, I guess chat about it with anaconda folks / Chris in IRC is what I'd do.

Comment 25 Peter Boy 2022-10-11 13:52:59 UTC
It's is definitely not a blocker, I agree. And I'll ask the Anaconda team when F37 is released.

Comment 26 Vendula Poncova 2022-10-14 09:27:20 UTC
Hi, I don't understand what do you mean by the update case. Could you be more specific, please?

Comment 27 Peter Boy 2022-10-14 10:58:02 UTC
Hi,

> I don't understand what do you mean by the update case.

I mean, if later after some time sysadmin uses dnf to update the system and an update includes some bootloader files, will every copy of BIOSboot partition (i.e. on every disk) gets the update automatically or has a sysadmin to take additional measures? And what happens when sysadmin has to reinstall grub? Do they have to do it for every drive themselves?

Sorry if the question seems too naive. I write the documentation for the Server Edition and want to provide reliable (and complete) information.

Comment 28 Chris Murphy 2022-10-14 15:41:47 UTC
>I mean, if later after some time sysadmin uses dnf to update the system and an update includes some bootloader files, will every copy of BIOSboot partition (i.e. on every disk) gets the update automatically or has a sysadmin to take additional measures?

Fedora never runs grub2-install on BIOS during system upgrades. All BIOSBoot get stale over time.

On UEFI only the mounted ESP is updated when shim and grub are updated. Additional ESPs become stale. (On rpm-ostree installations, it's up to bootupd to update any ESP. Historically it's also like BIOS in that the bootloader isn't updated.)

Comment 29 Chris Murphy 2022-11-02 20:56:32 UTC
Just tested Fedora-Server-dvd-x86_64-37_Beta-1.5.iso and make the following observations:

The Custom partitioning UI on the right-side under Devices show two vda and vdb selected for a single BIOSBoot. On the left-side under BIOSBoot it says vda1. So that's confusing. After I complete the layout with raid1 /boot and raid1 /, then circle back to Installation Destination to check out the bootloader configuration at the bottom of that page - it still won't let me select both devices.

And the installation still fails with a pop-up

>The following error occurred while installing the boot loader. The hsystem will not be bootable. Would you like to ignore this and continue wiht installation?

>boot loader install failed

Clicked on Yes. And I'll attach the logs....

Comment 30 Chris Murphy 2022-11-02 21:04:51 UTC
Good news. I did not follow the sequence in https://bugzilla.redhat.com/show_bug.cgi?id=2088113#c20

Instead I created BIOSBoot first. So that's probably why this failed. I'll try again before reopening.

Comment 31 Adam Williamson 2022-11-02 21:14:59 UTC
The key thing isn't (probably) the order, but the thing about manually ensuring you place one BIOS boot partition on each drive. If you just let anaconda pick which drive to put the BIOS boot partitions on, it will put them both on one drive.

Comment 32 Chris Murphy 2022-11-03 02:57:04 UTC
Comment 20, step 4 -> I do not get a second BIOSBoot. 

The exact clicks are:
+, biosboot, 2M, add mount point, click on the biosboot mount point that appears, devices>modify, vda, select, update settings, +, biosboot, 2M, add mount point...fail

At this point the first BIOSBoot vda1 is replaced by BIOSBoot vda2. But let's go with this anyway. Click on BIOSBoot, devices>modify, vdb, select, update settings.

I'm left with a single BIOSBoot, on vdb1. If I delete it, this single BIOSBoot on vdb1 changes to a single BIOSBoot on vda1. So it's as if there are two here, they just get merged or layered into a single mount point entry.

Fine, so keep them, and do an installation. The Summary dialog in fact shows two BIOSBoot, one on vda1 one on vdb1.

And it works: installer creates biosboot on each drive, and has grub2-install applied to both drives, and either drive can boot the system. It might be a good idea to commonbugs this due to the cosmetic UI weirdness because it's definitely not obvious.

Comment 33 Vendula Poncova 2022-11-03 17:07:01 UTC
I think that Fedora-Server-dvd-x86_64-37_Beta-1.5.iso doesn't contain the fixes (there is anaconda-37.12.2-2 on the iso). They were released after the Beta freeze.

Comment 34 Adam Williamson 2022-11-03 17:19:47 UTC
Haha, I didn't even notice that. Chris, were you really using a Beta-1.5 ISO not a Final RC one?

Comment 35 Chris Murphy 2022-11-04 00:49:09 UTC
Haha! Frack!
>Nov 02 22:31:07 fnuc.local libvirtd[12722]: Unable to remove disk metadata on vm fedora from /var/lib/libvirt/images/Fedora-Server-dvd-x86_64-37_Beta-1.5.iso (disk target sda)

Comment 36 Chris Murphy 2022-11-04 01:41:36 UTC
OK after acquiring the correct image, Fedora-Server-dvd-x86_64-37-1.6.iso and follow comment 20, I see two BIOSBoot and can place them each on separate drives, and the resulting installation post-install behaves otherwise as described in comment 32.


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