On 12/24/21 14:29, Cameron Simpson wrote:
On 24Dec2021 12:09, Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote:
Additionally, it should be performed *after* adding the replacement
disk to the RAID set, not before.
Is that true? My (blurry) mental model for this issue is that the boot
block isn't in the area maintained by the RAID, which is also the reason
that RAID1 doesn't automatically make all drives in the set bootable.
That suggests that you could do this before or after.
Right, the boot block *is* in a non-RAID area (the MBR) for the standard
config, which is partitions in RAID sets. But grub2 still has to map
the Linux device names to BIOS devices for use during boot, and the way
that I remember it (I haven't managed an mdraid system on BIOS in a
*long* time), the device needed to be a member when grub2-install was
run in order for the resulting grub2 image to have a complete view of
the places it might find its configuration files, etc.
If I'm wrong, or if things have changed since I last set up a BIOS
system with mdraid and GRUB2, I hope someone corrects me. :)
(Note that this step is not required and should not be performed on
UEFI systems, only BIOS.)
This also I'd like explained. Is this because the UEFI stuff _will_ be
in the area mirrored by the RAID?
On UEFI systems, the firmware doesn't load a bootloader out of a boot
block, it has a path to the boot loader in a FAT filesystem. Rather than
putting a bootloader in a static location where the BIOS will look (as
grub2-install does on BIOS), UEFI systems are given a location where
they should look using efibootmgr.
But beyond grub2-install being unnecessary on UEFI, the standard effect
of running it on a UEFI system is to rebuild the grub2 EFI image, and
that will break Secure Boot systems because your efi image is no longer
signed. Looking at bz#1917213, it seems like grub2-install will (as of
some very recent version) refuse to run in order to not break the image.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
