On Thu, 14 Jan 2021 at 19:04, Thomas Lange <[email protected]> wrote: > > Hi Alexander, > > my short search found some links that all say, UEFI cannot boot > software AID. This makes much sense to me. The solution seems to have > a /boot/efi partitions on each disk and have two UEFI boot entries.
OK, after some more research I have found that there are two approaches: 1. Put the ESP (EFI system partition) inside the RAID, but with mdadm option --metadata=1.0. This puts RAID metadata at the end and fools UEFI into believing it is a plain FAT32 partition. There is a risk of corruption if something writes to the partition outside of RAID, but this can be mitigated with a startup script that forces a sync. I have tried this in FAI and it works, but the efibootmgr error that I mentioned before is still present (not fatal, but ugly). 2. Keep the ESP outside RAID on each disk like Thomas said. It should suffice to set up the ESP on one disk and then clone it to the second disk. I would prefer the second method because it is not a hack. I have successfully tried it with only 1 disk in the RAID during install, but with 2 disks there is a problem. The disk_config for this 2-disk case currently looks like: disk_config disk1 disklabel:gpt bootable:1 primary /boot/efi 512M vfat rw primary - 512M - - primary - 1G-4G - - primary - 30G-36G - - primary - 4G- - - disk_config disk2 sameas:disk1 bootable:1 disk_config raid fstabkey:uuid raid1 /boot disk1.2,disk2.2 ext2 rw,noatime raid1 swap disk1.3,disk2.3 swap sw raid1 / disk1.4,disk2.4 ext4 noatime,rw raid1 - disk1.5,disk2.5 - - Obvious problem: the `sameas` also clones the /boot/efi mount point, and install fails with “mount point /boot/efi used twice”. Is there an easy way around this, like some mountdisks hook script, or is the ESP-inside-RAID a better option after all? Regards, Alexander
