[systemd-devel] "bootctl install" on mdadm raid 1 fails

[D.S. Ljungmark]

I seem to have the same problem, and here's the output:

[root at 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
<lennart at poettering.net> wrote:
> On Fr, 08.12.17 23:33, Bjørn Forsman (bjorn.forsman at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC