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.
Created attachment 1881028 [details] anaconda.log
Created attachment 1881029 [details] program.log
Created attachment 1881030 [details] storage.log
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.
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)
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.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/822 , marking accepted.
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.
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.
*** Bug 2092116 has been marked as a duplicate of this bug. ***
(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.
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.
> 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.
FEDORA-2022-c20d42f3bc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c20d42f3bc
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.
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.
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.
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.
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.
Created attachment 1917240 [details] screenshot of successful partitioning with recent F37 nightly
And indeed the system installed and booted OK. I am not sure of the answer to the "how do they get updated" question.
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?
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.
It's is definitely not a blocker, I agree. And I'll ask the Anaconda team when F37 is released.
Hi, I don't understand what do you mean by the update case. Could you be more specific, please?
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.
>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.)
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....
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.
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 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.
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.
Haha, I didn't even notice that. Chris, were you really using a Beta-1.5 ISO not a Final RC one?
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)
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.