Looks like this comes from reading:

/sys/firmware/efi/efivars/BootCurrent-<UUID>

i'm testing a late_command to dump both efibootmgr -v output and
hexdump'ing the sysfs path
to see if that shows the missing BootCurrent entry.


On Thu, Sep 13, 2018 at 2:16 PM Ryan Harper <email address hidden> wrote:
>
> Rod,
>
> Thanks for the successful run.  Looking at the log I can see where
> curtin does a reorder of the boot entries and clearly shows a call to
> efibootmgr with the -o option.
>
> Running command ['unshare', '--fork', '--pid', '--', 'chroot',
> '/tmp/tmpbfj5kvuo/target', 'efibootmgr', '-v'] with allowed return
> codes [0] (capture=True)
> Running command ['udevadm', 'settle'] with allowed return codes [0]
> (capture=False)
> Running command ['umount', '/tmp/tmpbfj5kvuo/target/sys'] with allowed
> return codes [0] (capture=False)
> Running command ['umount', '/tmp/tmpbfj5kvuo/target/proc'] with
> allowed return codes [0] (capture=False)
> Running command ['umount', '/tmp/tmpbfj5kvuo/target/dev'] with allowed
> return codes [0] (capture=False)
> Setting currently booted 0006 as the first UEFI loader.
> New UEFI boot order: 0006,0000,0008,0007,0005,0009,000A,000B,000C,0003
> Running command ['mount', '--bind', '/dev',
> '/tmp/tmpbfj5kvuo/target/dev'] with allowed return codes [0]
> (capture=False)
> Running command ['mount', '--bind', '/proc',
> '/tmp/tmpbfj5kvuo/target/proc'] with allowed return codes [0]
> (capture=False)
> Running command ['mount', '--bind', '/sys',
> '/tmp/tmpbfj5kvuo/target/sys'] with allowed return codes [0]
> (capture=False)
> Running command ['unshare', '--fork', '--pid', '--', 'chroot',
> '/tmp/tmpbfj5kvuo/target', 'efibootmgr', '-o',
> '0006,0000,0008,0007,0005,0009,000A,000B,000C,0003'] with allowed
> return codes [0] (capture=False)
> BootCurrent: 0006
> Timeout: 5 seconds
> BootOrder: 0006,0000,0008,0007,0005,0009,000A,000B,000C,0003
> Boot0000* ubuntu
> Boot0003  UEFI: Built-in EFI Shell
> Boot0005* UEFI: Slot5 Port0 HTTP IPv4 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot0006* UEFI: Slot5 Port0 PXE IPv4 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot0007* UEFI: Slot5 Port1 HTTP IPv4 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot0008* UEFI: Slot5 Port1 PXE IPv4 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot0009* UEFI: Slot5 Port0 HTTP IPv6 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot000A* UEFI: Slot5 Port0 PXE IPv6 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot000B* UEFI: Slot5 Port1 HTTP IPv6 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
> Boot000C* UEFI: Slot5 Port1 PXE IPv6 Intel(R) 82599 10 Gigabit Dual
> Port Network Connection
>
> So the remaining question now is on the failing system why does the
> system *not* show BootCurrent in the output immediately after we
> install grub.
>
> That seems to be the core issue.  Now, once you've booted into these
> systems, efibootmgr -v does show boot current, however, while we're
> booted into the ephemeral environment and we chroot into the target
> OS, the efibootmgr command doesn't seem to return BootCurrent.
>
> Do you have any insight w.r.t what how efibootmgr determines what
> BootCurrent value should be?
>
>
>
> On Thu, Sep 13, 2018 at 2:01 PM Rod Smith <email address hidden> wrote:
> >
> > Oh, I missed one question: The servers are all set to "EFI Boot" under
> > "Power Configuration."
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1789650
> >
> > Title:
> >   Servers set to boot from disk after MAAS installation
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/curtin/+bug/1789650/+subscriptions