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

[dann frazier]

Cool, yeah - that looks like a more complete solution.

On Wed, Jun 14, 2017 at 2:35 PM, Ryan Harper <1642298 at bugs.launchpad.net> wrote:
> I think this is related and should address things.
>
> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/503
>
> This curtin is available in the daily PPA, and is in process for SRU'ing
>
> https://launchpad.net/~curtin-dev/+archive/ubuntu/daily
>
>
> If that's not applicable, I'm not aware of any curtin changes to address
> the issue.
>
>
> On Wed, Jun 14, 2017 at 2:13 PM, dann frazier <dann.frazier at canonical.com>
> wrote:
>
>> I noticed that a GRUB SRU is about to hit -updates that will trigger
>> this bug on existing systems. Though too late to avoid that, I did want
>> to recheck on the status of this bug on the curtin side.
>>
>> --
>> 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 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
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=curtin; status=Confirmed; importance=Medium; assignee=None;
> Launchpad-Bug: product=maas; status=Invalid; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=grub2; component=main; status=Fix Released; importance=Undecided; assignee=dann.frazier at canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=trusty; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=xenial; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=yakkety; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
> Launchpad-Bug-Tags: oil patch
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: blake-rouse dannf lmic raharper rodsmith
> Launchpad-Bug-Reporter: Rod Smith (rodsmith)
> Launchpad-Bug-Modifier: Ryan Harper (raharper)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: dannf

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

  ***However***, this doesn't stop a boot entry from being added after
  deploy. If the user installs a grub package update or manually runs
  'grub-install', a boot entry will be added, 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