[Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk

[Rod Smith]

Andres, fundamentally the problem is that EFI provides no means to
control the boot order via IPMI; it's set via non-IPMI firmware
mechanisms or via the efibootmgr tool in Ubuntu. That is, point #4 in
your first list is incorrect, and everything falls apart after that.
When a GRUB package uses efibootmgr to set GRUB as the default boot
option, the configuration to PXE-boot first is overridden and MAAS loses
control of the computer's boot process. Although I, the original
reporter, am on the server certification team, this isn't a
certification issue per se; it affects ANYBODY who uses MAAS to
regularly redeploy nodes. Larry Michel, then on the OIL team, noted that
it affects OIL in comment #3. Sooner or later, customers will be
affected by this, too.

You can view this as a problem with EFI and/or how IPMI interacts with
EFI if you like, but that won't resolve the problem. Like it or not, the
industry is moving to EFI, and my understanding is that the big players
in this realm aren't interested in providing a way for IPMI to set the
boot order on EFI-based systems. Even if they did, at this late date
there'd still be a large installed base of computers that wouldn't work
with any mechanism that might be developed.

What we (Canonical) CAN control is how and when we use efibootmgr to
adjust the boot order. This is PARTLY a GRUB packaging issue, but we
need some way to tell that package whether or not to set itself as the
default boot option. Blake, Ryan, and Dann are discussing ways to use
debconf variables to tell the GRUB package what to do, and if I'm
understanding correctly, MAAS will have to set such a variable in a
preseed file to produce results that keep nodes controllable by MAAS.

Of course, once a node is deployed, its owner could log in and mess
things up. There's not much we can do about that, but at least we can
ensure that our own tools and procedures don't mess things up.

-- 
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:
  UEFI Xenial install sets computer to boot from hard disk

Status in curtin:
  Confirmed
Status in MAAS:
  Incomplete
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