Managing Redundant ESPs with mdraid#
On a multi-device system, having multiple, redundant EFI system partitions may be desirable. This can be achieved by using a post-generation hook to copy the generated ZFSBootMenu images between ESPs, but that requires generating images yourself.
Using Linux's software RAID capabilities can allow for seamless and automatic ESP redundancy, without requiring scripts to update each ESP.
Make an EFI System Partition on each disk:
ESP_DISKS="/dev/sda /dev/sdb" for disk in $ESP_DISKS; do sgdisk -n "1:1m:+512m" -t "1:ef00" "$disk" done
Create the mdraid array:
mdadm --create --verbose --level 1 --metadata 1.0 \ --homehost any --raid-devices 2 /dev/md/esp \ /dev/sda1 /dev/sdb1 mdadm --assemble --scan mdadm --detail --scan >> /etc/mdadm.conf
Note
Depending on the distribution, additional setup may be required to assemble the mdraid array on boot. Consult your distribution's documentation for more information.
Format the array as
vfat
, create an fstab entry, and mount:mkfs.vfat -F32 /dev/md/esp cat << EOF >> /etc/fstab /dev/md/esp /boot/efi vfat defaults 0 0 EOF mkdir -p /boot/efi mount /boot/efi
Install ZFSBootMenu in
/boot/efi
as desired.
If adding boot entries with efibootmgr
, add entries for each disk in the mdraid array.
Note
This configuration exploits the fact that, with version 1.0, mdraid
metadata will be written to the end of each partition. Newer metadata
versions would be written to the beginning of each partition, and the
system firmware would fail to recognize each component as a valid EFI
system partition.
In general, allowing systems to directly access the constituent partitions of a Linux software RAID volume is inadvisable. However, the usual concerns about data integrity do not generally apply to mirroring of the EFI system partition. First, the firmware will generally read, but not write, the contents of these partitions; under normal circumstances, the only modifications made to the EFI system partitions will be by the Linux system that assembles them into an array. Second, if the firmware does commit any unintended writes to the partition from which it boots, inconsistencies can be reconciled with periodic resilvering in the host Linux installation. Finally, the contents of an EFI system partition are almost never critical. Unintended corruption of your EFI system partition could potentially prevent your system from booting, but the likelihood of such corruption is low and the partition can generally be trivially recovered in any event.