[Bug 1868553] Re: libefi* integration breaks grub-install on MD devices

[Mason Loring Bliss]

So, "dpkg-reconfigure grub-efi-amd64" now has a screen that matches what 
we'd get reconfiguring the old grub-pc:

                                                             
 ┌──────────────────────┤ Configuring grub-efi-amd64 ├───────────────────────┐
 │ The grub-efi package is being upgraded. This menu allows you to select    │
 │ which EFI system partions you'd like grub-install to be automatically     │
 │ run for, if any.                                                          │
 │                                                                           │
 │ Running grub-install automatically is recommended in most situations, to  │
 │ prevent the installed GRUB core image from getting out of sync with GRUB  │
 │ modules or grub.cfg.                                                      │
 │                                                                           │
 │ GRUB EFI system partitions:                                               │
 │                                                                           │
 │    [*] /dev/sda1 (199 MB; /boot/efi) on 120034 MB INTEL_SSDSC2BW12        │
 │                                                                           │
 │                                                                           │
 │                                  <Ok>                                     │
 │                                                                           │
 └───────────────────────────────────────────────────────────────────────────┘
                             
I'll test with a system with two ESPs later, but this ought to do the right 
thing. You'll need one entry for each, just as you would with an old-meta-
data MD-RAID1 used as an ESP, but as vorlon's noting, this will be a little
safer in the face of UEFI firmware that writes stuff to the drives.

It'd be something like:

efibootmgr -c -d /dev/sda -L ubuntu0 -l '\EFI\UBUNTU\SHIMX64.EFI'
efibootmgr -c -d /dev/sdb -L ubuntu1 -l '\EFI\UBUNTU\SHIMX64.EFI'

This is a win, and I have no further desire for direct MD-RAID 1
support.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1868553

Title:
  libefi* integration breaks grub-install on MD devices

Status in curtin package in Ubuntu:
  New
Status in grub2 package in Ubuntu:
  Confirmed
Status in subiquity package in Ubuntu:
  New

Bug description:
  Working with a new install of 20.04 on RAID-1 mirror using mdadm grub-
  install fails on EFI installs with:

  # grub-install -v /dev/md0
  ...
  Installing for x86_64-efi platform.
  grub-install: warning: efivarfs_get_variable: open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b): No such file or directory
  .
  grub-install: warning: efi_get_variable: ops->get_variable failed: No such file or directory.
  grub-install: warning: efi_va_generate_file_device_path_from_esp: could not open device for ESP: Bad address.
  grub-install: warning: efi_generate_file_device_path_from_esp: could not generate File DP from ESP: Bad address.
  grub-install: error: failed to register the EFI boot entry: Bad address.

  Note the mythical device "blk0-47c7b225-c42a-11d2-8e57-00a0c969723b" -
  the UUID is the GUID type for an EFI system partition.

  This comes from libefivars where it constructs a blk0-* device for EDD
  - see src/efi.c::get_edd_version() and
  src/efi.c::make_linux_load_option()

  It's not clear why this happens from grub but it doesn't happen (I've
  not been able to reproduce it) using efibootmr directly.

  Current workaround (but doesn't stop apt/dpkg failures) is to manually
  create the EFI entries for each device in the array, e.g:

  # for i in 0 1; do efibootmgr -c -d /dev/nvme${i}n -p 1 -L "Ubuntu
  nvme${i}n1" -l \\EFI\\ubuntu\\grubx64.efi; done

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1868553/+subscriptions