I seem to have the same problem, and here's the output:
[***@spring ~]# blkid -p /dev/sda1
PART_ENTRY_NAME="EFI System Partition"
The machine is 6 disks, raid1 on /boot, in mdadm format 1.0 (
metadata at the end of the device) which allows each partition to be
mounted (read only) as itself.
On Mon, Dec 11, 2017 at 11:59 PM, Lennart Poettering
> On Fr, 08.12.17 23:33, Bjørn Forsman (***@gmail.com) wrote:
>> Hi all,
>> I assumed bootctl would be able to install onto a mdadm raid 1 array
>> (mirror). But this happens:
>> $ bootctl --path=/mnt/boot install
>> Failed to probe partition scheme "/mnt/boot": Input/output error
>> The raid array is created with --metadata=0.90 (superblock at the end
>> of device). systemd v234 was used for testing.
>> I see people online that have worked around this by setting up the ESP
>> (/boot) manually, and finalizing the install with 2x calls to
>> efibootmgr. But I'm hoping for bootctl to handle this for me :-)
>> Any ideas?
> Hmm, we simply use libblkid on the block device, and validate that
> everything is in order, i.e. has a GPT disk label, and all the right
> UUIDs and so on. It's very simple code. If that doesn't work, then
> either your setup is borked or most likely the bug is in libblkid.
> We ultimately don't care much what the backing block device really is,
> as long as it exposes a GPT partition table and the kernel exposes
> proper per-partition block devices.
> You can check if blkid works properly by running:
> # blkid -p /dev/sda1
> /dev/sda1: LABEL="SYSTEM" UUID="1234-5678" VERSION="FAT32" TYPE="vfat"
> USAGE="filesystem" PART_ENTRY_SCHEME="gpt" PART_ENTRY_NAME="EFI System
> Partition" PART_ENTRY_UUID="12345678-1234-1234-1234-123456789abc"
> PART_ENTRY_FLAGS="0x1" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048"
> PART_ENTRY_SIZE="532480" PART_ENTRY_DISK="8:0"
> we need at least the fields PART_ENTRY_TYPE=, PART_ENTRY_SIZE=,
> PART_ENTRY_OFFSET=, PART_ENTRY_NUMBER=, PART_ENTRY_UUID=,
> PART_ENTRY_SCHEME= and TYPE= of these. If they are missing, then
> either your setup is bad, or blkid confused.
> That all said, unless mdadm operates with exactly zero header and
> footer on disk I doubt this will ever work and be compatible with
> EFI. But then again, I have no clue about mdadm...
> Good luck,
> Lennart Poettering, Red Hat
> systemd-devel mailing list
8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC