Bug 1170507
Summary: | [RFE]Expose boot-menu shortcut to domain via OVMF | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Hu Jianwei <jiahu> | ||||||
Component: | ovmf | Assignee: | Laszlo Ersek <lersek> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 7.1 | CC: | dyuan, honzhang, huding, jherrman, juzhang, knoel, lersek, michen, mzhan, xfu, xwei | ||||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
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)
|
Story Points: | --- | ||||||
Clone Of: | |||||||||
: | 1172756 (view as bug list) | Environment: | |||||||
Last Closed: | 2015-11-19 14:44:29 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
Hu Jianwei
2014-12-04 08:15:03 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 Created attachment 964488 [details]
boot menu of seabios
Created attachment 965149 [details]
[PATCH] OvmfPkg: PlatformBdsLib: adhere to QEMU's -boot menu=on,splash-time=N
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 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. Posted upstream series http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11907 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 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 This bug should be solved by bug 1211337. 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. Resulting qemu cli of the xml snip is -boot order=c,menu=on,splash-time=65535,strict=on 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 |