On Mon, May 16, 2022 at 12:26 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Sat, May 14, 2022 at 1:52 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Last meeting we discussed whether we should change to GPT as default partitioning.
Now some of our members have submitted a change proposal to make GPT the default
partitioning for new installations. I think this is actually long overdue, yet better
communication among us would actually be nice as well.
> 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. Of
course it requires the minimum number of disks for GRUB's md driver to
assemble the member drives so it can read /boot to find additional
grub modules and grub.cfg and the kernel and initramfs.
The problem still remains unsolved though for UEFI. Upstream GRUB
suggest sequentially mounting each ESP on each drive, and issuing
grub-install. We don't use grub-install (or grub2-install in Fedora
land) for UEFI at all though, because the grubx64.efi is built in the
Fedora build system and signed for UEFI Secure Boot. Even if the
installer were to mount each ESP in turn, copying the bootloader
configuration files to each one, and then adding the proper entries in
NVRAM for each one to act as fallbacks - the problem is they all get
out of sync as kernels and bootloader updates happen. There is an idea
how to handle this in Fedora CoreOS, a project called bootupd. But
this particular work isn't finished yet, specifically for the
raid/multiple boot disks use case.
Just to expand on this.
I personally prefer the idea of proscribing anything other than fwupd
and bootupd from writing to either /boot or /boot/efi. i.e. no more
dracut or rpm or dnf writing to /boot or /boo/efi. I also support
getting rid of persistently mounting /boot and /boot/efi. Those
volumes are only needed during boot by the bootloader, they aren't
even needed during startup (once the kernel is running and systemd is
starting up services). And when their contents are being updated.
Therefore the thing(s) responsible for updating them, should have the
sole ability to mount them, and an obligation to unmount them when the
updating is finished. That's a clean and secure way of managing /boot
(and by extension /boot/efi).
And it'd be neat if bootctl (part of systemd) were extended to act as
the user interface to bootupd where status, repair and customizations
Further, I'd like to see the canonical location for /boot and
/boot/efi to exist in /usr, such that bootupd has the ability to just
sync files from the canonical /usr location to the ESP (or multiple
ESPs). That way the ESP is completely repairable in a simple way: fsck
the ESP, if that fails mkdosfs, mount it, repopulate it,
verify+restore the NVRAM entries.