I'm setting up a HTPC with Ubuntu 64-bit, using UEFI and RAID with GPT disks.

Is it possible for the EFI system partition (partition type 0xEF00) to be part of a RAID1 array using mdadm? I'm hoping that metadata version 1.0 (at the end of the disk) will allow this.

Also, what should "device for boot loader installation" be set too, or does that only apply to MBR disks?

5 Answers 5


As you say, mdadm metadata ver. 1.0 does the job.

I've managed to get working configuration that Gigabyte's GA-C1037UN-EU EFI was able to boot. This configuration is limited to RAID1 for ESP partition, but allows to use any RAID configuration for the rest of the partitions. Let show RAID1 on two drives as example. Every disk is partitioned in the next way:

sda (gpt)
--sda1 (512MB)
  mdadm array member with 1.0 metadata format
  boot and esp flags set
--sda2 (rest of disk)
  mdadm array member with 1.2 metadata format

First RAID created over sdX1 partitions on each drive and used for ESP partition. Rest of the drives capacity can be used in any manner, for example, in RAID1 too. Let the first RAID be /dev/md/efi and the second /dev/md/data. /dev/md/efi should not use any partitioning labels, such as MBR or GPT. /dev/md/data can be partitioned later or used as LVM pv. For example:

--fat32 fs, mounting to /boot/efi/
  linux swap partition
  ext4 root partition
  ... (other needed partitions)

Metadata ver. 1.0 has one simple feature: it's superblock is stored at the end of the RAID partition, so BIOS can detect plain FAT32 partition with ESP and BOOT flags. So nothing prevents BIOS from searching EFI/BOOT/BOOTX64.EFI on this partition and booting from it.

Main limitation of this method is that GRUB should be configured to install bootable EFI file in path for removable media, because efibootmgr is trying to make BIOS boot directly from md device, not sdX. This can be done using grub-install with --removable flag.

UPD. There are compatibility issues. Tried same configuration on ASUS P8Z68-V PRO/GEN3 motherboard. System won't boot no matter what I do.

  • I also wonder what happens if your BIOS writes to one of the partitions
    – sourcejedi
    Commented Sep 4, 2017 at 8:05
  • What about mdadm 0.90 which should support older grub (read this)? Maybe it will work for ASUS P8Z68.
    – hrvoj3e
    Commented Dec 11, 2017 at 20:34
  • 1
    I tested it and it is only possible with MD metadata version 1.0 because the ESP partition remains in GPT and metadata is stored behind. With metadata version 2.0 the partition is incorporated into the MD superblock, so the firmware cannot detect it.
    – Kouros
    Commented Jul 5, 2019 at 7:25
  • I am trying to replicate this with a current Debian and three disks. I debootstrapped the system and am now trying to execute grub-install in a (arch-)chroot. However I only get error: disk md127 not found, not matter what cli flags I add or change. Does anyone has an idea how to call grub-install for a positive outcome? Commented Sep 23, 2023 at 17:02

After much experimentation I think this is the answer:

The EFI system partition (usually mounted at /boot/efi/) doesn't hold many files, unless e.g. GRUB is stored directly there instead of /boot/grub/. The contents usually don't change, so there is no need to RAID the partition. Having multiple copies of the partition across different disks would also require the UEFI boot entries to be set with efibootmgr; usually GRUB initialises this based on the mounted partition of /boot/efi/.

So it seems that it's both not needed, and not easy to do.

  • 2
    But let's say you want to have raid1 just for safety if one disk fails. Would "and not easy to do." mean it is possible?
    – zidarsk8
    Commented Sep 3, 2012 at 21:00
  • What about all those guides saying demonstrating both a boot partition and efi system partition? Commented Jul 2, 2014 at 7:28
  • See also: askubuntu.com/q/660023/50254 Commented Sep 13, 2021 at 13:44

I think the short answer is: No, EFI system partitions (ESPs) cannot be RAID-ed. However, you can still get RAID-like advantages if you clone the ESP between you RAID disks and add both partitions into the EFI boot chain. For details, see this 20.04 link or this 18.04 link, or this 16.04 link.

  • What would you suggest to be the best way to synchronise each partition's /boot if you make changes such as adding a new kernel... etc? Commented Nov 10, 2015 at 8:46
  • 1
    You don't have to! See my comment at askubuntu.com/questions/660023/…. Commented Nov 10, 2015 at 9:49

No it's not possible yet, most motherboards the have UEFI can read of a limited number of partition types for the EFI (eg. FAT32) and RAID is not one of them.


Technically, yes, the ESP can be mirrored when putting the RAID superblock at the end (which is the case if you create a Linux RAID-1 version 1.0 format superblock).

In such a setup the raided ESP is indistinguishable from a non-raided ESP by the UEFI firmware.

However, this mode isn't supported by Ubuntu and none of the Ubuntu tooling works with such a setup. (In contrast e.g. to Fedora.)

However, having redundant and synced ESPs is still important, even if their content doesn't change often. Package updates that write to the ESP do happen, latest on the next dist-upgrade. Also, if one drive fails you need a redundant ESP to still being able to boot from the other leg of your root filesystem, i.e. when that was created on a RAID-1. And then is should better contain current software that is compatible with the rest of the Ubuntu system.

Fortunately, Ubuntu nowadays supports redundant ESPs in other ways. That means their grub package can be reconfigured to always update a second ESP, as well, whenever the system writes to the ESP:

You must log in to answer this question.

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