Comment 40 for bug 1789650

@Rod

do you have the curtin install logs from your reorder_uefi: false run?

> Please review my comments in posts #29 and #30, above. The affected servers don't produce a BootCurrent variable under some circumstances, which seems to be throwing off the algorithms that curtin uses.

The curtin algorithm is:

if grubcfg.get('reorder_uefi', True):
   if efibootmgr has BootCurrent set:
       if BootCurrent in BootOrder:
            remove BootCurrent from BootOrder
       BootOrder = [BootCurrent] + BootOrder
       efibootmgr -o BootOrder

1) If BootCurrent is not present, we don't do any reordering in curtin
2) If You disable reordering (like you did) we don't do any reordering

I think I suggested the disable redordering as I was confused about what the
expected result was, let's refresh (mine) and clarify what is expected.

There was a time when MAAS *always* PXE booted (even after an install) and that the PXE config sent to the node would instead use a BootNext directive to hand off from PXE to the on-disk loader/grub.

Is that still the case?

It was with this MAAS mode that the uefi_reorder_loaders() was written (ie no matter how you booted) curtin would place the currently booted item to the head of the list, (PXE booted systems stay PXE booted, non-pxeboot will stay non-pxeboot.)

It may be the case that via BMC or other firmware modes that a PXE boot does not affect the BootOrder and *also* does not display BootCurrent; in which case, after an install curtin will not have modified *any* BootOrder values, the node of course will boot in the order it previously did.

In the case that the Firmware is reordering things under us; it's not clear how curtin can know which item (other than currently booted one) at the front. If BootCurrent is not available, how can curtin know what item to place at the beginning of the BootOrder list?