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

[Andrew Lutomirski]

On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
>
>> Adam's scheme is the only possibility.
>
>> Adam's raid1 /boot just seems more
>> reliable, especially if it became a designed feature.
>
> It's not my plan, it's the anaconda developers'. I only described it.
> Actually it took them like 15 minutes to get it into my dumb brain. :)

Can you all please try to make sure you're talking about the same thing?

I believe that Chris is suggesting /boot as raid1 and ESP not mounted.

Adam and Przemek seem to be talking about /boot on RAID1 (I've never
heard anyone say that /boot as RAID is a bad idea) but I think
something's very confused about my understanding of your opinions
about how the ESP should or does work.  Can one or both of you please
describe, unambiguously, how you think the ESP should be created, when
and if it should be mounted, what filesystem and/or raid config should
be used to mount it, and what should happen when a kernel is updated?

> Sure, UEFI has the capability, but it's not going to be used when simply
> booting the system normally. All the firmware does in that case is mount
> the partition and execute the bootloader it finds there.

Why not?  It's completely safe when the OS is Mac OS or Windows.  It's
sometimes safe when the OS is Linux.  It's even possibly useful: you
might want to have an ESP bootloader, shim, or whatever that logs
errors.  I bet there's at least one UEFI firmware out there that backs
up settings to ESP and/or backs up a whole firmware image to ESP.

It would be a shame for a Linux "RAID" install to corrupt the ESP just
because you did something unusual in various UEFI menus.

--Andy