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: https://github.com/QubesOS/qubes-issues/issues/3592
> > Installing Qubes Windows Tools: 
> > https://github.com/QubesOS/qubes-issues/issues/3585
> > 
> > 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 

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 
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 

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.

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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to