I seem to have the same problem, and here's the output: [root@spring ~]# blkid -p /dev/sda1 /dev/sda1: UUID="01c0c70f-9204-8e4e-f2a7-aa8ec14c4a41" UUID_SUB="2a820238-597c-bfd4-aa2e-19425f7e8fa4" LABEL="spring.skuggor.se:0" VERSION="1.0" TYPE="linux_raid_member" USAGE="raid" PART_ENTRY_SCHEME="gpt" PART_ENTRY_NAME="EFI System Partition" PART_ENTRY_UUID="98b45cd9-11f8-402a-8c89-a4e833581446" PART_ENTRY_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048" PART_ENTRY_SIZE="409600" PART_ENTRY_DISK="8:0"
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 <lenn...@poettering.net> wrote: > On Fr, 08.12.17 23:33, Bjørn Forsman (bjorn.fors...@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_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" > 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 > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
