When setting up a RAID-1 Ubuntu system (i.e. where / and /boot are on RAID-1 mirrors) it's unclear to me what Ubuntu's answer is to making the EFI System Partition (ESP, i.e. /boot/efi) redundant, as well.

The Fedora solution, i.e. just putting it on a superblock 1.0 RAID-1, apparently isn't supported at all and thus makes grub-install fail.

There seems to be some support for letting the Ubuntu installer create 2 ESPs and install the files to both of them. But according to this recent bug report it's still unclear how this scheme is supported by regular package updates:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1876974 (see also)

So how do I have to set up the ESP's on the both disks (when aiming for RAID-1 setup with - say - Ubuntu 20.04 LTS) to make them redundant and keep them in-sync for later Ubuntu updates?

The objective here is to still be able to boot that Ubuntu system, i.e. even when one disk dies.

How does my /etc/fstab (or other relevant) configuration files have to look for such a setup?

For example, when the first ESP is mounted under /boot/efi where has the second one to be mounted in order to be recognized by Ubuntu package post-install scripts?

And what are the necessary grub-install/dpkg-reconfigure/reinstall commands to fix the ESP setup after an installer failed to set up the ESPs correctly?

  • I do not fully understand the problem. A hardware RAID controller will mirror all data at block-level. It does not care about partitions at all. A software RAID should not mirror the ESP (since the RAID is not active during boot), Nothing stops you of having two ESPs. Install grub into both of them separately.
    – Hermann
    Nov 28, 2020 at 13:36
  • 1
    @Hermann, I'm talking about software RAID here, i.e. at leat /boot and / are mirrored with mdadm or btrfs. With 1.0 Linux RAID superblocks the RAID doesn't have to be active during boot. The problem with your approach is that the second ESP isn't kept up-to-date when the grub package is updated. Or when any other package is updated that installs files into the ESP. Nov 28, 2020 at 14:45
  • 1
    Updates are only done to the grub configuration, i.e. /boot/grub/grub.cfg. The efi-compatible grub binary efi\boot\bootx64.efi or efi\distro\grubx64.efi is only written once per system lifetime, usually.
    – Hermann
    Nov 28, 2020 at 16:17
  • 1
    @Hermann, sure, one could hope for the best. On the other hand, the fun might begin when a disk fails after the next dist-upgrade where a new grub version most certainly is installed. However, I prefer a robust solution. Nov 28, 2020 at 23:13

2 Answers 2


Ubuntu's solution to a redundant ESP is to just to create and mount two of them, and reconfigure grub, instead of creating one on a superblock 1.0 RAID-1.

The name of the second mount point doesn't matter. Since a single ESP is usually mounted under /boot/efi, mounting the second ESP under something like /boot/eficopy would be natural.

Both ESPs have to be mounted automatically via /etc/fstab in case a grub package update happens.

It's important that both ESPs have the right GPT type (i.e. C12A7328-F81F-11D2-BA4B-00A0C93EC93B). Sizing them 200 MiB each is sufficient.

The initial setup then requires reconfiguring grub:

dpkg-reconfigure grub-efi-amd64

The grub reconfigure script then checks for all partitions with the ESP GPT type and allows the user to select both. After that change future package updates/re-installs will update both ESPs.

Note that (as of 2020), the reconfigure only works for grub-efi-amd64 and not for grub-efi-amd64-signed (where reconfigure doesn't prompt for anything).

Thus, one might need to install the right grub first, e.g.:

apt-get install grub-efi-amd64
apt-get remove grub-efi-amd64-signed
  • Should this solution work on Debian stable as well? I'm trying but the reconfigure does not ask for anything regarding the ESP partitions.
    – gigabytes
    Mar 30, 2021 at 19:47
  • @gigabytes I don't know. Given the extensive discussions in the Ubuntu bug-tracker it could very well be that it's a Ubuntu specific solution that might have been 'upstreem'ed to a later Debian version, if any. Perhaps you can look up the dates when Debian stable was 'frozen' and when Ubuntu's solution was created. And/or look at the relevant source packages and compare them. Mar 30, 2021 at 20:27

It does seem to work with grub-efi-amd64-signed but confusingly, to get the prompt to identify efi partitions you have to call dpkg-reconfigure shim-signed.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .