Hide Forgot
Description of problem: qemu cli: -drive id=drive_image1,if=none,format=qcow2,snapshot=off,file=/root/r.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1 \ -boot order=cdn,once=n,menu=off,strict=off \ Slof will firstly boot from virtio-blk-pci,bootindex=0, if this device is not bootable or if the disk is an empty disk or boot failed, slof will stop to boot, it will not change to other boot method; Version-Release number of selected component (if applicable): Host: 3.10.0-514.el7.ppc64le qemu-kvm-rhev-2.6.0-28.el7_3.2.ppc64le SLOF-20160223-6.gitdbbfda4.el7.noarch Guest: 3.10.0-514.6.1.el7.ppc64le How reproducible: 100% Steps to Reproduce: 1.boot a guest, with an empty disk r.qcow2 and specify this device bootindex=1; /usr/libexec/qemu-kvm \ -name 'RHEL7.3-vm1' \ -machine pseries \ -nodefaults \ -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=03 \ -device usb-ehci,id=usb1,bus=pci.0 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0 \ -drive id=drive_image1,if=none,format=qcow2,snapshot=off,file=/root/r.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1 \ -device virtio-net-pci,mac=9a:7b:7c:7d:7e:71,id=idtlLxAk,vectors=4,netdev=idlkwV8e,bus=pci.0 \ -netdev tap,id=idlkwV8e,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 \ -m 2G \ -smp 4,maxcpus=8 \ -cpu host \ -vga std \ -vnc :1 \ -qmp tcp:0:8881,server,nowait \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=n,menu=off,strict=off \ -monitor stdio \ -enable-kvm \ -usb -device usb-host,hostbus=1,hostaddr=3,id=usb0 \ 2. 3. Actual results: (1)Slof will firstly boot from virtio-blk-pci,bootindex=1, if this device is not bootable or if the disk is an empty disk or boot failed, slof will stop to boot, it will not change to other boot method; (2)If remove the "bootindex", the slof will firstly boot from network because of "once=n", if boot from network failed, it will stop; Then if reboot, guest will boot as order=cdn; Expected results: if the disk that "virtio-blk-pci,bootindex=1" is an empty disk or boot failed, slof will try to boot from network because "once=n" Additional info:
Just a note: According to https://github.com/qemu/qemu/blob/master/docs/bootindex.txt : "If the bootindex property is not set for a device, it gets lowest boot priority." Since we're using "strict=off" here, I think SLOF should try to boot from the NIC anyway after failing to boot from the block device, even without "once=n".
FWIW, here are some technical details what's going on here: QEMU builds a list with all devices that have the "bootindex" parameter and passes it to SLOF in the /chosen/qemu,boot-list device tree property. The value from "-boot order=xxx" (or the value from "-boot once=x" during the first boot) gets passed in /chosen/qemu,boot-device instead. Now, when SLOF detects the /chosen/qemu,boot-list property, it currently only uses this list for booting, and completely ignores /chosen/qemu,boot-device. I think we've got to fix this so that SLOF combines both approaches instead (or "once=x" will never work properly): It should look at /chosen/qemu,boot-device first to see which *classes* of devices should be considered for booting. Devices of these classes should then get extracted from the /chosen/qemu,boot-list property, so that they are considered for booting in the right order according to their "bootindex" parameter. Then, if we started QEMU with "strict=off", we should finally also add the other remaining devices to the SLOF-internal list of possible boot devices.
I've now suggested a patch on the SLOF mailing list: https://lists.ozlabs.org/pipermail/slof/2017-January/001426.html
The SLOF maintainer suggested to fix this issue in QEMU instead, so I'm changing to the component to qemu-kvm-rhev now.
Finally, at least my patch that fixes the "strict=off" problem has been accepted in SLOF: http://git.qemu-project.org/?p=SLOF.git;a=commitdiff;h=ef5286f020d850f47fe196297f673769f6d63198 ... so moving the component back to SLOF now.
We'll get the fix via rebase to SLOF-20170303
Fixed by rebase
The following is the step of verification: 1.Version: Host:3.10.0-623.el7.ppc64le Qemu:qemu-kvm-rhev-2.9.0-0.el7.mrezanin201703210848 SLOF:SLOF.noarch 20170303-1.git66d250e.el7 2.Steps to Verify: Same to the top Description 3.Actual results: SLOF ********************************************************************** QEMU Starting Build Date = Mar 14 2017 08:36:17 FW Version = mockbuild@ release 20170303 Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /pci@800000020000000 00 0000 (D) : 1234 1111 qemu vga 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] 00 1000 (D) : 1af4 1004 virtio [ scsi ] Populating /pci@800000020000000/scsi@2 SCSI: Looking for devices 00 1800 (D) : 1af4 1003 virtio [ serial ] 00 2000 (D) : 1af4 1001 virtio [ block ] 00 2800 (D) : 1af4 1000 virtio [ net ] 00 4800 (D) : 1af4 1002 unknown-legacy-device* Installing QEMU fb Scanning USB XHCI: Initializing USB Keyboard USB mouse USB Storage SCSI: Looking for devices USB-DISK: Bulk commad failed! USB-DISK: Bulk commad failed! No console specified using screen & keyboard Welcome to Open Firmware Copyright (c) 2004, 2011 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /pci@800000020000000/scsi@4 ... E3404: Not a bootable device! Trying to load: from: /pci@800000020000000/scsi@4 ... E3404: Not a bootable device! Trying to load: from: cdrom ... E3405: No such device Trying to load: from: /pci@800000020000000/ethernet@5 ... Initializing NIC Reading MAC address from device: 9a:7b:7c:7d:7e:71 Requesting information via DHCP: done Using IPv4 address: 10.19.112.128 Requesting file "pxelinux.0" via TFTP from 10.19.42.13 Receiving data: 25 KBytes TFTP: Received pxelinux.0 (25 KBytes) E3403: Bad executable: No boot partition found E3406: Client application returned an error: No boot partition found ..`. .. ....... .. ...... ....... ..`...`''.`'. .''``````..''. .`''```''`. `''`````` .`` .:' ': `''..... .''. ''` .''..''....... ``.':.';. ``````''`.''. .''. ''``''`````'` ``.':':` .....`''.`'`...... `'`.....`''.`'` .`.`'`` .'`'`````. ``'''''' ``''`'''`. `'` Type 'boot' and press return to continue booting the system. Type 'reset-all' and press return to reboot the system. ..`. .. ....... .. ...... ....... ..`...`''.`'. .''``````..''. .`''```''`. `''`````` .`` .:' ': `''..... .''. ''` .''..''....... ``.':.';. ``````''`.''. .''. ''``''`````'` ``.':':` .....`''.`'`...... `'`.....`''.`'` .`.`'`` .'`'`````. ``'''''' ``''`'''`. `'` Type 'boot' and press return to continue booting the system. Type 'reset-all' and press return to reboot the system. Ready! 0 > The guest try to boot from network,so this bug is fixed, and change the status to verified.
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/RHBA-2017:2093