update_nvram defaults to false, not true as per docs

[Lee Trager]

While verifying MAAS 2.9.0b1 I noticed that NVRAM variables are not being written. MAAS does not set this variable and according to the docs it should be set to true by default[1]. Without NVRAM being written the UEFI boot order isn't modified and no new entry is added for the deployed OS. If MAAS is down while a deployed machine reboots this may cause the machine to be unable to reboot.

[1] https://curtin.readthedocs.io/en/latest/topics/config.html?highlight=nvram#grub

[Lee Trager (ltrager)]

Note curtin.cfg does disable updating NVRAM in grub as a debconf_selection. This is to fix LP:1642298 and shouldn't effect Curtin. Even if the debconf_selection is removed Curtin does not update nvram.

[Ryan Harper (raharper)]

mwhudson already saw this and fixed in master, though without filing a bug and no review AFAICT. =(

https://git.launchpad.net/curtin/commit/?id=83944d61e95ea7eb17289625330f0863bec39488

So daily curtin groovy is fixed. This is released in 20.1 so we'll need to SRU to Xenial, Bionic, Focal.

[Ryan Harper (raharper)]

@ltrager

Any idea why the maas verification for the 20.1 SRU didn't catch this?

curtin's vmtest runs with pristine NVRAM, so we always run with update_nvram=true otherwise we can't boot into whatever is installed.

[Lee Trager (ltrager)]

SolutionsQA and the MAAS CI verify that operations like commissioning and deploying work. AFAIK neither verify the deployed environment, just that the CI can SSH into it. Since both CIs verify that MAAS doesn't go down while testing this test case isn't hit.

I'll leave this open for MAAS to add NVRAM verification to the MAAS CI.

[Jerzy Husakowski (jhusakowski)]

The version of curtin with the patch is incorporated in MAAS 2.9