RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1170507 - [RFE]Expose boot-menu shortcut to domain via OVMF
Summary: [RFE]Expose boot-menu shortcut to domain via OVMF
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ovmf
Version: 7.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-04 08:15 UTC by Hu Jianwei
Modified: 2015-11-19 14:44 UTC (History)
11 users (show)

Fixed In Version: ovmf-20150414-1.gitc9e5618.el7
Doc Type: Enhancement
Doc Text:
OVMF now supports the "Enable boot menu" option in the virt-manager application and the underlying "bootmenu" element in the libvirt domain XML. If this option is selected when booting a virtual machine (VM) using OVMF, the VM now displays a progress bar before booting. If the user presses the ESC key before the progress bar disappears, the VM switches to the UEFI Configuration utility. (BZ#1170507)
Clone Of:
: 1172756 (view as bug list)
Environment:
Last Closed: 2015-11-19 14:44:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
boot menu of seabios (7.93 KB, image/png)
2014-12-04 09:13 UTC, Hu Jianwei 		no flags Details
[PATCH] OvmfPkg: PlatformBdsLib: adhere to QEMU's -boot menu=on,splash-time=N (3.55 KB, patch)
2014-12-05 16:22 UTC, Laszlo Ersek 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1211337 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2015:2465 0 normal SHIPPED_LIVE OVMF bug fix and enhancement update 2015-11-19 11:43:18 UTC

Internal Links: 1211337

Description Hu Jianwei 2014-12-04 08:15:03 UTC 
Description
Expose boot-menu shortcut to domain via OVMF

Version:
libvirt-1.2.8-10.el7.x86_64
qemu-kvm-rhev-2.1.2-14.el7.x86_64
OVMF-20140822-1.git9ece15a.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
seabios is capable of enabling or disabling a boot menu before bootloader, so we can select a bootable device from the menu manually, this is shortcut menu without going into bios setup. But lack of such capability in OVMF, after TianoCore splash screen, we can not enter such menu.

Actual results：
No entry to display boot menu between TianoCore splash screen and Bootloader screen.

Expected results:
OVMF should try to imitate seabios behavior, just as below:

[root@ibm-x3850x5-06 ~]# virsh dumpxml win7 | grep -A4 "<os"
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.1.0'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='yes' timeout='10000'/>
  </os>
[root@ibm-x3850x5-06 ~]# virsh start win7
Domain win7 started

After starting the domain, please see my attachment for the real boot menu under seabios.

Additional info:
Clipped qemu command line:
[root@ibm-x3850x5-06 ~]# ps aux | grep win7
qemu     18939 98.1  0.2 1697916 92792 ?       Sl   15:50   1:04 /usr/libexec/qemu-kvm -name win7 -S -machine pc-i440fx-rhel7.1.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 61b1e472-ba92-4497-98af-fac5f9a0e3c4 -no-user-config -nodefaults -device sga -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=c,menu=on,reboot-timeout=0,splash-time=10000,strict=on ...
Comment 2 Laszlo Ersek 2014-12-04 09:08:40 UTC 
I asked for a detailed specification of the feature, and the above doesn't look like one.

Anyway I think I can figure it out myself with some testing, and referring to the QEMU and SeaBIOS code, and the domain XML format: http://libvirt.org/formatdomain.html#elementsOSBIOS

So, here's the cases. The libvirt bootmenu @enable='yes' setting corresponds to the -boot menu=on qemu command line switch, which in turn is stored as value 0 or value 1 in the uint16_t typed FW_CFG_BOOT_MENU key.

Internally, SeaBIOS transforms this key to a file called "etc/show-boot-menu", and later references this file instead of the direct key.

In addition, libvirt's @timeout attribute corresponds to the -boot splash-time qemu command line switch, which is then stored as a (little endian) uint16_t value in the "etc/boot-menu-wait" fw_cfg file.

The settings go through several layers of transmogrification. For example, SeaBIOS defaults to showing the boot menu if the FW_CFG_BOOT_MENU is absent, but qemu *always* stores that key, and if the user doesn't specify -boot menu at all, then it stores a zero. Therefore the apparent default is "don't show the boot menu", even though SeaBIOS's own default is "do show the boot menu".

So I'll ignore the various flip-flops and just see what happens in practice.

(a) Boot menu is not requested. In this case SeaBIOS proceeds to loading the boot options immediately.

(b) Boot menu is requested, and

(b1) no timeout is specified. In this case we go with the next case, and use 2500 as timeout value.

(b2) timeout is specified. The uint16_t value means the number of milliseconds to wait. We have three outcomes:

(c1) the timeout elapses. SeaBIOS proceeds to load the boot options non-interactively.

(c2) the user presses the "enter boot menu" key before the timeout elapses. The boot menu is displayed.

(c3) the user presses a different key before the timeout elapses. SeaBIOS proceeds to load the boot options non-interactively.

The above can be mapped to OVMF as follows:
- if FW_CFG_BOOT_MENU is zero, proceed to boot as always -- immediately.

  If an OS level facility has been used previously to set the
  EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit in the OsIndications non-volatile
  variable, then the UEFI Setup utility will be entered.

- if FW_CFG_BOOT_MENU is nonzero:
  - if the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit in the OsIndications
    non-volatile variable has been set, then we enter the UEFI Setup utility
    immediately. Otherwise,

  - if etc/boot-menu-wait is absent, use 3 seconds
    (rounded up from 2500 msecs)

  - if etc/boot-menu-wait is present, round it up to the next full second.
    This also includes the case of zero seconds, which means just check for
    an already pending keypress.

  - display the progress bar for the calculated number of seconds
    - if the timeout elapses, OVMF will proceed to load the boot options

    - if the user presses Enter before the timeout elapses, OVMF will proceed
      to load the boot options

    - if the user presses any other key before the timeout elapses, OVMF will
      enter the UEFI setup

Here's the SeaBIOS features that OVMF will not support:
- user defined splash screen
- user defined boot message
- user defined key
- etc etc etc
Comment 3 Hu Jianwei 2014-12-04 09:13:23 UTC 
Created attachment 964488 [details]
boot menu of seabios
Comment 5 Laszlo Ersek 2014-12-05 16:22:36 UTC 
Created attachment 965149 [details]
[PATCH] OvmfPkg: PlatformBdsLib: adhere to QEMU's -boot menu=on,splash-time=N
Comment 8 Hu Jianwei 2014-12-17 08:26:30 UTC 
I found a similar issue on rebootTimeout attribute in <bios> with OVMF.

[root@jiahu ~]# rpm -q libvirt OVMF qemu-kvm-rhev
libvirt-1.2.8-10.el7.x86_64
OVMF-20140822-7.git9ece15a.el7.x86_64
qemu-kvm-rhev-2.1.2-14.el7.x86_64

like:
   <os>
...
    <bios useserial='yes' rebootTimeout='10000'/>
  </os>

qemu-kvm command line is "-boot reboot-timeout=10000,", need we fix it in this bug together, or file a separate bug to track it? Thanks
Comment 9 Laszlo Ersek 2014-12-17 09:26:26 UTC 
The qemu-kvm manual page says

  A timeout could be passed to bios, guest will pause for rb_timeout ms when
  boot failed, then reboot. If rb_timeout is '-1', guest will not reboot,
  qemu passes '-1' to bios by default. Currently Seabios for X86 system
  support it.

In OVMF, when all boot options fail, then the setup TUI is entered (also known as the Intel BDS Front Page). Simply rebooting when all boot options fail is not supported by Intel BDS, and in fact rebooting would make less sense than the current behavior. So "reboot-timeout" is one of those flags that won't be supported by OVMF.
Comment 10 Laszlo Ersek 2015-01-07 11:48:44 UTC 
Posted upstream series
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11907
Comment 11 Laszlo Ersek 2015-01-13 12:21:08 UTC 
Posted upstream v2 (links to the individual messages rather than the v2 0/3 blurb because the rotten sourceforge mail server is dragging its feet again):

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11969
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11970
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11971
Comment 12 Laszlo Ersek 2015-01-14 20:03:56 UTC 
Patches to backport:

1 9253c14 OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot
          menu=on[,splash-time=N]"
2 ea444a3 OvmfPkg: PlatformBdsLib: get front page timeout from QEMU
3 9aaf441 ArmVirtualizationPkg: PlatformIntelBdsLib: get front page timeout
          from QEMU
Comment 14 Laszlo Ersek 2015-04-20 11:02:05 UTC 
This bug should be solved by bug 1211337.
Comment 16 Xiaoqing Wei 2015-06-16 09:11:24 UTC 
on system with
OVMF-20150414-1.gitc9e5618.el7.noarch
qemu-kvm-rhev-2.3.0-2.el7.x86_64

booting a vm with xml snip as below:
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.2.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/efi-stub-rhel7.1_VARS.fd</nvram>
    <boot dev='hd'/>
    <bootmenu enable='yes' timeout='65535'/>
  </os>

after OVMF displaying the Tianocore logo,
then a moving progress bar with text "start boot options" appear,
now
1) touch nothing, after the progress bar reaches the right side, grub2 start work
2) press ESC key, OVMF config utility start work.

So based on above, move to VERIFIED.
Comment 17 Xiaoqing Wei 2015-06-16 09:12:27 UTC 
Resulting qemu cli of the xml snip is
-boot order=c,menu=on,splash-time=65535,strict=on
Comment 19 errata-xmlrpc 2015-11-19 14:44:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2465.html
Note You need to log in before you can comment on or make changes to this bug.