Comment 28 for bug 1466150

While installing ESP on top of mdadm (metadata version <= 1.0) RAID-1 is practically possible, supporting this is not: The UEFI specification (version 2.8, sections 13.3.1.1, 13.3.3) defines the ESP as a FAT32 file system which is located (directly) on a GPT partition. While this does not seem to be part of the specification, some UEFI implementations expect to be able to write to an ESP.

Having UEFI write to what it must assume is just a FAT32 file system, but is really a mdadm RAID device in a RAID-1 array hosting a FAT32 file system, is problematic. While technically possible, allowing direct writes to a single RAID member violates RAID-1 and mdadm's expectations, and will put the RAID array into an inconsistent state, requiring a re-sync, which can only happen after mdadm detects the fact that this array is inconsistent.

This conclusion has also been drawn in bug 1817066, which therefore suggests an alternative approach for improved data security for ESP: to support installing to multiple separate ESPs (located directly on GPT partitions).

This said, the current bug report seems to be about several things:

* grub-install cannot gracefully handle the (unsupported / non supportable) situation where the active ESP (FAT32 file system) is not located directly on a GPT partition (on a GPT partitioned disk), invokes efibootmgr with an empty -d (target device) argument; this can make grub-install fail, can make the grub package installation fail (pending dpkg configuration) and leave apt in a bad state, breaking installations

* Some Ubuntu installers may allow to create partition schemes where ESP file systems are not located directly on a partition on a GPT partitioned disk, but such layouts should not be supported by these installers

* Release upgrades may fail to handle (unsupported / unsupportable) partition schemes which contain a ESP which is not located directly on a partition on a GPT partitioned disk (an error)