rfc: EFI System partition, FAT32, repair and non-persistent mount

[Chris Murphy]

On Mar 19, 2014, at 7:51 PM, Adam Williamson <awilliam at redhat.com> wrote:

> On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
>> 
>> More complex than trying to mirror a FAT ESP partition across multiple
>> boot disks, keeping it properly synchronized, because RAID isn't
>> supported?
> 
> You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
> of how RAID-1 works; each individual member can also be mounted as if it
> was just a plain old partition, which is how the firmware will mount it.

This shouldn't be done. It's a source of corruption to treat an md raid1 device as a plain volume, rather than as a degraded md device. If the plain partition volume is modified, its mdadm metadata won't be updated, so when the array is finally assembled, mdadm has no idea member devices are not sync'd, and also has no way to resolve the ambiguity.

Because of this, at least one raid stack kernel maintainer wants to do away with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that permits this plain old  partition treatment as a side effect. 

v1.2 metadata is preferred since it compels the proper treatment of individual member devices as md devices not plain partitions. The metadata is offset 4KB by the start, so only something that will treat it as an md device (normally or degraded assembly) will be able to use it. And  hence not useable by UEFI firmware.

Therefore I don't think software RAID is a solution. It's more complicated and problem prone than what I've suggested by obviating the on-going need to update the ESP in the first place. Instead we should treat the ESP like the MBR gap, and BIOS Boot: Write once, forget about it. (Short of some critical security update.)

> On the UEFI side you just write entries for each of the ESPs into
> the EFI boot manager. If one of them fails, then the firmware will boot
> from the next in line.

The firmware itself will do a fallback even without specific NVRAM entries, and will eventually land on one of the ESP's /EFI/BOOT/BOOTX64.efi's.


Chris Murphy