RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2079710 - biosboot partition not installed on all disks as specified
Summary: biosboot partition not installed on all disks as specified
Keywords:
Status: CLOSED DUPLICATE of bug 1913035
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: anaconda
Version: CentOS Stream
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-28 07:07 UTC by Marc Dequènes (Duck)
Modified: 2022-05-12 16:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-12 15:53:52 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-120302 0 None None None 2022-04-28 07:18:06 UTC

Description Marc Dequènes (Duck) 2022-04-28 07:07:05 UTC 
Description of problem:
I'm installing a new server using Stream 9. Cince it switches to GPT by default I add a biosboot partition of 1MB as suggested. The machine has 10 disks and uses software RAID + LVM and I want it is be able to boot on any disks. /boot is in RAID1 on all disks, then / and swap on RAID10 + LVM.

Partitioning and installation works but installing the boot loader fails. The logs shows grub2-install complains that a BIOS boto partition is missing and embedding is not possible. On tty2 running lsblk shows that the bios boot partition is only created on the first disk.

I tried wiping the disk and starting afresh (it was initially blank disks) and I checked that the list of associated devices for the bios boot partition had all disks selected and that is the case,

Nevertheless I noted that the "full disk summary and boot loader…" page only allowed to select a single disk. The "Summary of changes" before the final partitioning validation also only contains the bios boot partition creation for the first disk.

On EL8 I was able to install a similar server but since GPT was not used there was no need for a bios boot partition. Now on EL9 this kind of configuration has become impossible out of the box.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. on a server with multiple disks select custom partitioning
2. add a bios grub partition on all disks
3. add /boot on RAID 1 on all disks
4. add / and swap on LVM + RAID 10 on all disks
5. start install

Actual results:
bios grub partition only installed on first disk and grub installation fails

Expected results:
grub installation succeed and able to boot into new system

Additional info:
Comment 1 Marc Dequènes (Duck) 2022-04-28 07:57:22 UTC 
We wanted to test EL9 with UEFI, good opportunity, so I switched to UEFI boot mode and retried the installation using /boot/efi instead of the bios boot partition.

First, the installer forces me to create a separate /boot, which is not needed in that case, but that's not a big deal.

Then the installer tells me: « boot loader stage 2 device boot is on a multi-disk array, but boot loader stage 1 device is not. A drive failure in boot could render the system unbootable. »

So I'm back to the same situation but at least the installer tells me it's not gonna work and I saved some precious time.
Comment 2 Jan Stodola 2022-04-29 08:56:13 UTC 
Hi Marc,
the use case you described is really not handled well by the installer at this moment. There are actually two issues:

1) When you create a biosboot partition, the partition will not be created on all disks as it might seem from the list of devices allowed to be used for the partition after clicking on the "Modify..." button. The installer will only select on of the selected disk. A bug 2063288 exists to provide a better explanation of disks selection. So, in order to have multiple biosboot partitions on multiple disks, you have to create multiple biosboot partitions and restrict each biosboot partition to only one of the available disks. This reveals another problem:

2) Only one biosboot partition is visible in the installer. This is currently tracked in bug 1913035 for rhel-8, but needs to be fixed in rhel-9 as well. The workaround is assigning a disk to the created biosboot partition, then creating a new biosboot partition and assigning another disk and so on until all the biosboot partitions are defined - although the installer still shows just one (the latest) biosboot partition in the UI. When you click the Done button in the custom partition screen, the installer will present you a list of actions it will do - there you can see that several biosboot partitions will really be created.

I hope it helps with your use case.
Comment 3 Jan Stodola 2022-05-06 11:59:50 UTC 
Marc, can you please confirm that the two bugs from comment 2 help with your use case and this bug can be closed as a duplicate?
Comment 4 Marc Dequènes (Duck) 2022-05-09 11:33:04 UTC 
Quack,

I'm just back from Golden Week (public holiday in Japan). Thanks for the detailed information; I'll try this trick to make this installation possible.

Since #1913035 is about disallowing the creation of multiple bios boot partition and #2063288 is only about clarifying that only one disk will be used, then fixing them would make my use case impossible to realize. Unless you plan to make the creation of the partition on multiple disks a reality instead of what is suggested in #2063288 (in Expected results, there is no comment) then that's not gonna help at all. Because of this I don't think closing this BR is a good idea.

Regards.
\_o<
Comment 5 Jan Stodola 2022-05-09 15:21:20 UTC 
I've added a comment to bug 1913035#c10 clarifying that the installer will allow to create multiple multiple biosboot partitions and they will be visible in the custom partitioning spoke. The summary of the bug has also be updated to be less confusing.
Comment 6 Marc Dequènes (Duck) 2022-05-11 13:55:19 UTC 
Thanks Jan :-). You can close this one as duplicate then.
Comment 7 Jan Stodola 2022-05-12 15:53:31 UTC 
Closing as a duplicate of bug 1913035 based on previous comments.
Comment 8 Jan Stodola 2022-05-12 15:53:52 UTC 

*** This bug has been marked as a duplicate of bug 1913035 ***
Note You need to log in before you can comment on or make changes to this bug.