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

[dann frazier]

On Fri, Jul 7, 2017 at 2:44 PM, David Britton
<david.britton at canonical.com> wrote:
> Some Testing Scenarios and concerns before we agree that this change
> should be made in curtin:

I'm not sure if you're asking about the design, or test results on a
given implementation, so I'll answer with respect to the design I've
proposed.

> 1) After this change, after curtin boots first time, is EFI boot order
> a)pxe b)local disk

This proposal does not involve changing the install-time EFI boot order
at all.

As I understand it, curtin now installs a new boot entry for the
target OS - that is, it no longer passes --no-nvram to grub-install.
But, prior to reboot, it restores the previous default boot entry
(PXE). This proposal would not change this. grub2/update_nvram does
not change the behavior of grub-install called directly - just when
called by the grub maintainer scripts. Of course, this should be
verified when we have a testable implementation.

> 2) This doesn't appear scoped to grub2-efi, but modifies
> grub2/update_nvram, what effect does this have on other bios/firmware
> environments that rely on grub?

The impacted archs are described here:
https://bugs.launchpad.net/maas/+bug/1642298/comments/19

In short, EFI-based and POWER systems will be impacted. AFAICT, this
change is also beneficial for POWER, for teh same reasons, and it
should certainly be verified there before merging.

> 3) Does a new kernel install work correctly?

The value of grub2/update_nvram is orthogonal to a new kernel install.
A new kernel install does not trigger a call to grub-install, it just
updates the configuration of the existing grub installation
(update-grub).

  -dann

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