[iam-TJ]

One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content.

A second issue is that since FAT doesn't have permissions any user ID on the system can potentially mount, read, and possibly write to the ESP.

A separate (possibly encrypted) /boot/ file-system can be hosted on a RAID device or even loaded over the network.

With a 'regular' boot process (UEFI > ESP boot-loader core > LUKS unlock > /boot/ boot-loader 2nd stage > /boot/ kernel+initrd > root-fs) the only thing lost is the boot-loader core, which can quickly be switched for a USB boot, set options appropriately to find and use /boot/, and for the boot process to use alternate RAID device(s) and continue with a degraded boot.

On UEFI most distros now do not use os-prober to populate GRUB's own menu with other bootable OSes (GRUB_DISABLE_OS_PROBER=yes) since it expects those OSes to have added themselves to the UEFI boot menu.

As for replacing the default boot entry, this is caused by efibootmgr not GRUB. GRUB calls efibootmgr with "--create|-c" which adds a new BOOTNUM and puts it at the head of the list.

GRUB could be taught a new option that then does several efibootmgr operations: parsing text output of "efibootmgr" to get current boot order, --delete-bootorder then --bootorder A,B,C,OS to ensure OS is added last.

That is obviously fragile so best approach would be to teach efibootmgr a new option --create-append|-C that adds the new entry to the end of BootOrder and then simply teach GRUB a new variable GRUB_UEFI_BOOTORDER_FIRST=yes|no to use efibootmgr --create-append.

[sneak]

As someone who has run /boot on raid1 for years, I think his idea in the article of keeping them synchronised in userspace at update time (ie rsync) is better. There is no reason to need realtime raid1 kernelspace sync when /boot changes only monthly.

[effie]

One good reason is that mdraid takes care of syncing automatically, no need to set up rsync on every update of /boot.

[effie]

> One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails

It is possible to make ESP part of MDRAID array of level 1 with metadata v1. True, the boot starts with single disk and only later Linux activates the array. So if your boot fails before that happens, reboot and try the other disk.

Or alternatively, don't set up MDRAID array for ESP, just have the ESP mirrored on all disks.

[iam-TJ]

"don't set up MDRAID array for ESP, just have the ESP mirrored on all disks. "

Isn't that the entire point of utilising MD RAID-1 in the first place?

I've done as you suggest in years gone by with either metadata v0.9 or v1.0 (not v1.1 or v1.2) where the metadata is not at the start of the block device and therefore does not confuse a non-MDRAID-aware firmware or other OS.

[effie]

> I've done as you suggest in years gone by with either metadata v0.9 or v1.0

Then why did you wrote

> it is not possible to make it part of a software RAID device

You are saying it is both not possible and that you've done it.

[iam-TJ]

It is NOT possible to have the UEFI access the RAID device so that if one of the mirrors is broken it can continue to boot in degraded mode.

It requires manual intervention of a knowledgable person to boot a UEFI system into the default OS if the ESP is broken or missing.

[effie]

OK now I get what you mean. In that case, one can reboot and select the other non-broken disk and the system will boot, with some hiccups due to degraded array, but it will boot.