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