Glen H:
> On Monday, February 19, 2018 at 1:05:09 AM UTC-5, Yuraeitha wrote:
>> On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote:
>>> On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote:
>>>> On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
>>>>> Hi,
>>>>> I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. 
>>>>>  I have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
>>>>> installed Qubes I used the Dell recovery tool to create a recovery usb 
>>>>> disk for Win7 to re-install the OS but I'm not sure if this is usable to 
>>>>> install with Qubes.
>>>>> I tried following the instructions on the Qubes website by creating a new 
>>>>> Qube without a template but I could not change it from PVM to HVM.  Then 
>>>>> when I tried booting from the USB recovery disk it would load up a 
>>>>> terminal and then exit after 10 seconds.
>>>>> When I try to boot the recovery USB disk from the main BIOS it boots up 
>>>>> fine.  Does anyone have any tips for installing Win7 in Qubes 4?
>>>>> Thanks,
>>>>> Glen
>>>> Hi,
>>>> Check out these two issues:
>>>> Installing Windows 7:
>>>> Installing Qubes Windows Tools: 
>>>> The two problems you describe in the post seem to be the following:
>>>> 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
>>>> 2. Make sure you set the video-model to cirrus for install.
>>>> Best,
>>>> Daniel
>>> Hi,
>>> Thanks for the tips Daniel.  I'm stuck at not being able to boot from the 
>>> usb disk.  I am doing:
>>> ```
>>> qvm-create --class StandaloneVM --label red win7new
>>> qvm-prefs win7new virt_mode hvm
>>> qvm-prefs win7new memory 4000
>>> qvm-prefs win7new maxmem 4000
>>> qvm-prefs win7new kernel ''
>>> qvm-volume extend win7new:root 25g
>>> qvm-prefs win7new debug True
>>> qvm-features win7new video-model cirrus
>>> # Then attach usb drive to untrusted, but all of these fail to boot:
>>> qvm-start --hddisk untrusted:sda win7new
>>> qvm-start --hddisk untrusted:sda1 win7new
>>> qvm-start --hddisk untrusted:/dev/sda win7new
>>> qvm-start --hddisk untrusted:/dev/sda1 win7new
>>> ```
>>> I'm not sure whether to use the whole drive (no name) or the first 
>>> partition (named DELLRESTORE)...but I tried both.
>>> I get the error message in the win7new terminal:
>>> ```
>>> SeaBIOS (version ...)
>>> Machine UUID ...
>>> Booting from Hard Disk...
>>> Boot failed: not a bootable disk
>>> Booting from Floppy...
>>> Boot failed: could not read the boot disk
>>> No bootable device.
>>> ```
>>> So it seems that it doesn't recognize the USB drive as bootable even though 
>>> I can boot it from the main BIOS (in legacy mode).  
>>> Any help would be appreciated.
>>> Glen
>> First, welcome to the Qubes community! :)
>> A few things first, starting to use Qubes can be a bit overwhelming, but 
>> you'll get the hang of it over time if you keep using it. For starters, look 
>> here in the command you use "untrusted:sda" which is something Qubes 
>> exclusive and you therefore had no chance knowing this. Untrusted, is a word 
>> that needs replacing for whichever untrusted AppVM you're using to hold your 
>> USB or SATA controllers. It's called untrusted because dom0 is trusted, and 
>> you need to use an less untrusted domain that doesn't compromise your more 
>> trusted domain, dom0. This is a bit tricky for new users to catch on, on, as 
>> it's ambiguity for new users, at best. To solve this, then you first need to 
>> figure out where your controller is located. If you have no sys-usb or 
>> similar, then it's likely still in dom0. It's insecure to keep this in the 
>> secure dom0 domain, but mostly you should be fine for some time yet if 
>> you're not a high target profile, and never leave your computer unattended 
>> in public or near people you don't trust with your life. Still, having it in 
>> dom0 is still more secure than not using Qubes. Just keep in mind you 
>> eventually want to migrate away from using dom0 for anything, but it's not 
>> always easy just yet due to some fixes and hardwares require you still 
>> manually manage dom0 from time to time, so it's not yet entirely a users 
>> responsibility, as there are still times when you need to use dom0.
>> So if your USB or SATA controllers are in dom0 (Your SATA controllers will 
>> be if you did not move them yourself, and USB controllers depend on your 
>> hardware, the installer might or might not have done it automatically). If 
>> you don't have a sys-usb VM, then it's probably still in dom0. 
>> I don't know your current knowledge on Linux, so I'll take the liberty to 
>> add more details just in case.
>> In conclusion from the above, instead of untrusted, it should look like this 
>> dom0:sda for dom0, and sys-usb:sda for sys-usb, whereever that controller is 
>> located.
>> further, sda may look like sdb, sdc, or if adding partitins, like sdb2 or 
>> sdf4.
>> It's kind of like C:/ in windows, followed by d:/ for your DVD drive, on 
>> most machines. Instead it's "sd" followed by a,b,c,d,e,f, etc. 
>> The reason it's typically starting with "sda" when the AppVM has partitions 
>> on its own, is because they are named "xvd" followed by a,b,c,d,e,f, etc. 
>> instead of "sd" for normal physical devices. Open up the AppVM in question, 
>> and run "lsblk" to get a printout of all your "/dev/xvd's" and "/dev/sdx's". 
>> Remember whereever that USB controller is located, you need to use that 
>> yellowish GUI widget up in the upper corner (only available in Qubes 4 
>> onwards), to move an USB port to any other AppVM, where your iso/image 
>> recovery file is located. 
>> Then you should be able to fix the command so that it works, knowing these 3 
>> things.
>> As for the boot that doesn't work, why are you using this flag --hddisk 
>> instead of the --cdrom flag? Is this an assumption based decision or a guide 
>> you followed? This flag "might" be an additional reason that it's not 
>> booting. For image files, like your recovery medium should boot up with the 
>> --cdrom (it's an img or iso format file right? or is it a special format?).
>> Should look like this, just like in the link up above provided by Daniel.
>> qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
>> Does using --cdrom flag, make any progress?
>> It might also be neat to know which recovery tool you used, and what format 
>> it puts your recovery backup in?
>> As for the conversion of an existing image file, well, I've seen various 
>> transfers from different virtual machines before, although not seen many. I 
>> do believe that I've seen an image file taken directly from a drive, and so 
>> too are the ones coming from VirtualBox. But by the word convert here, I 
>> really mean I don't know any details, just that I've seen the topic 
>> headlines briefly, and it was quite a while ago. For all I know, it could be 
>> no big deal, or really messy. I just know I've seen the topic headlines 
>> before. But I've also yet to see one where it wasn't possible to 
>> transfer/convert over though. In my anecdotal perspective on this matter, 
>> odds seems to be that it might work, though maybe with needed some 
>> work-arounds. I might look into this later today in order to learn more, 
>> I'll post if I learn anything new that might be useful.
>> Hopefully the first part of this post is enough to make it work though.
> Thanks Yuraeitha.  This is one of the most helpful posts I have ever 
> received.  I'm not sure what the root issue was but I was able to get it to 
> work by not burning the USB stick.  Initially I used the Dell Recovery tool 
> to burn a recovery USB stick while I still had Win 7 installed.  I found out 
> I can download the iso from any OS so I downloaded into `untrusded` AppVM 
> from here:
> After entering the service tag you can download the .iso.  Then booted with:
> `qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new`
> The basics are working (including networking).  I installed the windows tools 
> following the instructions here:
> 1) When I right click in the file manager in "untrused" AppVM to copy a file 
> into my Windows 7 VM the copy dialog window seems to hang and nothing happens.
> 2) The other issue I have is I would like a menu option to start windows 
> (instead of running `qvm-start win7new` from Dom0).  I can't seem to find any 
> info on this.

For this issue try running (in dom0):

[user@dom0 ~]$ qvm-sync-appmenus win7new

> Thanks again,
> Glen

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to