On Wed, May 18, 2022 at 7:34 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, May 18, 2022 at 7:24 AM Chris Murphy <lists(a)colorremedies.com> wrote:
>
>
>
> On Tue, May 17, 2022, 2:43 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
>>
>>
>>
>> > Am 16.05.2022 um 18:26 schrieb Chris Murphy
<lists(a)colorremedies.com>:
>> >
>> > On Sat, May 14, 2022 at 1:52 PM Peter Boy <pboy(a)uni-bremen.de>
wrote:
>> >> ...
>> >> I don’t know if there is a potential problem. Some time ago, if I
remember correctly it was Neil who wrote in a discussion about storage that a software
RAID is no longer possible, because - so my memory - the biosboot partition is not
replicable over multiple disks. So if the previous boot disk fails, you can't just
boot from another disk.
>> >
>> > Last time I checked this particular configuration of /boot on multiple
>> > drives in e.g. a raid1,10,5,6 - on BIOS firmware only, Anaconda issues
>> > the grub2-install command pointing at all the member drives making up
>> > /boot. Whether MBR or GPT, the proper GRUB core.img is installed on
>> > each. So any of them will get you to at least a grub rescue prompt.
>>
>> Did you test that?
>
>
> That's what i just described.
>
>> If I remember correctly, without the biosboot partition in place, a bios system
doesn’t boot at all from a GPT disk. So you get a black screen.
>
>
> Anaconda automatic partitioning always creates the required BIOS Boot partition. And
in Custom, it complains if you don't. So yes, i created them.
>
> The reality on UEFI is degraded boot isn't possible unless you're willing to
setup ill advised janky nonsense. Like using mdadm raid1 n-copies for n-drives for the
ESP.
>
To be fair, the same is true for legacy BIOS boot. You need the MBR
code installed on all bootable disks, you need the partition with the
boot code at the beginning of the disk on all disks, and they have to
be marked as bootable.
OK the installer isn't doing what I'm expecting it to do based on
years ago testing. So the behavior has changed.
Currently, when I select 2 drives for installation:
Automatic partitioning results in a grub2-install command to only one
the drives. Whether MBR or GPT. And if GPT only one drive gets BIOS
Boot.
Custom partitioning has at least one bug. It shows BIOS Boot partition
with two devices selected in the manual partitioning UI, suggesting
that each drive will get a BIOS Boot partition. However, the
bootloader dialog accessed at the bottom of the Installation
Destination page no longer allows both drives to be chosen. And the
summary shows only one BIOS Boot will be created. And the final
installation likewise only has one BIOS Boot, but there are separate
grub2-install commands to each of the drives selected for installation
destination. The second command fails because the drive doesn't have a
BIOS Boot partition.
https://bugzilla.redhat.com/show_bug.cgi?id=2088113
In any case, if I create BIOSBoot on the drives, and if I make /boot
raid1 on all the drives, it issues grub2-install on each drive,
populating each BIOS Boot correctly, and it can find grub.cfg and
normal.mod on even a degraded raid1 /boot. There really isn't an
equivalent on UEFI right now. Some installers might still use mdadm
metadata format 1.0 to put the mdadm super at the end of the
partition, and create a raid1 for the ESPs. This looks like individual
FAT 32 volumes from the firmware's perspective. But a raid1 from
Linux's perspective. The problem is that any writes by the firmware to
any of the ESPs results in corruption of the array and it's ambiguous
to md which drive is correct - so it's all just trash unless you're
experienced enough to know how to manually deal with it.
So the long term solution for this use case needs to be something like
bootupd, which has exclusive ownership of the $efi and $boot
partitions, or even combine them.
--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Chris Murphy