Subiquity does not change EFI boot order

Can you provide a curtin log from when this happens? curtin definitely *intends* to do this by default...

Logs attached. I see that "efibootmgr -o" is being called (installer-journal.txt), but apparently not with what should be the right order:

Mar 17 21:44:13 ubuntu-server subiquity_log.3145[4338]: Setting currently booted 0009 as the first UEFI loader.
...
Mar 17 21:44:13 ubuntu-server subiquity_log.3145[4338]: Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/target', 'efibootmgr', '-o', '0009,0000,0001,0004,0005,0006,0007,0008,000A,0003,0002,000B,000C,000D,000E,000F,0010'] with allowed return codes [0] (capture=False)

0009 is IP4 netboot for one of the interfaces. After I re-start and manually select option 0000 I can see this:

ubuntu@mynic:~$ efibootmgr -v
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0009,0000,0001,0004,0005,0006,0007,0008,000A,0002,000B,000C,000D,000E,000F,0010
Boot0000* ubuntu HD(1,GPT,e52c7da5-9485-4024-a44c-eaf04b6f3ff0,0x800,0x100000)/File(\EFI\ubuntu\grubaa64.efi)
Boot0001* Linux from mmc0 VenHw(8c91e049-9bf9-440e-bbad-7dc5fc082c02)/HD(1,GPT,3dcadb7e-bccc-4897-a766-3c070edd7c25,0x800,0x4a800)/File(Image)c.o.n.s.o.l.e.=.t.t.y.A.M.A.1. .c.o.n.s.o.l.e.=.h.v.c.0. .c.o.n.s.o.l.e.=.t.t.y.A.M.A.0. .e.a.r.l.y.c.o.n.=.p.l.0.1.1.,.0.x.0.1.0.0.0.0.0.0. .e.a.r.l.y.c.o.n.=.p.l.0.1.1.,.0.x.0.1.8.0.0.0.0.0. . .r.o.o.t.=./.d.e.v./.m.m.c.b.l.k.0.p.2. .r.o.o.t.w.a.i.t...
Boot0002* EFI Network 2 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()
Boot0004* EFI Misc Device VenHw(8c91e049-9bf9-440e-bbad-7dc5fc082c02)
Boot0005* EFI Network PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0006* EFI Network 1 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv6([::]:<->[::]:,0,0)
Boot0007* EFI Network 4 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be056,1)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0008* EFI Network 5 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be056,1)/IPv6([::]:<->[::]:,0,0)
Boot0009* EFI Network 8 MAC(001acaffff01,1)/IPv4(0.0.0.00.0.0.0,0,0)
Boot000A* EFI Network 9 MAC(001acaffff01,1)/IPv6([::]:<->[::]:,0,0)
Boot000B* EFI Network 3 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv6([::]:<->[::]:,0,0)/Uri()
Boot000C* EFI Network 6 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be056,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()
Boot000D* EFI Network 7 PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be056,1)/IPv6([::]:<->[::]:,0,0)/Uri()
Boot000E* EFI Network 10 MAC(001acaffff01,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()
Boot000F* EFI Network 11 MAC(001acaffff01,1)/IPv6([::]:<->[::]:,0,0)/Uri()
Boot0010* EFI Internal Shell MemoryMapped(11,0xfe110000,0xfe86e37f)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)

If you're PXE/Network booting an installer and you *don't* want to keep PXE
booting
then you likely want to include curtin grub config to disable
reordering[1][2] UEFI to retain
the boot current entry.

grub:
   reorder_uefi: false

1. https://curtin.readthedocs.io/en/latest/topics/config.html#grub
2. Curtin is typically used with MAAS where the systems are configured to
boot from the network leaving MAAS in control. On UEFI systems, after
installing a bootloader the systems BootOrder may be updated to boot from
the new entry. This breaks MAAS control over the system as all subsequent
reboots of the node will no longer boot over the network. Therefore, if
reorder_uefi is True curtin will modify the UEFI BootOrder settings to
place the currently booted entry (BootCurrent) to the first option after
installing the new target OS into the UEFI boot menu. The result is that
the system will boot from the same device that it booted to run curtin; for
MAAS this will be a network device.

On Mon, May 10, 2021 at 8:35 AM Alfonso Sanchez-Beato <
<email address hidden>> wrote:

> Logs attached. I see that "efibootmgr -o" is being called (installer-
> journal.txt), but apparently not with what should be the right order:
>
> Mar 17 21:44:13 ubuntu-server subiquity_log.3145[4338]: Setting currently
> booted 0009 as the first UEFI loader.
> ...
> Mar 17 21:44:13 ubuntu-server subiquity_log.3145[4338]: Running command
> ['unshare', '--fork', '--pid', '--', 'chroot', '/target', 'efibootmgr',
> '-o',
> '0009,0000,0001,0004,0005,0006,0007,0008,000A,0003,0002,000B,000C,000D,000E,000F,0010']
> with allowed return codes [0] (capture=False)
>
> 0009 is IP4 netboot for one of the interfaces. After I re-start and
> manually select option 0000 I can see this:
>
> ubuntu@mynic:~$ efibootmgr -v
> BootCurrent: 0000
> Timeout: 3 seconds
> BootOrder:
> 0009,0000,0001,0004,0005,0006,0007,0008,000A,0002,000B,000C,000D,000E,000F,0010
> Boot0000* ubuntu
> HD(1,GPT,e52c7da5-9485-4024-a44c-eaf04b6f3ff0,0x800,0x100000)/File(\EFI\ubuntu\grubaa64.efi)
> Boot0001* Linux from mmc0
> VenHw(8c91e049-9bf9-440e-bbad-7dc5fc082c02)/HD(1,GPT,3dcadb7e-bccc-4897-a766-3c070edd7c25,0x800,0x4a800)/File(Image)c.o.n.s.o.l.e.=.t.t.y.A.M.A.1.
> .c.o.n.s.o.l.e.=.h.v.c.0. .c.o.n.s.o.l.e.=.t.t.y.A.M.A.0.
> .e.a.r.l.y.c.o.n.=.p.l.0.1.1.,.0.x.0.1.0.0.0.0.0.0.
> .e.a.r.l.y.c.o.n.=.p.l.0.1.1.,.0.x.0.1.8.0.0.0.0.0. .
> .r.o.o.t.=./.d.e.v./.m.m.c.b.l.k.0.p.2. .r.o.o.t.w.a.i.t...
> Boot0002* EFI Network 2
> PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()
> Boot0004* EFI Misc Device VenHw(8c91e049-9bf9-440e-bbad-7dc5fc082c02)
> Boot0005* EFI Network
> PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv4(0.0.0.00.0.0.0,0,0)
> Boot0006* EFI Network 1
> PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(98039b5be055,1)/IPv6([::]:<->[::]:,0,0)
> Boot0007* EFI Network 4
> PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be056,1)/IPv4(0.0.0.00.0.0.0,0,0)
> Boot0008* EFI Network 5
> PciRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)/MAC(98039b5be...

I'm seeing this as well, on multiple arm64 servers. Using the 20.04.3 RC (20210819.1)

This seems to be reproducible only when there's a pre-existing "ubuntu" boot entry that is not the default. If no "ubuntu" entry already exists, one is created and becomes the default.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1927702