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 833675 - make "Boot from USB" test (ms hardware certification kit) work
Summary: make "Boot from USB" test (ms hardware certification kit) work
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-20 06:47 UTC by Mike Cao
Modified: 2016-05-06 05:20 UTC (History)
12 users (show)

Fixed In Version: qemu-kvm-rhev-2.3.0-31.el7.x86_64
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-06 05:20:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Mike Cao 2012-06-20 06:47:25 UTC
Description of problem:


Version-Release number of selected component (if applicable):
2.6.32-278.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6.x86_64
seabios-0.6.1.2-19.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Try to specify boot from usb first in -boot 
2.after guest boot up with usb,try to change the boot order in (qemu)boot_set

  
Actual results:
can not specify the boot from usb above 

Expected results:
Those should be supported

Additional info:
Upstream qemu-kvm hit the same issue .

Comment 2 Gerd Hoffmann 2012-07-03 10:25:12 UTC
-boot is obsoleted by the bootindex property, which works just fine for usb, please use that instead.

bootindex was added exactly because -boot has limitations which can't be fixed easily given the -boot syntax.

Comment 3 Mike Cao 2012-07-03 11:37:00 UTC
(In reply to comment #2)
> -boot is obsoleted by the bootindex property, which works just fine for usb,
> please use that instead.
> 
> bootindex was added exactly because -boot has limitations which can't be
> fixed easily given the -boot syntax.

Hi, Gerd 

Any other workaround  about to change boot order via (qemu)boot_set ?

Thanks,
Mike

Comment 4 Gerd Hoffmann 2012-07-03 13:35:23 UTC
Not sure, gleb?

Comment 5 Gleb Natapov 2012-07-03 14:27:28 UTC
(In reply to comment #4)
> Not sure, gleb?

Unfortunately not. We need to make bootindex property changable from a monitor. Is there standard way to change device propertoes from qemu monitor?

Comment 6 Mike Cao 2012-07-04 03:16:35 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Not sure, gleb?
> 
> Unfortunately not. We need to make bootindex property changable from a
> monitor. Is there standard way to change device propertoes from qemu monitor?

I still suggest we need a way to change boot from usb in hmp or qmp w/o shutdown the guest ,
Re-open this bug

Comment 7 Gerd Hoffmann 2012-07-05 09:49:37 UTC
What is the use case?
How about simply unplugging the usb stick?

Comment 8 Mike Cao 2012-07-17 03:17:37 UTC
(In reply to comment #7)
> What is the use case?

According to comment #5 ,seems Gleb means we can "make bootindex property changable from a monitor".And floppy ,disk ,cdrom both works when I using (qemu)boot_set  ,So I suggest we can add usb device in (qemu)boot_set .


> How about simply unplugging the usb stick?

I did not get this ,
After hot-unplug the usb-stick ,we still can not choose boot from usb disk unless we quit the qemu-kvm process and change the qemu-kvm commandline.

Comment 9 Gerd Hoffmann 2012-07-17 07:06:04 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > What is the use case?
> 
> According to comment #5 ,seems Gleb means we can "make bootindex property
> changable from a monitor".And floppy ,disk ,cdrom both works when I using
> (qemu)boot_set  ,So I suggest we can add usb device in (qemu)boot_set .

Even if possible it isn't a trivial change.
Thats why I'm asking what you want use it for.

> > How about simply unplugging the usb stick?
> 
> I did not get this ,
> After hot-unplug the usb-stick ,we still can not choose boot from usb disk
> unless we quit the qemu-kvm process and change the qemu-kvm commandline.

Original description sounds like you are first booting from usb (install from usb key?), then want boot from hard disk.  In that case just removing the usb stick (via device_del) after the installation completed will work just fine ...

Comment 10 Mike Cao 2012-07-17 07:18:26 UTC
Actually ,I want to a(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > What is the use case?
> > 
> > According to comment #5 ,seems Gleb means we can "make bootindex property
> > changable from a monitor".And floppy ,disk ,cdrom both works when I using
> > (qemu)boot_set  ,So I suggest we can add usb device in (qemu)boot_set .
> 
> Even if possible it isn't a trivial change.
> Thats why I'm asking what you want use it for.
> 
> > > How about simply unplugging the usb stick?
> > 
> > I did not get this ,
> > After hot-unplug the usb-stick ,we still can not choose boot from usb disk
> > unless we quit the qemu-kvm process and change the qemu-kvm commandline.
> 
> Original description sounds like you are first booting from usb (install
> from usb key?), then want boot from hard disk.  In that case just removing
> the usb stick (via device_del) after the installation completed will work
> just fine ...

I remember the reason to report this bug :)
I am testing win8 system test on MS hardware certification kit ,there is a new job named "Boot from USB", everytime the job copied the installation related file to the USB ,then failed to reboot .which cause job the job failed.
What I want to do use (qemu)boot_set to change usb as the first boot_order to see whether it is HCK issue or our qemu-kvm issue .
But now I think I needn't test win8 due to it is not part of SVVP

Comment 11 Gleb Natapov 2012-07-17 07:21:24 UTC
(In reply to comment #10)
> Actually ,I want to a(In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > What is the use case?
> > > 
> > > According to comment #5 ,seems Gleb means we can "make bootindex property
> > > changable from a monitor".And floppy ,disk ,cdrom both works when I using
> > > (qemu)boot_set  ,So I suggest we can add usb device in (qemu)boot_set .
> > 
> > Even if possible it isn't a trivial change.
> > Thats why I'm asking what you want use it for.
> > 
> > > > How about simply unplugging the usb stick?
> > > 
> > > I did not get this ,
> > > After hot-unplug the usb-stick ,we still can not choose boot from usb disk
> > > unless we quit the qemu-kvm process and change the qemu-kvm commandline.
> > 
> > Original description sounds like you are first booting from usb (install
> > from usb key?), then want boot from hard disk.  In that case just removing
> > the usb stick (via device_del) after the installation completed will work
> > just fine ...
> 
> I remember the reason to report this bug :)
> I am testing win8 system test on MS hardware certification kit ,there is a
> new job named "Boot from USB", everytime the job copied the installation
> related file to the USB ,then failed to reboot .which cause job the job
> failed.
> What I want to do use (qemu)boot_set to change usb as the first boot_order
> to see whether it is HCK issue or our qemu-kvm issue .
> But now I think I needn't test win8 due to it is not part of SVVP
run qemu with -no-reboot and after it exists start it with desirable bootindex config.

Comment 12 Gerd Hoffmann 2012-07-17 09:39:57 UTC
> I am testing win8 system test on MS hardware certification kit ,there is a
> new job named "Boot from USB", everytime the job copied the installation
> related file to the USB ,then failed to reboot .which cause job the job
> failed.

How is this supposed to work on real hardware?
Fully automatic?
Or with manual invention to pick usb in the bios boot menu?

Comment 13 Mike Cao 2012-07-23 07:17:36 UTC
(In reply to comment #12)
> > I am testing win8 system test on MS hardware certification kit ,there is a
> > new job named "Boot from USB", everytime the job copied the installation
> > related file to the USB ,then failed to reboot .which cause job the job
> > failed.
> 
> How is this supposed to work on real hardware?
> Fully automatic?
> Or with manual invention to pick usb in the bios boot menu?

Hi, Gerd 

Not sure whether they need to press F12 to choose boot from usb manually.

As I mentioned comment #8 , We needn't test win8 due to it is not part of SVVP. And windows 2012 SVVP test did not conclude this test(boot from usb).

So feel free to close it if you think there are risks to fix this bug

Comment 14 Gerd Hoffmann 2012-08-06 08:38:42 UTC
Ok, lets leave rhel6 alone when there is no urgent need and move to rhel7 so it doesn't fall off the radar.

I still like to know how the boot-from-usb testcase is supposed to work on real hardware as the best way to fix this kind of issues is to make qemu work like real hardware does instead of working around the problem with some monitor command.

Comment 15 Mike Cao 2012-08-06 09:48:49 UTC
(In reply to comment #14)
> Ok, lets leave rhel6 alone when there is no urgent need and move to rhel7 so
> it doesn't fall off the radar.
> 
> I still like to know how the boot-from-usb testcase is supposed to work on
> real hardware as the best way to fix this kind of issues is to make qemu
> work like real hardware does instead of working around the problem with some
> monitor command.

I think we need to wait until some hardware vendor got win8 logo for their bare-metal . btw ,Is it possible to use application to switch the bootindex for bare-metal instead of using bios or press F12 during host boot?

Comment 16 Gerd Hoffmann 2012-08-06 10:01:30 UTC
> Is it possible to use application to switch the bootindex
> for bare-metal instead of using bios or press F12 during host boot?

I don't think so, at least with the classic BIOS (which seabios emulates).
Maybe it is possible with UEFI.

Could also be that the boot order must be configured to have USB first, then expect the BIOS to skip devices without boot sector (such as a blank usb stick).

Comment 17 Mike Cao 2012-10-19 09:15:39 UTC
I found that I pass bootindex=1 to usb storage , bootindex=2 to system image (ide) ,bootindex=3 to cdrom .After the boot data in usb storage erased ,guest always boot from cdrom .Press F12 it shows the right order .

CLI: /usr/libexec/qemu-kvm  -m 16G -smp 8 -boot menu=on -cpu Nehalem,+x2apic,family=0xf -usb -device usb-tablet -drive file=win2012-64-sut.raw,format=raw,if=none,id=drive-ide0,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-ide0,bootindex=2,id=ide-drive0 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet0,mac=00:52:43:75:51:01,bus=pci.0,addr=0x4,id=virtio-net-pci0 -uuid a19b1188-7550-448b-908b-75980afea207 -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/sut-2012,server,nowait -mon chardev=111a,mode=readline -name win2k8-R2-sut -vnc :2 -drive file=en_windows_server_2012_x64_dvd_915478.iso,media=cdrom,id=cdrom,if=none -device ide-drive,drive=cdrom,bootindex=3 -monitor stdio -netdev tap,sndbuf=0,id=hostnet1,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet1,mac=00:52:00:43:51:01,bootindex=4,bus=pci.0,addr=0x9,id=virtio-net-pci1 -device usb-ehci,id=usb-uhci0 -drive file=usb.img,format=raw,if=none,werror=stop,rerror=stop,id=usb -device usb-storage,bootindex=1,drive=usb,bus=usb-uhci0.0,removable=on,serial="1234-123-232",create_unique_serial=1

Comment 18 Gerd Hoffmann 2012-10-19 09:18:07 UTC
usb stick prepared by boot-from-usb test:

rincewind kraxel ~/tmp/bz867214# fdisk -l gerd_usb.img 
You must set cylinders.
You can do this from the extra functions menu.

Disk gerd_usb.img: 0 MB, 0 bytes
191 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 12033 * 512 = 6160896 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

       Device Boot      Start         End      Blocks   Id  System
gerd_usb.img1   *           1          86      512000    b  W95 FAT32
Partition 1 has different physical/logical endings:
     phys=(63, 190, 63) logical=(85, 20, 63)

usb stick after windows cleared it:

rincewind kraxel ~/tmp/bz867214# fdisk -l stick.raw 
You must set cylinders.
You can do this from the extra functions menu.

Disk stick.raw: 0 MB, 0 bytes
16 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfb7ed55d

    Device Boot      Start         End      Blocks   Id  System
stick.raw1               1        1039      523200    7  HPFS/NTFS
Partition 1 has different physical/logical endings:
     phys=(1023, 15, 63) logical=(1038, 3, 35)

So the stick has a valid partition table, with a single partition, which is *not* tagged as bootable.

Maybe the windows test expects the bios skip sticks in case there is no bootable partition.

Comment 19 Mike Cao 2012-10-19 09:21:42 UTC
(In reply to comment #18)
> usb stick prepared by boot-from-usb test:
> 
> rincewind kraxel ~/tmp/bz867214# fdisk -l gerd_usb.img 
> You must set cylinders.
> You can do this from the extra functions menu.
> 
> Disk gerd_usb.img: 0 MB, 0 bytes
> 191 heads, 63 sectors/track, 0 cylinders
> Units = cylinders of 12033 * 512 = 6160896 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
> 
>        Device Boot      Start         End      Blocks   Id  System
> gerd_usb.img1   *           1          86      512000    b  W95 FAT32
> Partition 1 has different physical/logical endings:
>      phys=(63, 190, 63) logical=(85, 20, 63)
> 
> usb stick after windows cleared it:
> 
> rincewind kraxel ~/tmp/bz867214# fdisk -l stick.raw 
> You must set cylinders.
> You can do this from the extra functions menu.
> 
> Disk stick.raw: 0 MB, 0 bytes
> 16 heads, 63 sectors/track, 0 cylinders
> Units = cylinders of 1008 * 512 = 516096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xfb7ed55d
> 
>     Device Boot      Start         End      Blocks   Id  System
> stick.raw1               1        1039      523200    7  HPFS/NTFS
> Partition 1 has different physical/logical endings:
>      phys=(1023, 15, 63) logical=(1038, 3, 35)
> 
> So the stick has a valid partition table, with a single partition, which is
> *not* tagged as bootable.
> 
> Maybe the windows test expects the bios skip sticks in case there is no
> bootable partition.


Hi, Gerd 

I mean the 2nd bootindex does not work if usb storage is not a bootable device .
From the scenario I described ,I think guest should boot from harddisk instead of cdrom

Comment 30 lijin 2014-02-07 03:31:27 UTC
comment #26 is the detailed/expected steps of the svvp job.
In other jobs we usually set system disk bootindex=1,when guest comes to this "Boot from USB" job,it will start the step 1 and step 2 of comment #26.In order to follow step 3,we must manually change the boot order,that's why bcao reopen the bug to request a way to change the order through qemu command without shutdown the guest.

Comment 31 Gerd Hoffmann 2014-02-17 08:10:35 UTC
(In reply to lijin from comment #30)
> comment #26 is the detailed/expected steps of the svvp job.
> In other jobs we usually set system disk bootindex=1,when guest comes to
> this "Boot from USB" job,it will start the step 1 and step 2 of comment
> #26.In order to follow step 3,we must manually change the boot order,that's
> why bcao reopen the bug to request a way to change the order through qemu
> command without shutdown the guest.

Ok, so the qemu test procedure actually is step 1+2 -- change boot order -- steps 3+4+5 -- change boot order -- step 6.

How does that test work on real hardware?  I suspect it's fully automatic and works *without* changing the boot order in the bios setup?

Comment 35 lijin 2015-10-28 03:23:49 UTC
wyu,pls retest this job according to comment#34

Comment 36 Yu Wang 2015-10-30 09:44:35 UTC
Retest this issue on RHEL7 with qemu-kvm-rhev-2.3.0-31.el7.x86_64 , boot order can be changed succesfully by using "qom-set $deviceid bootindex $nr" and it can boot to USB first.

But according comment #0, this bug was created on RHEL6 
QE tried "qom-set" on qemu-kvm-rhev-0.12.1.2-2.479.el6.x86_64 for RHEL6, but there is no qom-set command on hmp. We also tried "boot_set" command, but don't know how to change bootorder to USB first.

Please tell me ,how to use "boot_set " or other command change boot to usb first on RHEL6?


Thanks
wyu

Comment 37 Gerd Hoffmann 2015-10-30 10:08:08 UTC
(In reply to wangyu from comment #36)
> Retest this issue on RHEL7 with qemu-kvm-rhev-2.3.0-31.el7.x86_64 , boot
> order can be changed succesfully by using "qom-set $deviceid bootindex $nr"
> and it can boot to USB first.
> 
> But according comment #0, this bug was created on RHEL6 
> QE tried "qom-set" on qemu-kvm-rhev-0.12.1.2-2.479.el6.x86_64 for RHEL6, but
> there is no qom-set command on hmp. We also tried "boot_set" command, but
> don't know how to change bootorder to USB first.
> 
> Please tell me ,how to use "boot_set " or other command change boot to usb
> first on RHEL6?

Bug has been moved to rhel7 at some point because it's unlikely it'll be fixed in RHEL-6.  The upstream fix which we have in RHEL-7 now can't be backported to RHEL-6 because the infrastructure needed isn't present in that old qemu version.

So, it works on RHEL-7 only.

Comment 40 Gerd Hoffmann 2016-04-15 11:10:02 UTC
(In reply to Gerd Hoffmann from comment #37)
> (In reply to wangyu from comment #36)
> > Retest this issue on RHEL7 with qemu-kvm-rhev-2.3.0-31.el7.x86_64 , boot
> > order can be changed succesfully by using "qom-set $deviceid bootindex $nr"
> > and it can boot to USB first.

Ok, so we are done ;)

Comment 42 Miroslav Rezanina 2016-05-06 05:20:27 UTC
Yes, it is fixed with 7.2 package. Closing.


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