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 1577546 - no input consoles connected under certain circumstances
Summary: no input consoles connected under certain circumstances
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ovmf
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: FuXiangChun
URL:
Whiteboard:
Depends On:
Blocks: 1579518
TreeView+ depends on / blocked
 
Reported: 2018-05-12 22:41 UTC by Laszlo Ersek
Modified: 2018-10-30 09:38 UTC (History)
5 users (show)

Fixed In Version: ovmf-20180508-2.gitee3198e672e2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 09:36:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1561128 0 high CLOSED OVMF Secure boot enablement (enrollment of default keys) 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2018:3090 0 None None None 2018-10-30 09:38:02 UTC

Internal Links: 1561128

Description Laszlo Ersek 2018-05-12 22:41:17 UTC
If both ConIn and ConOut exist, but ConIn references none of the PS/2
keyboard, the USB wild-card keyboard, and any serial ports, then
PlatformInitializeConsole() currently allows the boot to proceed without any
input devices at all. This makes for a bad user experience -- the firmware
menu could only be entered through OsIndications, set by a guest OS. The
issue used to be masked by the EfiBootManagerConnectAll() call that got
conditionalized in commit 245c643cc8b7.

Comment 2 Laszlo Ersek 2018-05-12 22:56:20 UTC
Posted upstream patch:
[edk2] [PATCH] OvmfPkg/PlatformBootManagerLib: connect consoles unconditionally
http://mid.mail-archive.com/20180512225514.30760-1-lersek@redhat.com
https://lists.01.org/pipermail/edk2-devel/2018-May/024709.html

Comment 3 Laszlo Ersek 2018-05-14 13:32:43 UTC
Upstream commit: f803c03cc2e0 ("OvmfPkg/PlatformBootManagerLib: connect consoles unconditionally", 2018-05-14).

Comment 4 Laszlo Ersek 2018-05-15 10:10:07 UTC
Virt QE, one way to test this is the following:

(1) create a new VM against the "OVMF_VARS.secboot.fd" variable store template that comes from bug 1561128,

(2) set a 10s boot progress bar timeout in the domain XML:

<domain>
  <os>
    <bootmenu enable='yes' timeout='10000'/>
  </os>
</domain>

(alternatively, use "-boot menu=on,splash-time=10000" on the command line),

(3) when the progress bar is advancing, try to interrupt it with ESC. With the bug not fixed, nothing will happen; with the bug fixed, you'll be dropped to the OVMF Setup TUI.

--*--

Now, it could happen that bug 1561128 and this bug (i.e., bug 1577546) are both addressed in the same "ovmf" build, such as "20180508-2.gitee3198e672e2.el7", for example. In that case, it may not be trivial to *reproduce* this bug, because the same OVMF build that provided you with "OVMF_VARS.secboot.fd" (for bug 1561128) would also contain the fix for this bug (i.e., bug 1577546).

If that happens, then please first grab "OVMF_VARS.secboot.fd" from the upcoming "20180508-2.gitee3198e672e2.el7" build, downgrade the OVMF package to "20180508-1.gitee3198e672e2.el7", and reproduce the issue with that, starting with step (1).

Once the issue has been reproduced, upgrade to "20180508-2.gitee3198e672e2.el7", and repeat the entire procedure (starting with step (1)). The issue should appear fixed then.

Thanks!
Laszlo

Comment 7 Miroslav Rezanina 2018-06-08 07:49:08 UTC
Fix included in ovmf-20180508-2.gitee3198e672e2.el7

Comment 9 FuXiangChun 2018-06-11 08:32:15 UTC
Laszlo,

This is my test result with the unfixed and fixed ovmf.

No matter which version(the fixed and unfixed) I use. when the progress bar is advancing, I try to interrupt it with ESC. Both will dropp to the OVMF Setup TUI.

According to comment4, with the unfixed version. "nothing will happen" when I try to interrupt it with ESC. 

If my unstanding is wrong, please correct me.  Thank.



Qemu command line:

/usr/libexec/qemu-kvm -enable-kvm -M q35 -nodefaults -smp 4,cores=2,threads=2,sockets=1 -m 4G -name vm1 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=on -debugcon file:/home/test/ovmf.log -global isa-debugcon.iobase=0x402 -spice port=5933,disable-ticketing -vga qxl -monitor stdio -boot menu=on,splash-time=10000

Comment 10 Laszlo Ersek 2018-06-11 09:29:08 UTC
FuXiangChun,

I thought I had addressed this question in the second half of comment 4 (under the "--*--" mark); however in retrospect maybe those reproducer instructions were not correct.

Can you please try the following reproducer instead:

(1) Create a brand new VM against "OVMF-20171011-4.git92d07e48907f.el7". Make sure that in this step, (a) the variable store file is created from scratch, from the file "/usr/share/OVMF/OVMF_VARS.fd", (b) the virtual machine has *no* USB keyboard (just PS/2). Boot the VM as normal, then power it off.

(2) While the VM is shut down, upgrade OVMF to "OVMF-20180508-1.gitee3198e672e2.el7". In this step, (a) *preserve* the VM's variable store file that was created in step (1), (b) add an USB keyboard (e.g. on qemu-xhci) to the VM configuration. Then boot the VM.

If I remember correctly, after step (2), you won't be able to interrupt the boot progress bar. QEMU will send the ESC keypress over USB, but OVMF will not have bound the USB keyboard, so the ESC will do nothing.

(3) Upgrade to "OVMF-20180508-1.gitee3198e672e2.el7" (either after step (2), or directly after (1)). Then the ESC over the USB kbd should work.

Sorry about the confusion; this is a pretty obscure regression.

Comment 11 Laszlo Ersek 2018-06-11 09:31:47 UTC
Ugh, sorry, in comment 10 step (3), I meant, upgrade to "OVMF-20180508-2.gitee3198e672e2.el7".

Comment 12 FuXiangChun 2018-06-12 05:34:44 UTC
Laszlo,

First, Thanks for your detailed explanation. But I still can not reproduce it. Could you please take a look at it for me again? According to comment10. This is the detailed test steps as below. 

1. Installation a new vm against OVMF-20171011-4.git92d07e48907f.el7
a)qemu cli:
.....
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=on \ -debugcon file:/home/test/ovmf1.log -global isa-debugcon.iobase=0x402 \
-monitor stdio -boot menu=on,splash-time=10000 \
-drive file=/mnt/rhel75-old-ovmf.qcow2,if=none,id=guest-img,format=qcow2,werror=stop,rerror=stop -device virtio-blk-pci,drive=guest-img,id=os-disk,bootindex=0 \
....

b) make sure "no" usb keyboard
(qemu) info usb
USB support not enabled

2.shutdown vm and cp variable store file to /home/
a)# cp /usr/share/OVMF/OVMF_VARS.fd /home/

b)add an USB keyboard to qemu cli(ehci or xhci)
-device usb-ehci,id=usb2,addr=0x7 -device usb-kbd,id=kdb,bus=usb2.0,port=1

c)update to "OVMF-20180508-1.gitee3198e672e2.el7"

d)Boot vm with /home/OVMF_VARS.fd(from step1) and usb keyboard. e.g
....
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=on \
-boot menu=on,splash-time=100000 \
-device usb-ehci,id=usb2,addr=0x7 -device usb-kbd,id=kdb,bus=usb2.0,port=1 \
....

e) ESC still can interrupt the boot progress bar and drop to the OVMF Setup TUI

Comment 13 Laszlo Ersek 2018-06-12 09:54:28 UTC
Hello FuXiangChun,

I've just tried and I can definitely reproduce this issue.

* Package versions:

- qemu-kvm-rhev-2.12.0-3.el7.x86_64
- libvirt-daemon-4.3.0-1.el7.x86_64
- virt-manager-1.4.1-7.el7.noarch
- OVMF-20171011-4.git92d07e48907f.el7.noarch.rpm [a]
- OVMF-20180508-1.gitee3198e672e2.el7.noarch.rpm [b]
- OVMF-20180508-2.gitee3198e672e2.el7.noarch.rpm [c]

* Domain XML (not changed across the repro steps):

> <domain type='kvm'
>  xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
>   <name>ovmf.fedora.q35</name>
>   <uuid>a51c0e4c-93b1-4485-811e-ea9727eb748c</uuid>
>   <memory unit='KiB'>5242880</memory>
>   <currentMemory unit='KiB'>5242880</currentMemory>
>   <vcpu placement='static'>4</vcpu>
>   <os>
>     <type arch='x86_64' machine='pc-q35-rhel7.5.0'>hvm</type>
>     <loader readonly='yes' secure='yes' type='pflash'
>      >/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
>     <nvram>/var/lib/libvirt/qemu/nvram/ovmf.fedora.q35_VARS.fd</nvram>
>     <bootmenu enable='yes' timeout='10000'/>
>   </os>
>   <features>
>     <acpi/>
>     <apic/>
>     <pae/>
>     <smm state='on'/>
>   </features>
>   <cpu mode='custom' match='exact' check='partial'>
>     <model fallback='allow'>Haswell-noTSX</model>
>     <topology sockets='2' cores='1' threads='2'/>
>     <feature policy='require' name='vmx'/>
>     <feature policy='disable' name='pcid'/>
>   </cpu>
>   <clock offset='utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>destroy</on_crash>
>   <pm>
>     <suspend-to-mem enabled='yes'/>
>     <suspend-to-disk enabled='no'/>
>   </pm>
>   <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='writeback'
>        error_policy='enospace' discard='unmap'/>
>       <source file='/mnt/data/virt-images-big/ovmf.fedora.q35.img'/>
>       <target dev='sdc' bus='scsi'/>
>       <boot order='2'/>
>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>     </disk>
>     <disk type='file' device='cdrom'>
>       <driver name='qemu' type='raw' cache='writeback'/>
>       <source file='/usr/share/OVMF/UefiShell.iso'/>
>       <target dev='sdd' bus='sata'/>
>       <readonly/>
>       <shareable/>
>       <boot order='1'/>
>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>     </disk>
>     <controller type='pci' index='0' model='pcie-root'/>
>     <controller type='pci' index='1' model='pcie-root-port'>
>       <model name='pcie-root-port'/>
>       <target chassis='1' port='0x1'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>        function='0x0' multifunction='on'/>
>     </controller>
>     <controller type='pci' index='2' model='pcie-root-port'>
>       <model name='pcie-root-port'/>
>       <target chassis='2' port='0x2'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>        function='0x1'/>
>     </controller>
>     <controller type='pci' index='3' model='pcie-root-port'>
>       <model name='pcie-root-port'/>
>       <target chassis='3' port='0x3'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>        function='0x2'/>
>     </controller>
>     <controller type='pci' index='4' model='pcie-root-port'>
>       <model name='pcie-root-port'/>
>       <target chassis='4' port='0x4'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>        function='0x3'/>
>     </controller>
>     <controller type='pci' index='5' model='pcie-root-port'>
>       <model name='pcie-root-port'/>
>       <target chassis='5' port='0x5'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>        function='0x4'/>
>     </controller>
>     <controller type='usb' index='0' model='qemu-xhci' ports='15'>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
>        function='0x0' multifunction='on'/>
>     </controller>
>     <controller type='usb' index='1' model='qemu-xhci' ports='15'>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
>        function='0x1'/>
>     </controller>
>     <controller type='sata' index='0'>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x1f'
>        function='0x2'/>
>     </controller>
>     <controller type='scsi' index='0' model='virtio-scsi'>
>       <address type='pci' domain='0x0000' bus='0x01' slot='0x00'
>        function='0x0'/>
>     </controller>
>     <controller type='virtio-serial' index='0'>
>       <address type='pci' domain='0x0000' bus='0x02' slot='0x00'
>        function='0x0'/>
>     </controller>
>     <interface type='network'>
>       <mac address='52:54:00:29:80:ae'/>
>       <source network='default'/>
>       <model type='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x03' slot='0x00'
>        function='0x0'/>
>     </interface>
>     <serial type='pty'>
>       <target type='isa-serial' port='0'>
>         <model name='isa-serial'/>
>       </target>
>     </serial>
>     <console type='pty'>
>       <target type='serial' port='0'/>
>     </console>
>     <channel type='unix'>
>       <target type='virtio' name='org.qemu.guest_agent.0'/>
>       <address type='virtio-serial' controller='0' bus='0' port='1'/>
>     </channel>
>     <channel type='spicevmc'>
>       <target type='virtio' name='com.redhat.spice.0'/>
>       <address type='virtio-serial' controller='0' bus='0' port='2'/>
>     </channel>
>     <input type='tablet' bus='usb'>
>       <address type='usb' bus='0' port='1'/>
>     </input>
>     <input type='keyboard' bus='usb'>
>       <address type='usb' bus='0' port='2'/>
>     </input>
>     <input type='mouse' bus='ps2'/>
>     <input type='keyboard' bus='ps2'/>
>     <graphics type='spice' autoport='yes'>
>       <listen type='address'/>
>       <streaming mode='off'/>
>     </graphics>
>     <video>
>       <model type='vga' vram='16384' heads='1' primary='yes'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>        function='0x0'/>
>     </video>
>     <memballoon model='virtio'>
>       <address type='pci' domain='0x0000' bus='0x04' slot='0x00'
>        function='0x0'/>
>     </memballoon>
>     <rng model='virtio'>
>       <rate bytes='1048576'/>
>       <backend model='random'>/dev/urandom</backend>
>       <address type='pci' domain='0x0000' bus='0x05' slot='0x00'
>        function='0x0'/>
>     </rng>
>   </devices>
>   <qemu:commandline>
>     <qemu:arg value='-global'/>
>     <qemu:arg value='isa-debugcon.iobase=0x402'/>
>     <qemu:arg value='-debugcon'/>
>     <qemu:arg value='file:/tmp/ovmf.fedora.q35.log'/>
>     <qemu:arg value='-fw_cfg'/>
>     <qemu:arg value='name=opt/ovmf/PcdResizeXterm,string=y'/>
>     <qemu:arg value='-global'/>
>     <qemu:arg value='pcie-root-port.io-reserve=0'/>
>     <qemu:arg value='-global'/>
>     <qemu:arg value='pcie-root-port.pref64-reserve=4G'/>
>     <qemu:arg value='-s'/>
>   </qemu:commandline>
> </domain>

* QEMU command line (generated by libvirtd, and not changed across the repro
  steps):

> /usr/libexec/qemu-kvm \
>   -name guest=ovmf.fedora.q35,debug-threads=on \
>   -S \
>   -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-ovmf.fedora.q35/master-key.aes \
>   -machine pc-q35-rhel7.5.0,accel=kvm,usb=off,smm=on,dump-guest-core=off \
>   -cpu Haswell-noTSX,vmx=on,pcid=off \
>   -global driver=cfi.pflash01,property=secure,value=on \
>   -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
>   -drive file=/var/lib/libvirt/qemu/nvram/ovmf.fedora.q35_VARS.fd,if=pflash,format=raw,unit=1 \
>   -m 5120 \
>   -realtime mlock=off \
>   -smp 4,sockets=2,cores=1,threads=2 \
>   -uuid a51c0e4c-93b1-4485-811e-ea9727eb748c \
>   -no-user-config \
>   -nodefaults \
>   -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-ovmf.fedora.q35/monitor.sock,server,nowait \
>   -mon chardev=charmonitor,id=monitor,mode=control \
>   -rtc base=utc \
>   -no-shutdown \
>   -global ICH9-LPC.disable_s3=0 \
>   -global ICH9-LPC.disable_s4=1 \
>   -boot menu=on,splash-time=10000,strict=on \
>   -device pcie-root-port,port=0x1,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \
>   -device pcie-root-port,port=0x2,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
>   -device pcie-root-port,port=0x3,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
>   -device pcie-root-port,port=0x4,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \
>   -device pcie-root-port,port=0x5,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \
>   -device qemu-xhci,p2=15,p3=15,id=usb,bus=pcie.0,multifunction=on,addr=0x2 \
>   -device qemu-xhci,p2=15,p3=15,id=usb1,bus=pcie.0,addr=0x2.0x1 \
>   -device virtio-scsi-pci,id=scsi0,bus=pci.1,addr=0x0 \
>   -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
>   -drive file=/mnt/data/virt-images-big/ovmf.fedora.q35.img,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap \
>   -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on \
>   -drive file=/usr/share/OVMF/UefiShell.iso,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on,cache=writeback \
>   -device ide-cd,bus=ide.0,share-rw=on,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1,write-cache=on \
>   -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 \
>   -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:29:80:ae,bus=pci.3,addr=0x0 \
>   -chardev pty,id=charserial0 \
>   -device isa-serial,chardev=charserial0,id=serial0 \
>   -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-ovmf.fedora.q35/org.qemu.guest_agent.0,server,nowait \
>   -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
>   -chardev spicevmc,id=charchannel1,name=vdagent \
>   -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
>   -device usb-tablet,id=input0,bus=usb.0,port=1 \
>   -device usb-kbd,id=input1,bus=usb.0,port=2 \
>   -spice port=5900,addr=127.0.0.1,disable-ticketing,streaming-video=off,seamless-migration=on \
>   -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x3 \
>   -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \
>   -object rng-random,id=objrng0,filename=/dev/urandom \
>   -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.5,addr=0x0 \
>   -global isa-debugcon.iobase=0x402 \
>   -debugcon file:/tmp/ovmf.fedora.q35.log \
>   -fw_cfg name=opt/ovmf/PcdResizeXterm,string=y \
>   -global pcie-root-port.io-reserve=0 \
>   -global pcie-root-port.pref64-reserve=4G \
>   -s \
>   -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
>   -msg timestamp=on

Steps to reproduce:

(01) Make sure that "/etc/libvirt/qemu.conf" contains the following entry in
     the "nvram" stanza:

> "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd"

     Ensure that libvirtd had a chance to pick up this config item (restart
     libvirtd).

(02) With the domain shut off, delete the file
     "/var/lib/libvirt/qemu/nvram/ovmf.fedora.q35_VARS.fd".

     As a result, at the next domain start, libvirtd will re-create the file
     from "/usr/share/OVMF/OVMF_VARS.fd", according to (01). Don't start the
     domain just yet.

(03) Install OVMF-20171011-4.git92d07e48907f.el7.noarch.rpm [a].

(04) Launch the domain. At this point it is possible to interrupt the boot
     progress bar.

     PERHAPS important (I'm not sure): I use virt-manager for all my
     testing.

     Either way, you end up in the OVMF setup TUI, or else at the UEFI shell
     prompt (booted from UefiShell.iso). Power off the VM (e.g. with the
     "reset -s" UEFI shell command).

(05) Upgrade OVMF to OVMF-20180508-1.gitee3198e672e2.el7.noarch.rpm [b].

(06) Launch the domain again. At this time, it is *not* possible to
     interrupt the boot progress bar.

     You end up at the UEFI shell prompt. The keyboard doesn't work in the
     graphical virt-manager window.

(07) Run "virsh console ovmf.fedora.q35". Over the serial console, it is
     possible to type UEFI shell commands, and the commands appear in the
     graphical virt-manager window as well.

     Power off the VM ("reset -s").

(08) Upgrade OVMF to OVMF-20180508-2.gitee3198e672e2.el7.noarch.rpm [c].

(09) Launch the domain. At this point, the boot progress bar can be
     interrupted again, in the graphical virt-manager window. Power off the
     domain.

(10) Launch the domain. Although you could, don't interrupt the progress bar
     now, just allow the UEFI shell to be booted from UefiShell.iso. Typing
     at the shell prompt in the graphical virt-manager window works now.

Comment 16 FuXiangChun 2018-06-14 05:52:16 UTC
Thanks for your help and detailed explanation. Through your explanation,I understand how to configure OVMF via libvirt.

(06) OVMF the boot progress bar cann't be interrupted via ESC and keyboard is not available in UEFI shell。

(07)Result is the same as your description in comment13.

(08)Upgrade OVMF to OVMF-20180508-2.gitee3198e672e2.el7.noarch.rpm

(09)~(10)Result is the same as your description in comment13


so,this bug is fixed. move it to verified.

Comment 17 Laszlo Ersek 2018-06-14 09:24:38 UTC
Thank you!

Comment 19 errata-xmlrpc 2018-10-30 09:36:07 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://access.redhat.com/errata/RHSA-2018:3090


Note You need to log in before you can comment on or make changes to this bug.