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?
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).
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: /bugs.launchpad .net/maas/ +bug/1642298/ comments/ 19
https:/
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