Am 15.05.2022 um 14:49 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
On Sun, May 15, 2022 at 8:45 AM Carlos Vidal <carlos(a)tarkus.se> wrote:
>
> It is true that the BIOS boot partition is limited to a single physical disk. What I
normally do is to replicate it to the other disks with "dd". As it remains
unchanged upon updates, it should be fairly easy to add this feature to Anaconda, just
after the BIOS boot installation.
>
It may already do this. I think it already does for the ESP on EFI installs.
It does actually not, unfortunately. At least not until the f35 release cycle. I didn’t
check F36.
By the way, the issue is described in the Server user documentation.
If you have a GPT partition table on a bios boot system and choose the custom partitioning
option, Anaconda creates a biosboot partition on the „first“ disk it actually boots from.
On any other disks it doesn’t care about biosboot. It not even reserves the space.
Using a mbr partition table, if Anaconda detects a /boot partition in a raid, in installs
the mbr on any disk that is part of the raid.
So, Anaconda has to be enabled to do the equivalent to biosboot on a GPT partition schema
(provided the technically specification allows it).
If you choose the ‚advanced custom option‘ (Blivet-GUI) you can manually create the
biosboot partition, but just on one disk. But you can create the partitions on the other
disks to start at the same space as on the „first“ disk, so reserve the space. And if I
remember correctly, I managed it one time to create a biosboot partition in that space
later, but I’m not sure. But I remember it was a mess.
As a consequence, we can only make GPT the default for biosboot machines when Anaconda can
manage the partitioning accordingly and after it has been *thoroughly tested* that
everything actually works in case of a boot disk failure.
I think it is unrealistic that this is feasible for F37.
On an UEFI system GPT is default any way. But remains the issue to setup a software raid.