Bug 1247956
Summary: | Boot the guest with "-boot menu=on" and press F12,didn't show the boot menu index | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Shuang Yu <shuyu> | ||||||
Component: | SLOF | Assignee: | Thomas Huth <thuth> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 7.2 | CC: | dgibson, jsuchane, knoel, michal.skrivanek, michen, mrezanin, ngu, qzhang, thuth, xuhan, zhengtli | ||||||
Target Milestone: | rc | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | ppc64le | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | qemu-slof-20151103 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2016-11-04 04:31:08 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: | |||||||||
Bug Depends On: | 1279954 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Created attachment 1057297 [details]
Screenshot2 is based on x86
The F12 boot menu is behaviour specific to the x86 BIOS, it's not implemented on the Power SLOF firmware. *** Bug 1257111 has been marked as a duplicate of this bug. *** (In reply to David Gibson from comment #3) > The F12 boot menu is behaviour specific to the x86 BIOS, it's not > implemented on the Power SLOF firmware. Should we disable the prompt? SLOF ********************************************************************** QEMU Starting Build Date = Aug 6 2015 10:55:18 FW Version = mockbuild@ release 20150313 Press "s" to enter Open Firmware. Press F12 for boot menu. Populating /vdevice methods Populating /vdevice/v-scsi@1000 Hi Nini, Sorry - I was mistaken above. It turns out an F12 boot menu had been added to SLOF in order to match x86 behaviour, which I hadn't realised. When attempting to use the boot menu were you using a graphical console and USB keyboard, or the serial / hypervisor console? (In reply to David Gibson from comment #6) > Hi Nini, > > Sorry - I was mistaken above. It turns out an F12 boot menu had been added > to SLOF in order to match x86 behaviour, which I hadn't realised. > > When attempting to use the boot menu were you using a graphical console and > USB keyboard, or the serial / hypervisor console? David, Both the graphical console(connected with vncviewer) and the serial console(connected with 'nc -U') could found the F12 info, and both a failure when use it. This bug is likely because function key sequences are generated wrong in SLOF. The problem has been discussed upstream a while ago, but I think the patch has never been committed upstream yet: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-May/129475.html I'll ask for the current state... Concerning the serial console ... I think it should work if you disable the graphics card of the guest, i.e. if you start with "-nographic -vga none", since SLOF will then ignore the USB keyboard. Thanks for the analysis, Thomas. How will the menu work with the serial console? I didn't think function keys even had a well defined representation over a serial link. In any case, I'm deferring this to 7.3, it just doesn't seem vital enough for 7.2. (In reply to David Gibson from comment #9) > How will the menu work with the serial console? I didn't think function > keys even had a well defined representation over a serial link. SLOF simply supports the function key codes that are used by xterm and similar terminals... at least for F6 to F12, there seems to be a "common sense" how the function key codes should look like (see http://aperiodic.net/phil/archives/Geekery/term-function-keys.html for example). The fix for the function keys has now been picked up by upstream: https://github.com/aik/SLOF/commit/43c9abfd8144d03ffa8 This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Fix included in SLOF-20160223-1.gitdbbfda4.el7. Hi, Thomas Verified this bug with the following version, and my question is at the end after the test steps. qemu-img-rhev-2.6.0-2.el7.ppc64le SLOF-20160223-3.gitdbbfda4.el7.noarch CLI: # /usr/libexec/qemu-kvm -name test_7_31_virtionet -machine pseries,accel=kvm,usb=off -m 4G -smp 4,sockets=1,cores=4,threads=1 -uuid 8aeab7e2-f341-4f8c-80e8-59e2968d85c2 -realtime mlock=off -nodefaults -monitor stdio -rtc base=utc -device spapr-vscsi,id=scsi0,reg=0x1000 -drive file=rhel72-ppc64le-virtio.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,bootindex=1,id=scsi0-0-0-0 -drive if=none,id=drive-scsi0-0-1-0,readonly=on -device scsi-cd,bus=scsi0.0,drive=drive-scsi0-0-1-0,bootindex=2,id=scsi0-0-1-0 -vnc :10 -msg timestamp=on -usb -device usb-tablet,id=tablet1 -vga std -qmp tcp:0:4666,server,nowait -netdev tap,id=hostnet1,script=/etc/qemu-ifup,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:54:5a:5f:5b:5c,disable-legacy=off,disable-modern=on -boot menu=on -drive file=disk.qcow2,if=none,id=drive-scsi0-0-0-1,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-1,bootindex=3,id=scsi0-0-0-1 -chardev socket,id=serial_id_serial0,path=/tmp/serial,server,nowait -device spapr-vty,reg=0x30000000,chardev=serial_id_serial0 After I press "F12" at the early stage of booting process, I see the following message printed: "Select boot device:" BUT, I need to wait for more than 30s to get the following message: 1. /vdevice/v-scsi@1000/disk@8000000000000000: /vdevice/v-scsi@1000/disk@8000000000000000 2. /vdevice/v-scsi@1000/disk@8100000000000000: /vdevice/v-scsi@1000/disk@8100000000000000 3. /vdevice/v-scsi@1000/disk@8200000000000000: /vdevice/v-scsi@1000/disk@8200000000000000 So, could you help check why it blocks here so long and could we make it more quicker? Thanks, Qunfang Hi Qunfang, may I ask how often you pushed the F12 key? It works OK for me, if I only press the button once during boot. But if I hit it multiple times, the boot menu gets delayed as you described it. I never noticed this behavior before ... but that's definitely a new, different bug - could you please open a separate ticket to track it? And maybe mark this one as verified if pressing the button only once works for you faster, too? Hi, Thomas You are correct, if only push F12 key once, it works well. This bug could be verified and I will create a new one. Thanks! New bug: Bug 1339528 - SLOF boot menu gets delayed if press 'F12' key for multiple times 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/RHEA-2016-2355.html |
Created attachment 1057296 [details] Screenshot1 is based on Power Description of problem: Boot the guest with "-boot menu=on" and during the boot press F12 to check the boot menu index,the guest did't show the boot menu index. Version-Release number of selected component (if applicable): ernel-3.10.0-292.el7.ppc64le qemu-kvm-rhev-2.3.0-12.el7.ppc64le guest kernel: kernel-3.10.0-295.el7.ppc64le How reproducible: 100% Steps to Reproduce: 1.Boot the guest with "-boot menu=on" and different "bootindex" about the scsi-cd,scsi-hd,scsi-block: /usr/libexec/qemu-kvm ... -device virtio-scsi-pci,id=scsi0,addr=0x6,bus=pci.0 -drive file=test_27.raw,if=none,id=drive-scsi0,format=raw,cache=none -device scsi-hd,bus=scsi0.0,drive=drive-scsi0,bootindex=0,id=scsi0-0 -device virtio-scsi-pci,bus=pci.0,addr=0x7,id=scsi1 -drive file=RHEL-7.2-20150720.0-Server-ppc64-dvd1.iso,if=none,media=cdrom,id=drive-scsi1,format=raw -device scsi-cd,drive=drive-scsi1,id=scsi0-1,bus=scsi1.0,bootindex=1 -device virtio-scsi-pci,id=scsi2,addr=0x8,bus=pci.0 -drive file=/dev/sdc,if=none,id=drive-scsi2,format=raw -device scsi-block,drive=drive-scsi2,id=scsi0-2,bus=scsi2.0,bootindex=2 ...-boot menu=on 2.press F12 during POST and check. 3. Actual results: After press F12,the boot menu index interface didn't appear,the attachment Screenshot1 will show the first interface after the guest bootup. Expected results: Additional info: Check this problem at x86 platform and didn't hit this issue,the attachment Screenshot2 will show the boot menu index interface