[SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

stri · 2022-09-13 15:25:11

I'm a beginner with RAID and I'm trying to set up RAID 1. I use systemd-boot. Everything seems to work, but `bootctl list` errors. In [1] it says

If the server has more than one disk in the system, then it is recommended to make the ESP in a RAID 1. The important thing in this case is to set --metadata=1.0 on the MD. This will write the MD metadata to the end of the partition and not to the start of the partition. This is needed in this case to give the UEFI firmware the ability to detect the ESP.

So I adapted what I read on the Arch wiki RAID page and used

mdadm --create --run --verbose --level=1 --homehost=any --metadata=1.0 --raid-devices=2 /dev/md0 /dev/loop0p1 /dev/loop1p1

for the uefi partition. However, `bootctl list` errors:

[root]# bootctl list
Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi.
Alternatively, use --esp-path= to specify path to mount point.

Then I try --esp-path /boot (/dev/md0 is mounted on /boot)

[root]#  bootctl list --esp-path /boot
File system "/dev/block/9:0" is not located on a partitioned block device.

The system boots fine and e.g. the following files contain the expected values:

/sys/firmware/efi/efivars/LoaderEntryDefault-*
/sys/firmware/efi/efivars/LoaderEntrySelected-*

Also great is that I can apparently use `bootctl set-default` which changes the LoaderEntryDefault way in the expected way, and the system reboots fine into the new default.

`bootctl status` reports

Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi.
Alternatively, use --esp-path= to specify path to mount point.
Failed to probe partition scheme of "/dev/block/9:0": Input/output error
System:
     Firmware: UEFI 2.70 (American Megatrends 5.17)
  Secure Boot: disabled (setup)
 TPM2 Support: no
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 251.4-1-arch
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
               ✓ Load drop-in drivers
               ✓ Boot loader sets ESP information
WARNING: The boot loader reports a different ESP UUID than detected!
          ESP: /dev/disk/by-partuuid/223810f0-063e-43d2-8e95-2e07fdef30e9
         File: └─/EFI/BOOT/BOOTX64.EFI

Random Seed:
 Passed to OS: no
 System Token: not set

Boot Loaders Listed in EFI Variables:
        Title: UEFI OS
           ID: 0x000A
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/223810f0-063e-43d2-8e95-2e07fdef30e9
         File: └─/EFI/BOOT/BOOTX64.EFI

        Title: UEFI OS
           ID: 0x0009
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/663b3425-ed90-4956-a22e-46853086ecb8
         File: └─/EFI/BOOT/BOOTX64.EFI

Note the

Failed to probe partition scheme of "/dev/block/9:0": Input/output error

and

WARNING: The boot loader reports a different ESP UUID than detected!

Is this normal? It's not a huge problem (or is it?), but I would like to use bootctl list if possible.

[1] https://docs.hetzner.com/robot/dedicate … partition/

Last edited by stri (2022-09-14 12:40:05)

frostschutz · 2022-09-13 16:01:28

Why are you using loop devices?

stri · 2022-09-14 07:04:57

Sorry my bad, all of the output above from `bootctl list` etc. is for a server with two NVME SSds. The mdadm command I use on the server:

mdadm --create --run --verbose --level=1 --homehost=any --metadata=1.0 --raid-devices=2 /dev/md0 /dev/nvme0n1p1 /dev/nvme1n1p1

I'm trying to reproduce the error with qemu-kvm, that's why I accidentally mixed in the `mdadm` command I used for the loop devices. In the qemu guest, output of `bootctl list` and `bootctl list --esp-path=/boot` is as above. In the qemu guest, the output of `bootctl status` is:

Couldn't find EFI system partition. It is recommended to mount it to /boot or /efi.
Alternatively, use --esp-path= to specify path to mount point.
Failed to probe partition scheme of "/dev/block/9:0": Input/output error
System:
     Firmware: UEFI 2.70 (EDK II 1.00)
  Secure Boot: disabled (unsupported)
 TPM2 Support: no
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 251.4-1-arch
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
               ✓ Load drop-in drivers
               ✓ Boot loader sets ESP information
WARNING: The boot loader reports a different ESP UUID than detected!
          ESP: /dev/disk/by-partuuid/05da35c9-d2cd-4e31-9b04-e0490d1bc6fb
         File: └─/EFI/BOOT/BOOTX64.EFI

Random Seed:
 Passed to OS: no
 System Token: not set

Boot Loaders Listed in EFI Variables:

Same warnings on the qemu guest. As opposed to the server, no boot loaders listed in EFI Variables for the qemu geust.

frostschutz · 2022-09-14 10:09:10

Seems like bootctl does not support RAID setups directly.

2017 - https://lists.freedesktop.org/archives/ … 39962.html

2020 - https://github.com/systemd/systemd/issues/12468

2021 - https://github.com/systemd/systemd/issues/19668

There are some recommendations for workarounds in those, too. So there may be something you can use anyway.

The main argument against RAID seems to be there is firmware that can write the ESP before the mirror is set up so the RAID would be out of sync. You would then have to run a mdadm repair action before the filesystem is mounted, or risk corruption.

schard · 2022-09-14 10:19:55

Can you please provide

# mdadm --detail /dev/md0
# lsblk
# gdisk -l /dev/md0

PS:
Nevermind, the systemd-boot issue still persists.
I suggest you create one ESP on one of the disks and mirror the partition filling the rest of that disk.

Last edited by schard (2022-09-14 11:02:46)

stri · 2022-09-14 12:39:01

The main argument against RAID seems to be there is firmware that can write the ESP before the mirror is set up so the RAID would be out of sync. You would then have to run a mdadm repair action before the filesystem is mounted, or risk corruption.

Ok, thanks for summarizing it! So it's dangerous.

I suggest you create one ESP on one of the disks and mirror the partition filling the rest of that disk.

Great thanks, I'll look into that!

frostschutz · 2022-09-14 14:18:33

stri wrote:

Ok, thanks for summarizing it! So it's dangerous.

Maybe dangerous from point of view of systemd, which has to support everyone and all setups under the sun.

Not dangerous in your personal use case where you make sure that such out-of-sync writes are not happening.

It just means you might have to jump some hoops to make it work for you as there won't be any direct support for it. Not with bootctl anyway...

stri · 2022-09-14 14:40:40

Ok, thanks for providing the links! From what I read it makes sense that they can't support it.

Arch Linux

#1 2022-09-13 15:25:11

[SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#2 2022-09-13 16:01:28

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#3 2022-09-14 07:04:57

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#4 2022-09-14 10:09:10

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#5 2022-09-14 10:19:55

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#6 2022-09-14 12:39:01

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#7 2022-09-14 14:18:33

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

#8 2022-09-14 14:40:40

Re: [SOLVED] RAID 1 with UEFI partition: `bootctl list` does not work

Board footer