No change to curtin here, it will use update-nvram, remove old loaders and reorder.
Looking at the output of the failed system I can see:
after grub-install efiboot settings
+ efibootmgr
BootOrder: 0000,0002,0001,0003,0004,0005,0006,0007,0008
Boot0000* ubuntu
Boot0001* Hard Disk 0
Boot0002* PXE Network
Boot0003 Enter Setup
Boot0004 Boot Devices
Boot0005 Boot Manager
Boot0006 Setup
Boot0007 Diagnostics
Boot0008 Firmware Log
Here we've added the ubuntu entry at 0000; and we know we booted via 0002 (PXE)
since this is maas. What we would expect to see is curtin do a reorder and here
it is in the log:
Now, the reorder code logs if it is *not* reordering, and we do not see that in the output, so it must have attempted to reorder (as expected).
In the reorder code block we have:
efi_output = util.get_efibootmgr(target)
currently_booted = efi_output.get('current', None)
boot_order = efi_output.get('order', [])
if currently_booted:
if currently_booted in boot_order: boot_order.remove(currently_booted)
boot_order = [currently_booted] + boot_order new_boot_order = ','.join(boot_order)
LOG.debug( "Setting currently booted %s as the first "
"UEFI loader.", currently_booted)
LOG.debug(
"New UEFI boot order: %s", new_boot_order)
with util.ChrootableTarget(target) as in_chroot: in_chroot.subp(['efibootmgr', '-o', new_boot_order])
The only path out of here that doesn't log is if the efi_output['current'] is not set.
But since we don't see additional calls to efibootmgr with -o to set the order then
it must have returned output that didn't have 'BootCurrent' set.
The efibootmgr -v output from Rod certainly shows BootCurrent, so this remains somewhat mysterious as to why we attempted to reorder but didn't find a BootCurrent value in the
efibootmgr -v output right after a grub install.
No change to curtin here, it will use update-nvram, remove old loaders and reorder.
Looking at the output of the failed system I can see:
after grub-install efiboot settings 0001,0003, 0004,0005, 0006,0007, 0008
+ efibootmgr
BootOrder: 0000,0002,
Boot0000* ubuntu
Boot0001* Hard Disk 0
Boot0002* PXE Network
Boot0003 Enter Setup
Boot0004 Boot Devices
Boot0005 Boot Manager
Boot0006 Setup
Boot0007 Diagnostics
Boot0008 Firmware Log
Here we've added the ubuntu entry at 0000; and we know we booted via 0002 (PXE)
since this is maas. What we would expect to see is curtin do a reorder and here
it is in the log:
Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpggk7qp pj/target' , 'efibootmgr', '-v'] with allowed return codes [0] (capture=True)
Now, the reorder code logs if it is *not* reordering, and we do not see that in the output, so it must have attempted to reorder (as expected).
In the reorder code block we have:
efi_output = util.get_ efibootmgr( target) booted = efi_output. get('current' , None) get('order' , [])
boot_ order.remove( currently_ booted)
new_boot_ order = ','.join( boot_order)
"Setting currently booted %s as the first " Target( target) as in_chroot:
in_ chroot. subp([' efibootmgr' , '-o', new_boot_order])
currently_
boot_order = efi_output.
if currently_booted:
if currently_booted in boot_order:
boot_order = [currently_booted] + boot_order
LOG.debug(
"UEFI loader.", currently_booted)
LOG.debug(
"New UEFI boot order: %s", new_boot_order)
with util.Chrootable
The only path out of here that doesn't log is if the efi_output[ 'current' ] is not set.
But since we don't see additional calls to efibootmgr with -o to set the order then
it must have returned output that didn't have 'BootCurrent' set.
The efibootmgr -v output from Rod certainly shows BootCurrent, so this remains somewhat mysterious as to why we attempted to reorder but didn't find a BootCurrent value in the
efibootmgr -v output right after a grub install.