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 1096560 - fail to assign correct order for the boot device in seabios as we specified the bootindex in qemu-kvm cli(under the same virtio-scsi-pci)
Summary: fail to assign correct order for the boot device in seabios as we specified t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: seabios
Version: 7.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Markus Armbruster
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1113520 1129930
TreeView+ depends on / blocked
 
Reported: 2014-05-12 03:29 UTC by Jun Li
Modified: 2015-03-05 08:15 UTC (History)
19 users (show)

Fixed In Version: seabios-1.7.5-5.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1129930 (view as bug list)
Environment:
Last Closed: 2015-03-05 08:15:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0345 0 normal SHIPPED_LIVE seabios bug fix and enhancement update 2015-03-05 12:27:47 UTC

Description Jun Li 2014-05-12 03:29:01 UTC
Description of problem:
fail to assign correct order for the boot device in seabios as we specified the bootindex in qemu-kvm cli(under the same virtio-scsi-pci).
This issue is different from bz923030(this bz is under different virtio-scsi-pci).

Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-60.el7_0.2.x86_64
seabios-bin-1.7.2.2-12.el7.x86_64
3.10.0-123.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot guests using following cli:
/usr/libexec/qemu-kvm -m 2G \
-device virtio-scsi-pci,id=scsi0 \
-drive file=/home/juli/win2012r2-64.qcow2-copy-from-auto,if=none,id=disk1,format=qcow2 \
-device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=100,lun=0,bootindex=0 \
-boot menu=on -monitor stdio -vnc :2 \
-drive file=/dev/disk/by-path/ip-10.66.9.10:3260-iscsi-iqn.2013-11.com.example:storage.disk1.juli.xyz-lun-2,if=none,id=disk2 \
-device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=0,lun=0,bootindex=3 -S
2.check the boot order in seabios.
Press F12 for boot menu.
3.

Actual results:
sys-disk2 is the first disk and sys-disk1 is the second disk when press F12.
Such as:
1. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
2. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
...

Expected results:
the order of the boot device in seabios should the same to we specified the bootindex in qemu-kvm command line.

Additional info:

Comment 2 Sibiao Luo 2014-05-12 05:05:19 UTC
(In reply to Jun Li from comment #0)
> Description of problem:
> fail to assign correct order for the boot device in seabios as we specified
> the bootindex in qemu-kvm cli(under the same virtio-scsi-pci).
> This issue is different from bz923030(this bz is under different
> virtio-scsi-pci).
> 
> Version-Release number of selected component (if applicable):
> qemu-kvm-1.5.3-60.el7_0.2.x86_64
> seabios-bin-1.7.2.2-12.el7.x86_64
> 3.10.0-123.el7.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.boot guests using following cli:
> /usr/libexec/qemu-kvm -m 2G \
> -device virtio-scsi-pci,id=scsi0 \
> -drive
> file=/home/juli/win2012r2-64.qcow2-copy-from-auto,if=none,id=disk1,
> format=qcow2 \
> -device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=100,lun=0,bootindex=0 \
> -boot menu=on -monitor stdio -vnc :2 \
> -drive
> file=/dev/disk/by-path/ip-10.66.9.10:3260-iscsi-iqn.2013-11.com.example:
> storage.disk1.juli.xyz-lun-2,if=none,id=disk2 \
> -device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=0,lun=0,bootindex=3 -S
> 2.check the boot order in seabios.
> Press F12 for boot menu.
> 3.
> 
> Actual results:
> sys-disk2 is the first disk and sys-disk1 is the second disk when press F12.
> Such as:
> 1. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
> 2. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
> ...
> 
> Expected results:
> the order of the boot device in seabios should the same to we specified the
> bootindex in qemu-kvm command line.
> 
> Additional info:
You should specify the scsi-id and lun value for your system disk smaller than your data disk if you want to boot from the bootinde=0 disk, as the scsi-id and lun value has specify meaning for virtio-scsi here. I think this should not a bug.
e.g.: scsi-id=0,lun=0 for your system disk, scsi-id=1,lun=0 for your data disk.
The seabios can just detest the lun=0 for disk currently.

Best Regards,
sluo

Comment 6 Ronen Hod 2014-05-14 08:39:32 UTC
Sibiao and Jun,
I am impressed!
Are you going to close this bug?

Comment 7 Sibiao Luo 2014-05-14 09:57:36 UTC
(In reply to Ronen Hod from comment #6)
> Sibiao and Jun,
> I am impressed!
> Are you going to close this bug?

Could you help make sure it, as comment #2 and comment #5 just my opinion. Thanks in advance.

Best Regards,
sluo

Comment 8 Paolo Bonzini 2014-05-14 10:04:20 UTC
The reason why both virtio-scsi disks come first, is that drives with a bootindex always come before drives without a bootindex.  Since you had no drive with indexes 1 and 2, the two SCSI disks were placed first.

Comment 9 Jun Li 2014-05-23 05:17:42 UTC
(In reply to Paolo Bonzini from comment #8)
> The reason why both virtio-scsi disks come first, is that drives with a
> bootindex always come before drives without a bootindex.  Since you had no
> drive with indexes 1 and 2, the two SCSI disks were placed first.

Hi Paolo,

  In comment #0, I just want to say:

-device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=100,lun=0,bootindex=0 \
...
-device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=0,lun=0,bootindex=3

------
  As above show, sys-disk1 with bootindex=0, sys-disk2 with bootindex=3. So we should see sys-disk1 before sys-disk2 when Press F12. But actually, we will see sys-disk2 before sys-disk1.

  Why hit above issue? I just find "scsi-id" causing this issue. When set scsi-id of sys-disk1 (with 100) larger than scsi-id of sys-disk2(with 0), bootindex will not effect. 

  Could you give some explanation? If you think this is not a bug, please close it. Thx.


Best Regards,
Jun Li

Comment 10 Jun Li 2014-06-11 13:01:06 UTC
(In reply to Paolo Bonzini from comment #8)
> The reason why both virtio-scsi disks come first, is that drives with a
> bootindex always come before drives without a bootindex.  Since you had no
> drive with indexes 1 and 2, the two SCSI disks were placed first.

Hi Paolo,

  I think you have misunderstand my original meaning(comment #0 and comment #9), so I want to reopen this bz. When you have time, please help me to double-check this issue. Thank you very much.

   
Best regards,
Jun Li

Comment 12 Ronen Hod 2014-07-28 21:25:20 UTC
Moving to Ademar, as this is mostly related to storage.

Comment 14 Markus Armbruster 2014-07-31 09:26:55 UTC
I know nothing about the interplay of SeaBIOS, virtio-scsi and
bootindex.  That's okay, I can figure it out.  But before I spend time
on that: Paolo, do you have anything to reply to comment#10?

Comment 15 Markus Armbruster 2014-08-12 14:53:08 UTC
Laszlo helped me understand this stuff better, thanks much!

Jun Li, I think you're right, this is a bug.  qemu-kvm formats the
SCSI ID in hex when building the Open Firmware device path.  SeaBIOS
formats in decimal.  Bootorder list entries with a SCSI ID > 9 aren't
found by SeaBIOS (lucky case), or attributed to the wrong device
(unlucky case).

Working on an upstream fix.

Comment 16 Markus Armbruster 2014-08-13 12:26:29 UTC
Please try my scratch brew of SeaBIOS[*], and let me know whether it
fixes the bug for you.

Additionally, please try to reproduce the bug under RHEL-6.  I suspect
that's broken, too.  If it is, clone the bug and assign it straight to
me.

[*] http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7838459

Comment 17 Jun Li 2014-08-14 02:48:41 UTC
(In reply to Markus Armbruster from comment #16)
> Please try my scratch brew of SeaBIOS[*], and let me know whether it
> fixes the bug for you.
> 
> Additionally, please try to reproduce the bug under RHEL-6.  I suspect
> that's broken, too.  If it is, clone the bug and assign it straight to
> me.
> 
> [*] http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7838459

Retest with http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7838459.

Version of components:
# rpm -qa|grep seabios && rpm -qa|grep qemu-kvm-rhev
seabios-1.7.2.2-12.el7_0.test.x86_64
seabios-bin-1.7.2.2-12.el7_0.test.x86_64
qemu-kvm-rhev-1.5.3-60.el7ev.x86_64
qemu-kvm-rhev-debuginfo-1.5.3-60.el7ev.x86_64

Steps as comment #0:
1.boot guests using following cli:
/usr/libexec/qemu-kvm -m 2G \
-device virtio-scsi-pci,id=scsi0 \
-drive file=/mnt/windows_img/win2012-64-virtio.qcow2,if=none,id=disk1,format=qcow2,snapshot=on \
-device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=100,lun=0,bootindex=0 \
-boot menu=on -monitor stdio -vnc :2 \
-drive file=/mnt/linux_img/RHEL-Server-7.0-64.qcow2,if=none,id=disk2,snapshot=on \
-device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=0,lun=0,bootindex=3 -S
2.check the boot order in seabios.
Press F12 for boot menu.
3.

Actual results:
sys-disk1 is the first disk and sys-disk2 is the second disk when press F12.
Such as:
1. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
2. virtio-scsi Drive QEMU QEMU HARDDISK 1.5.
...

Above test result is our expired.

Hi Markus,

  Also test this issue on rhel6, it has the same issue, too. I will clone a bz on rhel 6. Thx.

Best Regards,
Jun Li

Comment 18 Markus Armbruster 2014-08-15 15:20:43 UTC
Thanks, Jun Li!

Comment 20 langfang 2014-11-07 06:37:49 UTC
Reproduce this bug as follow version:
Host:
# uname -r
3.10.0-191.el7.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-2.1.2-6.el7.x86_64
# rpm -q seabios
seabios-1.7.5-4.el7.x86_64


Steps:
1.Boot guest with
..-drive file=/home/RHEL-Server-7.0-64-virtio.qcow2,if=none,id=disk1,format=qcow2 -device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=100,lun=0,bootindex=0 -boot menu=on -monitor stdio -vnc :2 -drive file=/home/win2012-64-virtio.qcow2,if=none,id=disk2 -device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=0,lun=0,bootindex=3..


Results: guest boot up from the "bootindex=3" imag.

Verify this bug as follow version:

# uname -r
3.10.0-191.el7.x86_64
# rpm -q qemu-kvm-rhev
qemu-kvm-rhev-2.1.2-6.el7.x86_64
# rpm -q seabios
seabios-1.7.5-5.el7.x86_64

Steps as same as reproduce

Resutls:

Guest boot up from "bootindex=0" imag, work well


Addtional info: Tried boot guest with other values of "scsi-id" ,work well
..-device scsi-hd,drive=disk1,id=sys-disk1,scsi-id=101,lun=0,bootindex=0 ...-device scsi-hd,drive=disk2,id=sys-disk2,scsi-id=002,lun=0,bootindex=3


According to above test ,this bug has been fixed.

Comment 23 errata-xmlrpc 2015-03-05 08:15:20 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://rhn.redhat.com/errata/RHBA-2015-0345.html


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