On Fri, Jun 25, 2021 at 4:08 PM Andy Smith <andy@xxxxxxxxxxxxxx> wrote: > > Hello, > > On Mon, Jun 21, 2021 at 12:00:13AM -0500, Edward Kuns wrote: > > 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@xxxxxxxxxxxxxxxx/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
