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

[Seth Arnold]

Hmm, I guess I'm not understanding. My only system with md root has:

/dev/md126p1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors
=remount-ro)

I'm hoping that if either drive dies, this system can still boot. (But
I've not been brave enough to try yanking a drive to find out what
happens.)

Do we support having some way to boot via raid if a drive dies? This
keeps coming up every single release as something we haven't supported
correctly, ever, and if we *do* support this, it'd be nice to have it
documented somewhere what exactly we support, with which tools, etc. I
suggest the LTS server guide, but the release notes would also do.

Thanks

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