Bug 833675
Summary: | make "Boot from USB" test (ms hardware certification kit) work | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Mike Cao <bcao> |
Component: | qemu-kvm-rhev | Assignee: | Gerd Hoffmann <kraxel> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | areis, juzhang, knoel, kraxel, lijin, michen, mkenneth, mrezanin, rbalakri, rpacheco, virt-maint, wyu |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-rhev-2.3.0-31.el7.x86_64 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-06 05:20:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mike Cao
2012-06-20 06:47:25 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. (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 Not sure, gleb? (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? (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 What is the use case? How about simply unplugging the usb stick? (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. (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 ... 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 (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. > 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?
(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 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. (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? > 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).
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 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. (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 #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. (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? wyu,pls retest this job according to comment#34 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 (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. (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 ;) Yes, it is fixed with 7.2 package. Closing. |