Red Hat Bugzilla – Bug 1247956
Boot the guest with "-boot menu=on" and press F12,didn't show the boot menu index
Last modified: 2016-11-04 00:31:08 EDT
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):
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.
After press F12,the boot menu index interface didn't appear,the attachment Screenshot1 will show the first interface after the guest bootup.
Check this problem at x86 platform and didn't hit this issue,the attachment Screenshot2 will show the boot menu index interface
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?
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
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?
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:
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 firstname.lastname@example.org with any questions
Fix included in SLOF-20160223-1.gitdbbfda4.el7.
Verified this bug with the following version, and my question is at the end after the test steps.
# /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?
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?
You are correct, if only push F12 key once, it works well. This bug could be verified and I will create a new one.
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.