The output you provided looks exactly like what we've seen before. Where BootCurrent is not always set. Have you looked into what Rod suggested (kernel or firmware bug)?
" Overall, this looks like either a firmware bug or a kernel bug (maybe a race condition in building the EFI variables list...?). The fact that a reset via the BMC causes the BootCurrent variable to appear post-deployment but (presumably) not during deployment is peculiar, though."
It's not clear to me what curtin should do if BootCurrent is not set?
You could try a maas deployment with:
grub:
reorder_uefi: false
This has curtin skip attempting to put BootCurrent to the front of the BootOrder list.
@Jeff
The output you provided looks exactly like what we've seen before. Where BootCurrent is not always set. Have you looked into what Rod suggested (kernel or firmware bug)?
" Overall, this looks like either a firmware bug or a kernel bug (maybe a race condition in building the EFI variables list...?). The fact that a reset via the BMC causes the BootCurrent variable to appear post-deployment but (presumably) not during deployment is peculiar, though."
It's not clear to me what curtin should do if BootCurrent is not set?
You could try a maas deployment with:
grub:
reorder_uefi: false
This has curtin skip attempting to put BootCurrent to the front of the BootOrder list.