On 1/10/19 8:35 AM, Simon Matter via CentOS wrote: > Are you sure? Yes. > How is the EFI firmware going to know about the RAID1? It doesn't specifically. Anaconda will create two EFI boot entries, each referring to one of the mirror components: # efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0001,0000 Boot0000* CentOS Linux HD(1,GPT,534debcc-f3d6-417a-b5d4-10b4ba5c1f7d,0x800,0x5f000)/File(\EFI\CENTOS\SHIM.EFI) Boot0001* CentOS Linux HD(1,GPT,05883d1e-df21-4938-bfa1-ac11ff376572,0x800,0x5f000)/File(\EFI\CENTOS\SHIM.EFI) # blkid -p -o value -s PART_ENTRY_UUID /dev/sda1 534debcc-f3d6-417a-b5d4-10b4ba5c1f7d # blkid -p -o value -s PART_ENTRY_UUID /dev/sdb1 05883d1e-df21-4938-bfa1-ac11ff376572 > RAID1 is going to have type FD00 (Linux RAID) whereas EFI firmware expects > type EF00 (EFI System Partition) to boot from. I think you're referring to MBR partition types. I'm not certain, but I don't see those values in a GPT. > EFI then reads the GPT table directly and looks for a vfat filesystem to > boot from. Default Linux software RAID1 on EL7 uses metadata 1.2 which > located at the beginning of the partition. EFI won't recognize the vfat > filesystem behind the RAID metadata. Anaconda knows that it needs to use 1.0 metadata for EFI system partitions, which is what I mean when I said "the installer should get the details right." # df /boot/efi/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/md125 194284 11300 182984 6% /boot/efi # mdadm --detail /dev/md125 /dev/md125: Version : 1.0 > Maybe certain EFI firmware is more tolerant but at least in my case I > didn't get it to work on RAID1 at all. > > I'd really be interested if someone got it to work, how exactly it's > configured. How exactly do the GPT tables look, how exactly is the RAID1 > configured. It might be more useful to know if this is still a problem for you with the current release. I'm not sure when support for this was added to Anaconda, but it was fairly recent. You may have last tried this before that release.