Bug 2184823

Summary: edk2-omvf does not save EFI boot selections
Product: [Fedora] Fedora Reporter: Paul Kenyon <pkenyon>
Component: edk2Assignee: Paolo Bonzini <pbonzini>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 37CC: berrange, crobinso, kraxel, pbonzini, philmd, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-12 08:12:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Domain XML none

Description Paul Kenyon 2023-04-05 21:01:44 UTC 
Description of problem:

The system boot options set in system settings (access by typing F2 early in boot) are not saved.  For example, if we were to set the network boot order to PXE IPv4 only, then OS, the system will continue to boot the order that was previously set.  Simiarly, boot options that are added or deleted are not saved.  The same happens when you change the boot order with efibootmgr from the guest OS.  From the libvirt xml, we can define the general boot order, e.g. disk,network or network,disk, but we can not select which of the network boot options are enabled/disabled.  There are four network boot sequences attempted when network boot is enabled - IPv4, IPv6, HTTPv4, HTTPv6; there should be the ability to disable some of these if not used.

Version-Release number of selected component (if applicable):
20230301gitf80f052277c8

How reproducible:
100%

Steps to Reproduce:
1. Create a VM in libvirt that is using EFI.
2. Start the VM; in a console, press F2 to enter setup.
3. Go to Boot Maintenance Manager -> Boot Options
4. Change Boot Order or Delete Boot Option
5. Press F10 to save (or select Commit Changes and Exit).  
6. Exit back to main menu; choose Reset.

Alternate reproduction steps:
1. Create a VM in libvirt that is using EFI.
2. Install/boot the os, e.g. RHEL 7.
3. Use efibootmgr to display, then change, then display again the boot order.
4. Reboot the system with "reboot" command from the shell.
5. See that new boot order isn't honored

Actual results:

See that boot order that was setup is not honored, and original default setting is used.

Expected results:

EFI boot order set either in system setup or from efibootmgr should be saved and used on subsequent boots.

Additional info:
Comment 1 Gerd Hoffmann 2023-04-11 14:58:32 UTC 
Please add full libvirt domain xml and efibootmgr output before and after reboot.
Comment 2 Paul Kenyon 2023-05-11 21:59:51 UTC 
Created attachment 1964094 [details]
Domain XML

With this domain.xml, secure boot setting can be changed within the EFI setup, saved, and takes effect for all subsequent boots, but EFI boot order changes do not.
Comment 3 Paul Kenyon 2023-05-11 22:02:45 UTC 
Initial EFI boot order, changing the order, before rebooting:

[root@localhost ~]# efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0007,0001,0004,0005,0006,0003,0002,0000
Boot0000* UiApp
Boot0001* UEFI PXEv4 (MAC:525400E7ECDA)
Boot0002* UEFI Misc Device
Boot0003* Red Hat Enterprise Linux
Boot0004* UEFI PXEv6 (MAC:525400E7ECDA)
Boot0005* UEFI HTTPv4 (MAC:525400E7ECDA)
Boot0006* UEFI HTTPv6 (MAC:525400E7ECDA)
Boot0007* redhat
[root@localhost ~]# efibootmgr -o 0001,0007,0003,0002,0000
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0001,0007,0003,0002,0000
Boot0000* UiApp
Boot0001* UEFI PXEv4 (MAC:525400E7ECDA)
Boot0002* UEFI Misc Device
Boot0003* Red Hat Enterprise Linux
Boot0004* UEFI PXEv6 (MAC:525400E7ECDA)
Boot0005* UEFI HTTPv4 (MAC:525400E7ECDA)
Boot0006* UEFI HTTPv6 (MAC:525400E7ECDA)
Boot0007* redhat
[root@localhost ~]#

EFI boot order after rebooting:

[root@localhost ~]# efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0001,0004,0005,0006,0007,0003,0002,0000
Boot0000* UiApp
Boot0001* UEFI PXEv4 (MAC:525400E7ECDA)
Boot0002* UEFI Misc Device
Boot0003* Red Hat Enterprise Linux
Boot0004* UEFI PXEv6 (MAC:525400E7ECDA)
Boot0005* UEFI HTTPv4 (MAC:525400E7ECDA)
Boot0006* UEFI HTTPv6 (MAC:525400E7ECDA)
Boot0007* redhat
Comment 4 Gerd Hoffmann 2023-05-12 08:12:53 UTC 
(In reply to Paul Kenyon from comment #2)
> Created attachment 1964094 [details]
> Domain XML
> 
> With this domain.xml, secure boot setting can be changed within the EFI
> setup, saved, and takes effect for all subsequent boots, but EFI boot order
> changes do not.

You have the boot order configured in the domain xml (<boot order='X'/>),
with NIC being first and DISK being second.  OVMF will sort the BootOrder
variable accordingly, this is intentional behavior.

If you don't want that you can just delete these two lines from the domain
xml and OVMF will stop reordering.
Comment 5 Paul Kenyon 2023-05-12 21:06:36 UTC 
If you delete the boot line, it will always be re-added as <boot dev='hd'/>.

Regardless, per my initial message, the boot order of the network devices is not preserved.  Is it actually libvirt altering the EFI boot order of the network entries?

As a comparison, when boot is set to hd, the disk boot options may be modified, and the order for those options alone persist.
Comment 6 Gerd Hoffmann 2023-05-15 11:08:35 UTC 
(In reply to Paul Kenyon from comment #5)
> If you delete the boot line, it will always be re-added as <boot dev='hd'/>.

OVMF ignores that, it only looks at <boot order='X'/> entries for devices.

> Regardless, per my initial message, the boot order of the network devices is
> not preserved.

It is preserved.  All nic entries are moved to the start of the list in
case the nic has the highest priority.  The ordering of the nic entries
is not changed, if shuffle them to have -- for example -- ipv6 ordered
before ipv4 ovmf would keep it.

> As a comparison, when boot is set to hd, the disk boot options may be
> modified, and the order for those options alone persist.

Same logic here.  All entries for the disk are moved according to the
boot order.  Entries pointing to the same disk are grouped together,
but keep their existing order within the group.