Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Okay, that did not work so well. Would someone please delete the first entry? Dear Qemu-kvm developers, I am a system builder (among other things). Would of out intrepid heroes please fix this bug for me? This affects my business and Windows 10 install from DVD drives in considerable slower and requires I include a DVD drive with new system builds or go find an even slower USB DVD drive. I am unable to create a Windows 10 installation USB flash drive with EUFI and GPT support with Rufus using qemu-kvm and either of my Windows 10, Windows 7 or Windows XP virtual machines. Please note that Rufus is the ONLY utility that can properly create these drives. There is no equivalent in Linux (wish there was) and Rufus does not run under Wine Staging. Windows 10 and Windows 7 cut 3/4 of the way through and then crashes Rufus; Windows XP will create the the drive, but the drive when booted will start the Windows 10 installed but stop and ask for a missing driver, means the drive did not create properly (one of those weird M$ error messages that means something else). Running Rufus from a temporary Windows 10 Professional build 1709 machine I had on hand to be delivered to a customer worked perfectly. The particulars: $ cat /etc/redhat-release Fedora release 27 (Twenty Seven) $ uname -r 4.14.8-300.fc27.x86_64 $ rpm -qa qemu\* qemu-system-x86-2.10.1-2.fc27.x86_64 qemu-common-2.10.1-2.fc27.x86_64 qemu-block-dmg-2.10.1-2.fc27.x86_64 qemu-kvm-2.10.1-2.fc27.x86_64 qemu-block-nfs-2.10.1-2.fc27.x86_64 qemu-system-x86-core-2.10.1-2.fc27.x86_64 qemu-block-gluster-2.10.1-2.fc27.x86_64 qemu-img-2.10.1-2.fc27.x86_64 qemu-block-rbd-2.10.1-2.fc27.x86_64 qemu-block-curl-2.10.1-2.fc27.x86_64 qemu-block-iscsi-2.10.1-2.fc27.x86_64 qemu-guest-agent-2.10.1-2.fc27.x86_64 qemu-block-ssh-2.10.1-2.fc27.x86_64 Windows 7 Professional, Service Pack 1, 64 bit Windows 10 Professional, Build 1709, 64 bit Windows XP Professinoal, Service pack 3, 32 bit rufus-2.18.exe rufus-2.18-portable.exe https://rufus.akeo.ie/ Windows 10 Build 1709 ISO: https://www.microsoft.com/en-us/software-download/windows10ISO Select the 64 bit profession version. To reproduce, 1) insert a 4+ GB Flash drive in a USB port and tell Virt-manager to use it in any of the above Windows VM's. W10 or W7 preferred. (The USB port may have to be a bootable USB port, but I haven't verified it.) 2) download the ISO from M$'s site above from Linux. Place the ISO in a directory that can be seen from any of the above Windows VM's: desktop or network drive. 3) download and fire up Rufus on any of the above Windows VM's. 4) Rufus: a) attach the IOS b) select "GTP partition scheme for EUFI" c) select "FAT 32" 5) select "start" and watch the blinking lights Many thanks, -T
A colleague told me that he is able to create Rufus Windows 10 USB flash drive of this type on his VM, which is virtual box.
I tried with - Up to date Fedora 27 host - Win10 Enterprise VM - Win10 enterprise iso image (I couldn't find how to download an iso from the link you provided) - rufus 2.18 portable - USB drive attached to the VM via spice USB redirection (attach device, virt-manager Virtual Machine->Redirect USB Device) - The rufus options you mentioned It completed fine for me. Please attach /var/log/libvirt/qemu/VMNAME.log
Created attachment 1378267 [details] /var/log/libvirt/qemu/VMNAME.log
(In reply to Cole Robinson from comment #3) > I tried with > > - Up to date Fedora 27 host > - Win10 Enterprise VM > - Win10 enterprise iso image (I couldn't find how to download an iso from > the link you provided) > - rufus 2.18 portable > - USB drive attached to the VM via spice USB redirection (attach device, > virt-manager Virtual Machine->Redirect USB Device) > - The rufus options you mentioned > > It completed fine for me. > > Please attach /var/log/libvirt/qemu/VMNAME.log You got it. Just did. You forgot to see if the usb drive would boot afterwards! :'( If it makes it through the custom set up and to the drive format/selection, then it works. (Stop at that point or your will ruin your drive.) Okay, I did my update a few days ago, so I was able to reproduce what you saw. W10 did cut the drive all the way through this time. The drive was useless afterwards, but this time Rufus did complete. When attempting to boot off the newly created flash drive, the boot loader was recognized, then the screen went black and froze. This happened when booting the flash drive as either a EUFI drive or a standard drive. > - Win10 enterprise iso image (I couldn't find how to download an iso from > the link you provided) Ya, I am glad I am not the only one. M$'s web sites can be a thing to behold at times. 1) open Firefox in Fedora 2) go to https://www.microsoft.com/en-us/software-download/windows10ISO 3) go to the section called "Select Edition", use the down arrow to select "Windows 10" (not the creators edition) and press confirm 4) go to "Select the product language" and select "English" and press confirm 5) go to "Windows 10 English" abnd select "64 bit download". Save it somewhere your VM can get at it. > - USB drive attached to the VM via spice USB redirection (attach device, > virt-manager Virtual Machine->Redirect USB Device) Maybe we are using different Virt-Managers. I have three "USB Redirects" and all three are "Spice VMC". And none of them import flash drives into my VM. In virtual machine manager, I have to 1) light bulb 2) +add hardware 3) USB Host Device 4) pick out he flash drive I want to write to One problem down, one to go! Thank you for the help!
Your log has some evidence of USB errors, but not sure specifically what it means: 2018-01-07T06:14:08.632162Z qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/2-4.2/bConfigurationValue failed ret=-1 errno=2 ehci warning: guest updated active qTD ehci warning: guest updated active QH FWIW my USB device does seem to work, I managed to UEFI boot into the windows installer. From the VM window where you interact with the windows graphical console, see the 'Virtual Machine' menu item at the top. That's where you'll find the 'Redirect USB Device' option. Give that a try instead of direct USB assignment, might not make a difference but worth seeing. Also worth trying a different brand USB device if you have it, maybe it's something specific to the device
(In reply to Cole Robinson from comment #6) > Your log has some evidence of USB errors, but not sure specifically what it > means: > > 2018-01-07T06:14:08.632162Z qemu-system-x86_64: libusb_release_interface: -4 > [NO_DEVICE] > libusb: error [_open_sysfs_attr] open > /sys/bus/usb/devices/2-4.2/bConfigurationValue failed ret=-1 errno=2 > ehci warning: guest updated active qTD > ehci warning: guest updated active QH I have a bad usb3 add on card in the system I have not yet removed. I wonder if that is what you are seeing? (I am using the native USB2 ports, as they are they only ones that work and are bootable.) > > FWIW my USB device does seem to work, I managed to UEFI boot into the > windows installer. Good news! > From the VM window where you interact with the windows graphical console, > see the 'Virtual Machine' menu item at the top. That's where you'll find the > 'Redirect USB Device' option. Give that a try instead of direct USB > assignment, might not make a difference but worth seeing. Also worth trying > a different brand USB device if you have it, maybe it's something specific > to the device I will test in a bit. Thank you!
Okay it cut using the 'Redirect USB Device' option, but it is not recognized at a boot device on qemu-qvm, so I will have to try it natively and possibly on another machine that supports EUFI (this one does not). It should hvae access to a EUFI based machine something tomorrow evening.
(In reply to Todd from comment #8) > Okay it cut using the 'Redirect USB Device' option, but it is not recognized > at a boot device on qemu-qvm, so I will have to try it natively and possibly > on another machine that supports EUFI (this one does not). It should hvae > access to a EUFI based machine something tomorrow evening. The symptom when trying to boot off teh flash drive in a EUFI machine is exactly the same. RATS.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.