Cannot deploy to mirrored EFI partitions

Hi,

I suspect that you're missing 'grub_device: true' on your two disks in the raid1 array.

Adjusting your config like so should work:

    - id: sda
      disk: 0
      type: disk
      ptable: gpt
      grub_device: true
    - id: sdb
      disk: 1
      type: disk
      ptable: gpt
      grub_device: true

An existing storage config for this scenario (MirrorbootUEFI) is here:

https://git.launchpad.net/curtin/tree/examples/tests/mirrorboot-uefi.yaml

This likely will be resolved with an updated config. Please let me know if those suggested changes resolve your boot issue.

Please provide the data requested here:

https://discourse.maas.io/t/getting-curtin-debug-logs/169

And /etc/maas/preseeds/<whatever preseed is being changed>

mmmm... In my case it doesn't make it, can I ask why your example have
one disk using dos partition, and one using gpt?

That looks like a cut-n-paste error. I'll fix that, thanks.

W.r.t your failure, as Andres requested, definitely need the logs to determine what else might be failing.

The config you pasted looks odd, so I suspect something else is composing the actual storage config that gets sent.

I see now, you're attempting to mirror /boot/efi; that's not a support configuration. The general issues are:

1) Firmware that handles EFI does not expect these partitions to be under raid.
2) The raid format may obfuscate the devices from the firmware (it won't see the devices)
3) Given that firmware doesn't know about raid, one needs two entries to handle the case that
either device is bad
4) There are sync issues, in the case that the firmware updates the EFI partition, this data may be lost due to linux raid syncing over the "bad" data on the other disk.

The efibootmgr output looks strange for the target devices:

......A.........................T.H.N.S.F.8.8.0.0.C.A.M.E.................................................................................. ......A.........................T.H.N.S.F.8.8.0.0.C.A.M.E...

This may be related to the raid on the devices, but could also just be something else between firmware and those disks.

I'm marking this as triaged as I understand the scenario, I've outlined that there is work to do make this work and it needs validation to ensure things are reliable. Some elements are out of our control w.r.t how Firmware treats a raided partition.

These are dell poweredge c4130, so perhaps we can get better insight on
the firmware support.

Ok, to remove the firmware variable from the bug, I'm trying right
now this config:

  centos-gpu:
    disks:
    - id: sda
      disk: 0
      type: disk
      ptable: gpt
      grub_device: true
    - id: sdb
      disk: 1
      type: disk
      ptable: gpt
      grub_device: true

      # Boot
    - id: sda-part1
      name: efi
      device: sda
      size: 100M
      type: partition
      number: 1
    - id: sdb-part1
      name: efi
      device: sdb
      size: 100M
      type: partition
      number: 2

    - id: sda-part2
      device: sda
      size: 398800M
      type: partition
      number: 3
    - id: sdb-part2
      device: sdb
      size: 398800M
      type: partition
      number: 4

    - id: sda-part1-format
      volume: sda-part1
      label: boot
      type: format
      fstype: vfat
    - id: sda-part1-mount
      device: sda-part1-format
      path: /boot/efi
      type: mount

    - id: md1
      name: md1
      raidlevel: 1
      type: raid
      spare_devices: []
      devices:
      - sda-part2
      - sdb-part2
    - id: md1-format
      volume: md1
      label: root
      type: format
      fstype: ext4
    - id: md1-mount
      device: md1-format
      path: /
      type: mount

It still doesn't make it, I'll be uploading curtin info in the followings.

False alarm this later config actually make it, just seems that there was some hicups in the node
to get the ephemeral OS booting to run the curtin, but the node is currently deployed with one efi
raw fat partition, one empty fat on the second disk, and a raid on top using the second partition
of any node.

Marking this as invalid, since EFI doesn't really support software raid, and there's not much MAAS can do about it.

We recently landed code to enable grub2 in ubuntu to keep multiple ESPs in-sync. with this in place, one can now supported multiple ESPs, and example config used is here:

https://git.launchpad.net/curtin/tree/examples/tests/mirrorboot-uefi.yaml

Note, instead of creating /boot/efi on the raid mirror itself, one creates multiple ESP partitions,
mount one at /boot/EFI and grub2 will handle replicating the data whenever there's an
update to grub.