On Fri, Jun 30, 2017 at 3:06 PM, Blake Rouse <email address hidden>
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?
Is there a use-case for a separate value used during grub-install than from
what one would put in the debconf value?
On Fri, Jun 30, 2017 at 3:06 PM, Blake Rouse <email address hidden>
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?
Is there a use-case for a separate value used during grub-install than from
what one would put in the debconf value?
> /bugs.launchpad .net/bugs/ 1642298 /bugs.launchpad .net/curtin/ +bug/1642298/ +subscriptions
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> UEFI Xenial install sets computer to boot from hard disk
>
> To manage notifications about this bug go to:
> https:/
>