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

[Ryan Harper]

On Tue, Aug 1, 2017 at 2:39 PM, dann frazier <dann.frazier at canonical.com>
wrote:

> On Mon, Jul 31, 2017 at 12:07 PM, Ryan Harper
> <1642298 at bugs.launchpad.net> wrote:
> > On Fri, Jun 30, 2017 at 3:06 PM, Blake Rouse <blake.rouse at canonical.com>
> > wrote:
> >
> >> I think having MAAS tell curtin to set the grub2/update_nvram to False,
> >> works fine. Since the path to the EFI loader should not change this is
> >> acceptable.
> >>
> >> Having grub adjust the EFI vars because of an upgrade is really bad in
> >> MAAS case because a following re-deploy will no longer work.
> >>
> >
> > We currently have a config key:
> >
> > grub:
> >   update_nvram: <boolean: default False>
> >
> > Which tells curtin whether or not to pass the --no-nvram flag to
> > grub-install
> >
> > We could also set the grub2/update_nvram debconf value to match this
> config.
> > Will that achieve the desired goal?
>
> If grub2/update_nvram is always false, then yes. But if it were set to
> true, that would regress this issue.
>

OK, curtin defaults to false, and MAAS is what drives that setting.  I
don;t know if/when they set that value to True

It sounds like grub2 should always have that value when it's installed
then? Is that the case with new installs?
Are we just attempting to plug upgrades of images which have an older grub2?


>
> > Is there a use-case for a separate value used during grub-install than
> from
> > what one would put in the debconf value?
>
> AIUI, curtin now *does* update NVRAM at install, but then reorders the
>

Only if MAAS sets update_nvram to true; otherwise we pass the no-nvram
flag


> boot entries after the fact to keep PXE booting as the default.  I'm
> not sure if this is related to the config key or not. Even so, we
> would still want update_nvram to be set to false after install, to
> avoid grub updates from overriding the PXE boot default.
>

The reordering of the UEFI menu is not related to the update_nvram flag;
That always happens on UEFI installs now, primarily to allow for booting
nodes when MAAS is offline (no PXE)


>
>   -dann
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1642298
>
> Title:
>   UEFI Xenial install sets computer to boot from hard disk
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
>

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