efi: stuck in local boot env after ubuntu install

[CoRfr]

Steps to reproduce:

• wipe disk
• select 'ubuntu-base' as workflow
• wait for install to complete
• select 'sledgehammer' as workflow

Expected: booting on 'sledgehammer'
Actual: booted on local system (ubuntu)

When the target reboots, since 'ubuntu' has the highest priority in the EFI boot order, the system boots from it:

root@ubuntu:~# efibootmgr 
BootCurrent: 0004
Timeout: 5 seconds
BootOrder: 0004,0002,0003,0001,0000
Boot0000* EFI Misc Device
Boot0001* EFI Internal Shell
Boot0002* EFI Network 001320FE4CA5 IPv4
Boot0003* EFI Network 001320FE4CA5 IPv6
Boot0004* ubuntu

I guess I would expect the system to first try to boot from PXE with syslinux or ipxe chain to the bootloader on a local disk (which seems to be what the 'local' boot env is doing).

There is a {{reorder-uefi-bootorder}} stage (or {{always-pxe-in-uefi-first}} task) but it doesn't seem like it's being used anywhere. Is there any reason?

[galthaus]

Couple of things. Avoiding Automagic things is kinda the rule, but with that said here we go.

Do you have the IPMI plugin installed and configured? In some cases, the runner/DRP will attempt do the IPMI call to next boot pxe but IPMI plugin has be installed, ipmi enabled, and activated.

It appears that you have a runner installed in the post-install environment. That will attempt to do things as well. For example, if you have the kexec tools installed (ubuntu is lame and doesn't include them) and the runner is running and you have set the system to KEXEC, the runner will kexec to sledgehammer instead of actually rebooting. Again, avoiding the need to reset the boot order or worry about it.

Finally, I think there are some tasks for boot order. The challenge is some OS installs reset it (like ubuntu). So, add the reorder in the sequence (potentially in the first boot after install). Since the system doesn't know what you are installing, you need to make that choice by putting tasks in the right place and the right time.

We actually encourage most people to use network boot always and let DRP handle it, but even the OS installs get in the way. It is actually why I prefer image-based installs when possible.

As we look towards the universal workflow, we may add vars to make this more configurable. Though it is always going to be a little tricky (UEFI vs legacy vs vendor tools vs linux app).