Custom UEFI layout with /boot/efi, bug 1168118

[Chris Murphy]

https://bugzilla.redhat.com/show_bug.cgi?id=1168118

This, among dozens of EFI System Partition bugs, and an endless stream
of user confusion demonstrated on various forums and lists proving
users do not now and will never understand the basics let alone the
specifics of EFI System Partitions. And for good reason: it's useless
boring knowledge.

Simple solution: Stop making users create them. Always make an ESP on
every selected drive. Revert to GRUB upstream recommended behavior
using a forwarding grub.cfg on the ESP that uses configfile to point
to the real one where it's always been at /boot/grub2/grub.cfg. And
now nothing ever needs to mount them because they never need to be
modified after the install.

The way we do it now has a litany of problems that we keep dancing
around, not directly addressing, and just keep trying to force a bad
idea to work one day (never).

1. We mount the ESP without fscking it first. This one might get fixed soon:
https://bugzilla.redhat.com/show_bug.cgi?id=1077917

2. We wrongly mount the ESP rw persistently by default, which
encourages corruption. This is not recommended by upstream FAT
maintainer. It's not recommended by a systemd maintainer. And it has a
known recommended, demonstrated, tested solution, with no progress
implementing it.
https://bugzilla.kernel.org/show_bug.cgi?id=92721
https://bugzilla.redhat.com/show_bug.cgi?id=1077984
https://lists.fedoraproject.org/pipermail/devel/2014-March/196824.html
https://lists.fedoraproject.org/pipermail/devel/2014-March/196855.html

3. GRUB upstream proposes (and Ubuntu and openSUSE implement) the ESP
having a static grub.cfg to forward to the real one in the usual
location at /boot/grub2/grub.cfg. That way the ESP doesn't need to be
mounted when doing kernel updates in order for grubby to modify
grub.cfg, and the system can still boot in raid1+ configurations.
https://bugzilla.redhat.com/show_bug.cgi?id=1048999

Poof. No more bugs, and no more confused users. This makes things just
like they were with BIOS+MBR on which the user was never responsible
for creating the bootloader region.

There are numerous reasons why the current behavior is bad for users,
QA, documenters, translators alike - everyone has all of this
completely superfluous and unnecessary work to do.

And there are no good reasons for the current behavior. "We do it
because we can" isn't a good enough reason.


-- 
Chris Murphy