Comment 29 for bug 1642298

On Fri, Jul 7, 2017 at 2:44 PM, David Britton
<email address hidden> 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