Comment 45 for bug 1642298

Andres, it's perfectly possible to redeploy a system after it's been set to boot from the local disk by either adjusting the boot order on the node or by deleting GRUB from the local disk. I don't recall which of those I did in the procedure noted in my comment #2, but it was likely one of those things; I simply didn't mention it; probably I thought it was obvious that I was working around the problem.

I'm not familiar with freeipmi-tools; however, I've just tested the following with ipmitool, and neither forced a server to PXE-boot:

ipmitool -H 10.20.30.13 -I lanplus -U user -P pass chassis bootparam set force_pxe
ipmitool -H 10.20.30.13 -I lanplus -U pass -P pass chassis bootdev pxe

Both times, ipmitool reported that the node was set to PXE-boot, but in both cases, the boot order reported by efibootmgr did not change, and when I rebooted, the node booted from the first item on that list (that is, not PXE-booting). I verified the boot order both by watching the boot process on the terminal and noting no PXE-boot attempt and by verifying via efibootmgr, once the system was up, that the BootCurrent variable was set to the "ubuntu" entry, not to a PXE-boot entry. I did this testing on betelnut, a Dell PowerEdge T110 in Lexington.

As to what GRUB should be doing on installation, that's different for MAAS vs. a non-network install (say, your laptop). EFI is explicitly designed to support multiple boot loaders on a disk, so an OS that installs in a non-PXE-boot way *MUST* register itself with the firmware, and in practice, OSes normally set their boot loaders as the default. Thus, changes to the boot order on OS installation are normal and expected behavior in the EFI world. MAAS is the special case here; if a MAAS-deployed OS should continue to boot with the help of the MAAS server, then the OS should either not register itself or register itself but ensure that the PXE-boot option(s) come earlier in the boot list than the local boot loader.

Note that, back in February, Dann Frazier submitted a change to GRUB and/or curtin that fixed this bug by causing the behavior you describe as optimal -- that is, the GRUB package no longer touched the EFI boot order when it was installed from the network, and it kept a debconf variable to ensure that future GRUB updates didn't cause problems (those updates, really, are the problem). (I don't see Dann's changes linked from this bug report, but maybe I'm missing something.) That, however, caused nodes to fail to boot if the MAAS server became inaccessible, since then there was no fallback to boot from GRUB on the hard disk. I believe somebody filed a bug on that, but I don't have a reference. Dann noted in comment #21 to this bug report that a GRUB SRU was imminent that would likely cause a regression on THIS bug, and in comment #23, I confirmed that this was the case.