Re: Redundant EFI Systemp Partitions (Was Re: How does one enable SCTERC on an NVMe drive (and other install questions))

On Fri, Jun 25, 2021 at 4:08 PM Andy Smith [off-list ref] wrote:

Hello,

On Mon, Jun 21, 2021 at 12:00:13AM -0500, Edward Kuns wrote:

quoted

looks like maybe I cannot use the installer to set up RAID mirroring
for /boot or /boot/efi.  I may have to set that up after the fact.

In November 2020 I had this discussion on debian-user:

    https://www.mail-archive.com/debian-user@lists.debian.org/msg762784.html

The summary was that the ESP is for the firmware and the firmware
doesn't know about MD RAID, so is only ever going to see the member
devices.

You could lie to the firmware and tell it that each MD member device
is an ESP, but it isn't. This will probably work as long as you use
the correct metadata format (so the MD metadata is at the end and
the firmware is fooled that the member device is just a normal
partition). BUT it is in theory possible for the firmware to write
to the ESP and that would cause a broken array when you boot, which
you'd then recover by randomly choosing one of the member devices as
the "correct" one.

Some people (myself included, after discovering all that) decided
that putting ESP on an MD device was too complicated due to these
issues and that it would be better to have one ESP on each bootable
device and be able to boot from any of them. The primary one is
synced to all the others any time there is a system update.

Ubuntu have patched grub to detect multiple ESP and install grub on
all of them.

In theory it would be possible to write an EFI firmware module that
understands MD devices and then you could put the ESP on an MD array
in the same way that grub can boot off of an MD array.

Yeah, efifs might have it
https://github.com/pbatard/efifs

One solution is making the ESP static, other than OSLoader updates. A
"stub" grub.cfg points to $BOOT/grub/grub.cfg or $BOOT/grub2/grub.cfg,
where $BOOT is typically mounted at /boot; and then follow the Boot
Loader Spec to add drop-in configuration files for each menu entry.
Typically there is one drop in file per kernel. This is how Fedora has
worked for several releases now. It permits the two grub.cfg's to
remain static, is less prone to problems if replacing it or modifying
it is interrupted by a crash. And the snippets are a more user
friendly format for editing, should it be deemed necessary, while
being less fragile.

A canonical ESP that resides virtually in /usr I think is another way
of doing all of this; and use a service unit to sync from /usr to each
ESP by mounting them e.g. somewhere in /run, in sequence, thereby
containing any problems with interruptions.

https://systemd.io/BOOT_LOADER_INTERFACE/
https://systemd.io/BOOT_LOADER_SPECIFICATION/

While some platforms are currently left out of the specs, I think it's
better to grow the spec to make booting more reliable and a lower
maintenance burden rather than continuing to do things in a rather ad
hoc manner.


-- 
Chris Murphy