[Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.

[Rod Smith]

Blake, your proposal makes sense on the surface; however, there are
cases where it would cause problems. For instance, suppose that, outside
of a MAAS environment, somebody installs Ubuntu, then installs Windows
in a dual-boot configuration, then re-installs Ubuntu because Windows
grabbed the boot process and the user couldn't figure out how to boot
into Ubuntu. In this case, Ubuntu/GRUB would not then gain control of
the boot process, which is what the user was hoping would happen, and (I
THINK) what would happen today. Of course, re-installing Ubuntu was
overkill in this scenario, and a little knowledge would go a long way to
resolving the problem in an easier way; but I've seen posts on user
forums from new users who do things like this. This isn't to say that
your suggestion is a bad one; but implementing it would create some new
problems of its own. They might be smaller than the ones we've got now,
but they should be considered.

Three more points, should Blake's proposal be implemented:

First, and most importantly, the initial installation of GRUB in a MAAS
environment would get it wrong, since as outlined, the proposal would
give boot control to the local hard disk, which is exactly the problem
we want to avoid. In such an environment, you'd need to install GRUB and
ensure that it comes AFTER the PXE-boot option, otherwise the initial
problem (MAAS losing control of nodes' boot process) would exist. Thus,
either the GRUB package would need to take a cue from MAAS to leave the
current top boot option in control (that is, install GRUB as the second
or later boot option) or it would need enough smarts to figure this out
itself. Given the wide variation in the way PXE-boot options appear in
efibootmgr output, the former is likely to be more reliable than the
latter.

Second, there's a potential implementation pitfall: There might be
stale/invalid NVRAM entries that point to GRUB on non-existent devices.
This could happen when MAAS redeploys a node, since the partition table
will be wiped and new partitions created, but the NVRAM-based boot
entries will be untouched. (Analogous things can happen in local/manual
installations, too, of course.) The new EFI System Partition (ESP) will
have a new GUID, which won't match the old one for the original
installation. Thus, if the check for a reference to grubx64.efi doesn't
include the GUID value (at a minimum; there are other identifying
features, too), it might think the existing entry is valid, when in fact
it's not. (Note that some, but not all, EFIs wipe invalid boot entries,
so some computers might not exhibit this problem, but others will.)

Third, on systems that boot with Secure Boot active, the NVRAM entry
will normally point to shimx64.efi, not grubx64.efi. In fact, this is
usually the case even when Secure Boot is NOT active, or is unavailable;
but with Secure Boot out of the picture, either binary should work to
boot the computer.

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

Title:
  Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
  overwritten.

Status in curtin:
  Confirmed
Status in MAAS:
  Confirmed
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  Triaged
Status in grub2 source package in Xenial:
  Triaged
Status in grub2 source package in Yakkety:
  Triaged

Bug description:
  [Impact]
  Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader.

  *Update*: newer curtin releases actually allow the creation of a new
  boot entry, but updates the boot menu to make PXE the default. That
  change is orthogonal to this bug.

  ***However***, this doesn't stop a new default boot entry from being
  added after deploy. If the user installs a grub package update or
  manually runs 'grub-install', booting from disk will become the
  default, and MAAS will lose control of the system.

  [Proposed Solution (er... glorified workaround)]
  The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install.

  This isn't a perfect solution - users can still call grub-install
  manually and omit this flag.

  [Test Case]
   - MAAS deploy an EFI system.
   - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture)
   - Reboot and observe that the system does not PXE boot.

  [Regression Risk]
   - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs).
   - XXX curtin risk XXX

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