Comment 54 for bug 1789650

Ryan,

Yes, #1, #3, and #4 were successful from the perspective of forcing a PXE boot; however, putting the ubuntu entry at the end of the boot list likely breaks the reason for creating the ubuntu entry at all (namely, enabling the node to boot if the MAAS server is down), since chances are an entry to boot to the firmware setup utility, EFI shell, or something else that would prevent an automated boot when the ubuntu entry is last in the list.

Given lack of a BootCurrent variable, I think that pushing the ubuntu entry to the second position is the easiest compromise. A more complex approach would be to move that entry beyond at least the first PXE-boot item in the Boot#### entries. This would be trickier to program and would require identifying PXE-boot items, which might not be 100% reliable. FWIW, there's code to identify PXE-boot items in the efi-pxeboot script in Checkbox. (See https://code.launchpad.net/~checkbox-dev/plainbox-provider-checkbox/+git/plainbox-provider-checkbox/+ref/master; and specifically, lines 99-100 of https://git.launchpad.net/plainbox-provider-checkbox/tree/bin/efi-pxeboot.py. The code looks for the strings "Network", "PXE", "NIC", "Ethernet", "IP4", or "IP6" in the description field. So far and AFAIK, those strings have correctly identified every network-boot option we've encountered in certification, but there's no guarantee that the next server released will use something else.) Even if you did this, moving "ubuntu" after the first PXE-boot entry might not work, because the system might boot from a later one; and moving it after the last one might not work, because there might be some intervening non-functional entry (boot to firmware setup, etc.). Maybe keep moving the ubuntu entry down until you hit a non-PXE entry (or the end of the list)? I don't think there's a perfect solution without BootCurrent -- but moving it to the second entry, or beyond the first network-boot option if you think it's worth writing the extra code, would be better than what we've got now.

> I don't quite follow the "installing with the ubunt entry first without wiping the partition table is impossible"

If the ubuntu entry is first in the BootOrder list, and if you try to redeploy the server, then that will fail, since the server will boot the existing Ubuntu installation; that's why this is a problem. Wiping the partition table is my go-to easy way around this, since when that's done and the server is rebooted, the ubuntu entry will fail and the server will try to boot what's next (PXE-boot, if it was correctly configured for MAAS).

> It sounds like you wanted to preserve the existing partition structure and just unpack the target OS on top of the disk?

No, it's just that this is the way things end up being configured with the current state of affairs. I wanted to feed your test code that condition for completeness, but of course that would work only if the partition table had been wiped (or some other workaround done) for the initial installation boot. Once a fix or workaround is in place and existing nodes redeployed, this condition won't often be encountered.