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 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. -- 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 https://groups.google.com/d/msgid/qubes-users/79772cc7-4cde-4ba2-8455-871e134e5978%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
