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

[Steve Langasek]

"for each device in the array"

You cannot put EFI system partitions in a Linux software raid device.
This is unsupported.  You will get corruption the first time your EFI
writes data to one of the VFAT filesystems (which EFI is allowed to do).

As of Ubuntu 20.04, the grub package has support for synchronizing the
bootloader content of multiple ESPs, which is the safe way to handle EFI
boot across multiple disks in a way that is resilient in the face of
disk failure.  (And yes, it requires creating multiple boot entries in
nvram.)

-- 
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