Comment 38 for bug 1642298

Hey guys.

Sorry for joining the party late. But let me see if I understand the full extent of the problem here.

0. A machine PXE boots off MAAS, installs Ubuntu in it, grub gets installed and configured without updating the NVRAM.

1. The machine reboots, PXE's, boots from local disk, and finishes installation (an unnecessary step).

2. An upgrade of <grub2 package> overwrites NVRAM to boot from disk.

3. A reboot boots from disk directly and not from network.

4. If we re-deploy, the machine is told to PXE boot via the BMC.

5. If we re-deploy the machine, the machine PXE boots off MAAS again and installs. The machine reboots and boots off the disk.

Now, the above only becomes a real problem when. The machine does not support changing the boot order remotely via IPMI or other power management mechanism.

 - That, however, is a certification problem. MAAS expects to be able to control the boot order of the machine. If this is not possible, it is a certification challenge.

That said, regardless of being able to set the boot order or not, I see a completely different problem:

1. The administrator configured their BIOS with a specific boot order.
2. The administrator installs ubuntu, expecting their BIOS boot order configuration to remain (somewhat) unchanged (specially when it is set to boot from network first).
3. The software (grub2) overrides the BIOS' boot order to boot from disk. This overrides the fact that the administrator set the BIOS boot order to PXE first.

So, based on this, the REAL bug that needs to be fixed is that grub needs to somewhat respect the boot order set in the BIOS. For example:

1. If BIOS Boot order before Ubuntu install is: 1. PXE, 2. HDD1, 3. HDD2
2. And we install Ubuntu on HDD2, then grub needs to /somewhat/ preserve the boot order and make it so: 1. PXE, 2. HDD2, 3. HDD1.

To conclude:
1. The real bug is in grub, and this needs to be addressed to properly preserve the boot order in a sane way if PXE/Network boot is set as the first boot type on the BIOS boot order.

2. If we want to make work arounds in the meantime, I think it is acceptable to say that curtin should tell grub to disable nvram updating by default, and only enabled it if the users wishes so, so we can respect what was set on the firmware.

Either way, IMHO, the real solution is to fix grub.