Qubes Windows Tools (QWT) on R4

[taradiddles]

EDIT - Updated tools for R4 are in the current-testing repo

See Marek's comment (some issues remain); install with

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools

• 1st install: follow the official doc
• upgrade from the 3.2 version: clone your vm first ! ; temporarily set debug to true and qrexec_timeout to a large value (eg. 600) or the vm will be killed before you'll be able to complete the setup (it takes a bit of point&click).
  • [FAILS] VM with SP1 and no other windows updates / upgrading over 3.2: at the following reboot, windows fails to boot and tries to repair files, which as usual doesn't fix anything (the VM might boot at some point, without the tools installed)
  • [TODO] VM with SP1 and no other windows updates / remove 3.2 version first and then install 4.0.0
  • [TODO] VM with latest windows updates / upgrade over 3.2
  • [TODO] VM with latest windows updates / remove 3.2 version first and then install 4.0.0

---

[The purpose of this issue is to gather user experience and document the installation of R3.2's QWT in Windows HVMs on R4, bugs found and workarounds until the tools are fixed (and hopefully have a new maintainer).]

Qubes OS version:

Qubes 4.0

Affected TemplateVMs:

Windows HVMs

Edits

• June 23
  • add @mossy-nw 's comment about properly checking the rpm sig
• May 7
  • add note about VM qvm-prefs issue when creating a VM based on a windows template
• Apr 23
  • add AppVM based on win TemplateVM issue
• Mar 11
  • revert note about qvm-copy/move failing, it works fine (transient errors because of update mismatch on my system).
• Mar 5
  • add note that since qsb #38 qvm-copy/move fails with 'request refused' because the tools aren't updated.
  • add qvm-prefs vmname default_user to fix copy location ; reference here
• Feb 28
  • add rpm -K for rpm sig check (seen such questions in qubes-users ML)
  • add comment by @AJolly / QWT won't install with the 'move profiles' option disabled
• Feb 18
  • more info on networking (DNS ips, ... + disabling the qubes net service)
  • copied some of the commands needed from the official QWT install guide
  • note about windows update + Xen VBD driver

---

QWT installation

Prerequisite: win7 x64 VM (see https://www.qubes-os.org/doc/windows-vm/).

Get the last QWT rpm here.

In order to check the rpm's signature you'll have to import Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature. Get the key here .

Check the key fingerprint as follows:

gpg2 --fingerprint --import --import-options show-only --dry-run qubes-release-3-signing-key.asc

Or alternatively,

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

And compare with the key's well-known fingerprint, which should be C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

Import the key to the VM's rpm keyring:

sudo rpm --import qubes-release-3-signing-key.asc

You can now check the rpm's signature (more info on rpm signatures here):

rpm -K qubes-windows-tools-3.2.2-3.x86_64.rpm

You should get qubes-windows-tools-3.2.2-3.x86_64.rpm: digests signatures OK. If not, check that the rpm is properly downloaded, that the signing key is imported, ...

Extract the iso from the rpm:

rpm2cpio qubes-windows-tools-3.2.2-3.x86_64.rpm | cpio -idmv

And start the VM (assuming the iso is in the 'untrusted' VM):

qvm-start --cdrom=untrusted:/home/user/qubes-windows-tools.iso win7new

From the QWT install guide:

• win cmd: bcdedit /set testsigning on
• win cmd: netplwiz / uncheck 'Users must enter a user name and password...'
• in dom0: qvm-prefs vmname qrexec_timeout 300

Note about Windows Update:

• updating the machine is not required provided you don't enable the storage driver (disabled by default) in QWT' setup. QWT works on a bare SP1 install as well as in fully updated. See @dmoerner's comment below on how to install updates.
• however, a fully updated Windows seems to be required in order to install xen's VBD (storage) PV driver:
  • on "stock" SP1, installing Xen's PV driver from either QWT or from Xen's official site results in either a BSOD or endless unfixable reboots.
  • after a full Windows Update (takes hours), installing Xen's official driver works flawlessly. Haven't tested when installing QWT with the storage PV driver after updates.

Note about QWT's 'move user profiles' options: @AJolly reports that QWT wouldn't install with the option disabled.

Issue 1 - Networking isn't set up properly

The PV adapter's status is stuck at "Identifying"; pinging an ip works but pinging a host fails, indicating a problem with DNS resolution. A tcpdump on sys-firewall indeed shows that DNS requests are sent to the gateway's ip and are rejected. The reason is that in R4 VMs are now using the exposed "/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use /qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).

Workaround: disable the "Qubes Network Setup" service (with gui/msconfig, or sc config "QubesNetworkSetup" start= disabled in a command prompt) and configure the network manually.

Settings:

• DNS{1,2}: 10.139.1.1, 10.139.1.2
• Subnet: 255.255.255.0
• IP: in dom0, qvm-prefs vmname ip will output the VM's ip. Caveat: a cloned/restored/... VM will likely have its IP changed so you'll have to remember to update your network settings.

Issue 2 - Copy/Move functions

• If the username you log on with in Windows is different than qvm-prefs vnname default_user (usually 'user'), then the 'QubesIncoming' folder is located in C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\ (and launching .exe's directly from this folder sometimes fail, in which case one has to copy the .exe somewhere else (eg. on the desktop) and run it from the new location). Fix it with qvm-prefs vnname default_user winusername where winusername is the username you log on with in windows.

• In R4 the qvm-{copy,move} operations don't require the destination VM as argument: the destination VM is later typed by the user in a dom0 popup gui. When using R3.2 tools in R4 and copying/moving a file from/to a Windows VM, the user will be presented with a "destination VM" popup menu twice - once in the windows VM and once in dom0 (it is OK to leave the VM field blank in windows though).

Issue 3 - inter VM copy/paste doesn't work

Workaround: copy text in files and copy/move them accross VMs.

Issue 4 - creating Windows AppVMs based on a Windows TemplateVM

Problem: the private disk is present in the AppVM but QWT doesn't initialize it if it's empty (format + relocate user profiles). As a result user profiles aren't found at startup and the AppVM is stuck at "Preparing your desktop" for a 2-3 minutes until it timeouts. The vm is then barely usable because of the lack of user profiles.

Workaround (work in progress): copy the private disk of the TemplateVM to the AppVM - see this ML thread

Problem 2: Qubes doesn't copy a template VM's prefs when creating a VM so the new VM's prefs will be the "default" ones and won't be set properly for windows ; eg.

qvm-prefs winTemplate kernel -> ''
qvm-prefs winTemplate virt_mode -> 'hvm'
qvm-prefs winTemplate memory -> '2096'

qvm-create --template winTemplate --label red wintest
qvm-prefs wintest kernel -> '4.4.18-1'
qvm-prefs wintest virt_mode -> 'pvh'
qvm-prefs wintest memory -> '400'

Solution: set the preferences to match those of the templateVM.

Fixing QWT

See this message from Marek.

• Networking isn't set up properly: use /qubes-primary-dns ; looks trivial (
  https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c)
• Copy/Move functions: fix the copy/move functions/gui not to require any argument (https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs)

[dmoerner]

Thanks for this as well. These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4? I've been able to install QWT, but after shutting down the VM after the successful install, the VM never boots again. It either crashes on the initial black Windows loading screen, or tries to fix the problem and tells me it can't fix the problem. (I've now experienced this twice.)

The error I get is:

Problem Signature 01: 6.1.7600.16385
Problem Signature 02: 6.1.7600.16385
Problem Signature 03: unknown
Problem Signature 04: 21198045
Problem Signature 05: AutoFailover
Problem Signature 06: 2
Problem Signature 07: BadPatch
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033

[dmoerner]

Thanks for this as well. These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4? I've been able to install QWT, but after shutting down the VM after the successful install, the VM never boots again. It either crashes on the initial black Windows loading screen, or tries to fix the problem and tells me it can't fix the problem. (I've now experienced this twice.)

The error I get is:

Problem Signature 01: 6.1.7600.16385
Problem Signature 02: 6.1.7600.16385
Problem Signature 03: unknown
Problem Signature 04: 21198045
Problem Signature 05: AutoFailover
Problem Signature 06: 2
Problem Signature 07: BadPatch
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033

[taradiddles]

These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4?
I installed on 4rc3 before the update to rc4 but there shouldn't be any difference.

I remember having a lot of crashes when I was trying to install Windows, which is what led me to write the instructions here and in #3592. Windows will try to fix the install (always unsuccessfully) when it detects that the previous startup crashed (that's why cloning after each successful installation step is important - once you get a crash you have to begin from scratch).
I didn't encounter any crash like yours (BTW, where do you get the error ? In one of Qubes' log files ?).
You may want to try the following (please comment if it helps so that I update the doc):

• have you followed QWT's README ? (IIRC you need to do something like bcdedit... in an admin command prompt to enable test signatures).
• make sure you don't install the storage PV driver if you select 'custom installation' in QWT
• Windows being Windows, try to reboot at least two times after a clean install before installing QWT.

[taradiddles]

These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4?
I installed on 4rc3 before the update to rc4 but there shouldn't be any difference.

I remember having a lot of crashes when I was trying to install Windows, which is what led me to write the instructions here and in #3592. Windows will try to fix the install (always unsuccessfully) when it detects that the previous startup crashed (that's why cloning after each successful installation step is important - once you get a crash you have to begin from scratch).
I didn't encounter any crash like yours (BTW, where do you get the error ? In one of Qubes' log files ?).
You may want to try the following (please comment if it helps so that I update the doc):

• have you followed QWT's README ? (IIRC you need to do something like bcdedit... in an admin command prompt to enable test signatures).
• make sure you don't install the storage PV driver if you select 'custom installation' in QWT
• Windows being Windows, try to reboot at least two times after a clean install before installing QWT.

[github74829]

I have had success installing the tools, thank you very much.

Would you be so kind and inform me how I can disable the Qubes Network Setup and setup the network manually? I have tried setting the Windows 7 IP address to the one shown in Qubes manager and the DNS/gateway to sys-net, but that does not work.

[github74829]

I have had success installing the tools, thank you very much.

Would you be so kind and inform me how I can disable the Qubes Network Setup and setup the network manually? I have tried setting the Windows 7 IP address to the one shown in Qubes manager and the DNS/gateway to sys-net, but that does not work.

[awokd]

@github74829 From https://mail-archive.com/qubes-devel@googlegroups.com/msg02800.html:

So you can simply disable the "Qubes Network Setup" service instead of renaming the .exe

[awokd]

@github74829 From https://mail-archive.com/qubes-devel@googlegroups.com/msg02800.html:

So you can simply disable the "Qubes Network Setup" service instead of renaming the .exe

[dmoerner]

After a third attempt to carefully shepherd the Windows updates, I was able to get the VM into a stable state and install QWT, seemingly without problems. (I did need to set qrexec_timeout 300 as the wiki suggested.)

@github74829: You can disable it in msconfig.

(For reference: The relevant error I found earlier can be found in "Startup Repair" when Windows fails to boot, rather than a Qubes log.)

[dmoerner]

After a third attempt to carefully shepherd the Windows updates, I was able to get the VM into a stable state and install QWT, seemingly without problems. (I did need to set qrexec_timeout 300 as the wiki suggested.)

@github74829: You can disable it in msconfig.

(For reference: The relevant error I found earlier can be found in "Startup Repair" when Windows fails to boot, rather than a Qubes log.)

[github74829]

I have renamed the .exe and did a restart but still no connectivity.
Here's my Windows network adapter setting for IP4 (IP6 is disabled):
IP 10.137.0.15 (as shown in Qube manager under networking)
Subnet 255.255.255.255
Standard Gateway 10.137.0.5 (sys-net)
DNS Servier 10.137.0.5 (sys-net)
What am I doing wrong?

[github74829]

I have renamed the .exe and did a restart but still no connectivity.
Here's my Windows network adapter setting for IP4 (IP6 is disabled):
IP 10.137.0.15 (as shown in Qube manager under networking)
Subnet 255.255.255.255
Standard Gateway 10.137.0.5 (sys-net)
DNS Servier 10.137.0.5 (sys-net)
What am I doing wrong?

[dmoerner]

@github74829
As mentioned in the mailing list post above, you need the DNS servers to be 10.139.1.1 and 10.139.1.2 (or something similar, just check /etc/resolv.conf in an arbitrary Linux VM).

[dmoerner]

@github74829
As mentioned in the mailing list post above, you need the DNS servers to be 10.139.1.1 and 10.139.1.2 (or something similar, just check /etc/resolv.conf in an arbitrary Linux VM).

[taradiddles]

@dmoerner : happy to read it worked. Do I understand correctly that you fully updated Windows before installing QWT ? I didn't run windows update in my VM - it always takes forever and my VM is network isolated so I simply disabled the service, but it will be nice to know so that I can update the doc. Also FWIW I didn't have to change the qrexec_timeout - maybe because my PC wasn't under heavy I/O when the VM was started.

@github74829 : I see a thumb up in the post above so I guess you managed to get networking up and running...

DNS servers: I was wondering whether their IPs were random or hardcoded when I posted to the ML; I now see they are hardcoded in /usr/lib/python3.5/site-packages/qubes/vm/mix/net.py in class "NetVMMixin" / def dns(). I'll update the doc with the IPs.

BTW this issue wasn't really meant to be a detailed guide like the instructions in #3495 but it looks like it would be helpful to people to have more detailed instructions. I'll try to update the doc tomorrow.

[taradiddles]

@dmoerner : happy to read it worked. Do I understand correctly that you fully updated Windows before installing QWT ? I didn't run windows update in my VM - it always takes forever and my VM is network isolated so I simply disabled the service, but it will be nice to know so that I can update the doc. Also FWIW I didn't have to change the qrexec_timeout - maybe because my PC wasn't under heavy I/O when the VM was started.

@github74829 : I see a thumb up in the post above so I guess you managed to get networking up and running...

DNS servers: I was wondering whether their IPs were random or hardcoded when I posted to the ML; I now see they are hardcoded in /usr/lib/python3.5/site-packages/qubes/vm/mix/net.py in class "NetVMMixin" / def dns(). I'll update the doc with the IPs.

BTW this issue wasn't really meant to be a detailed guide like the instructions in #3495 but it looks like it would be helpful to people to have more detailed instructions. I'll try to update the doc tomorrow.

[dmoerner]

@taradiddles Yes, I fully updated Windows before installing QWT. I find it doesn't take too long at all since they bundled SP2 into a single download.

I find it helpful to increase qrexec_timeout because in case you happen to get a BSOD or a similar crash in the VM, chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM.

[dmoerner]

@taradiddles Yes, I fully updated Windows before installing QWT. I find it doesn't take too long at all since they bundled SP2 into a single download.

I find it helpful to increase qrexec_timeout because in case you happen to get a BSOD or a similar crash in the VM, chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM.

[github74829]

@taradiddles Yes I did, thank you very much.
Now I have to see what to do in order for Windows Update to run, it seems like it is stuck. I have already installed QWT, if they prevent Windows Update from functioning correctly, I might have to uninstall QWT, run the updates and re-install QWT again.

[github74829]

@taradiddles Yes I did, thank you very much.
Now I have to see what to do in order for Windows Update to run, it seems like it is stuck. I have already installed QWT, if they prevent Windows Update from functioning correctly, I might have to uninstall QWT, run the updates and re-install QWT again.

[dmoerner]

@github74829
If you're trying to get Windows Update to run on a fresh install of Windows 7 Pro SP1, you need to manually install some updates by following steps 1-11 in this guide: https://plugable.com/2016/06/08/windows-7-wont-update-what-to-do/. Even after doing this, you may find you have trouble installing particular updates and may have to restore the VM from a backup made with qvm-clone; in that case, manually downloading the update and installing it is generally the easiest thing to do.

If your Windows Update appears to be in some sort of a broken state (determined by running Microsoft's diagnostic, here's a direct link: https://aka.ms/diag_wu), then follow this guide: https://support.microsoft.com/en-us/help/971058/how-do-i-reset-windows-update-components. Note that not all of the dll's will exist on Windows 7; that's fine.

I don't think that QWT in itself is likely to cause any problems with updating.

[dmoerner]

@github74829
If you're trying to get Windows Update to run on a fresh install of Windows 7 Pro SP1, you need to manually install some updates by following steps 1-11 in this guide: https://plugable.com/2016/06/08/windows-7-wont-update-what-to-do/. Even after doing this, you may find you have trouble installing particular updates and may have to restore the VM from a backup made with qvm-clone; in that case, manually downloading the update and installing it is generally the easiest thing to do.

If your Windows Update appears to be in some sort of a broken state (determined by running Microsoft's diagnostic, here's a direct link: https://aka.ms/diag_wu), then follow this guide: https://support.microsoft.com/en-us/help/971058/how-do-i-reset-windows-update-components. Note that not all of the dll's will exist on Windows 7; that's fine.

I don't think that QWT in itself is likely to cause any problems with updating.

[taradiddles]

Thank you both for the feedback, I've updated the docs accordingly.

I don't think that QWT in itself is likely to cause any problems with updating.

It doesn't seem to, but I found out that with QWT installed you don't see the "updates in process" (or whatever it's called) when the VM is being shutdowned. Large updates can take a while and you're left wondering what's happening (I killed the VM too hastily the first time and it broke Windows. The second time I didn't do anything and the VM stopped by itself after a few minutes; during that time xentop showed the VM's CPU varying).

[taradiddles]

Thank you both for the feedback, I've updated the docs accordingly.

I don't think that QWT in itself is likely to cause any problems with updating.

It doesn't seem to, but I found out that with QWT installed you don't see the "updates in process" (or whatever it's called) when the VM is being shutdowned. Large updates can take a while and you're left wondering what's happening (I killed the VM too hastily the first time and it broke Windows. The second time I didn't do anything and the VM stopped by itself after a few minutes; during that time xentop showed the VM's CPU varying).

[AJolly]

I was also unable to get QWT installed if I unchecked the option to move user profiles.

[AJolly]

I was also unable to get QWT installed if I unchecked the option to move user profiles.

[hugoncosta]

I'd like to chip in with my experience. Created a win7 x64 ultimate SP1 vm. Followed the instructions on this issue + doc/windows-vm. Doing the extend with 25g will net only 1.36gb of open space with 0 installations on the ultimate edition, so I increased it post installation. It'll really depend on the user, but I'd change it to at least 30GB as a conservative estimate.

Everything worked perfectly, thanks! I did notice a difference compared to R3.2. I had the memory set at 2048 and a maxmem of 4096, which worked fine, but on R4.0 it'd consistently crash my 2 imported vms. I only thought it'd be a nice idea to try it after I erased them and started building the new one. This is already stressed on the tutorial, just a fyi.

[hugoncosta]

I'd like to chip in with my experience. Created a win7 x64 ultimate SP1 vm. Followed the instructions on this issue + doc/windows-vm. Doing the extend with 25g will net only 1.36gb of open space with 0 installations on the ultimate edition, so I increased it post installation. It'll really depend on the user, but I'd change it to at least 30GB as a conservative estimate.

Everything worked perfectly, thanks! I did notice a difference compared to R3.2. I had the memory set at 2048 and a maxmem of 4096, which worked fine, but on R4.0 it'd consistently crash my 2 imported vms. I only thought it'd be a nice idea to try it after I erased them and started building the new one. This is already stressed on the tutorial, just a fyi.

[evadogstar]

Any progress with fixing this issues for Q4?

[evadogstar]

Any progress with fixing this issues for Q4?

[taradiddles]

@hugoncosta : thanks for the feedback. I'll try to submit a PR to the win7 doc with more info about minimal volume sizes.

@evadogstar

Any progress with fixing this issues for Q4?

Unfortunately no, it's a community effort and nobody with visual studio experience has stepped in to help (IIRC at least one user tried to set up a build environment but it didn't work). I personally know nothing about building stuff on windows and don't have the time/will to learn it. Most of the issues seem pretty straightforward to fix though.

[taradiddles]

@hugoncosta : thanks for the feedback. I'll try to submit a PR to the win7 doc with more info about minimal volume sizes.

@evadogstar

Any progress with fixing this issues for Q4?

Unfortunately no, it's a community effort and nobody with visual studio experience has stepped in to help (IIRC at least one user tried to set up a build environment but it didn't work). I personally know nothing about building stuff on windows and don't have the time/will to learn it. Most of the issues seem pretty straightforward to fix though.

[mossy-nw]

hi @taradiddles thank you for compiling this helpful advice! Could you please add to " QWT Installation Check the rpm's signature... " something like the following?

Please import the Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature (otherwise you will get the error qubes-windows-tools-3.2.2-3.x86_64.rpm: digests SIGNATURES NOT OK). Get the key here and import it to your rpm keyring using:

sudo rpm --import qubes-release-3-signing-key.asc

It is also a good idea to check the key fingerprint as follows:

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

The correct fingerprint (I hope!) is C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

[mossy-nw]

hi @taradiddles thank you for compiling this helpful advice! Could you please add to " QWT Installation Check the rpm's signature... " something like the following?

Please import the Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature (otherwise you will get the error qubes-windows-tools-3.2.2-3.x86_64.rpm: digests SIGNATURES NOT OK). Get the key here and import it to your rpm keyring using:

sudo rpm --import qubes-release-3-signing-key.asc

It is also a good idea to check the key fingerprint as follows:

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

The correct fingerprint (I hope!) is C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

[taradiddles]

Thanks, I've added your comment to the doc.

Interestingly, IIRC rpm -K was working without having to import the signing key when I wrote the doc (back in 4.0 rc something). Maybe the key was removed by 4.0 updates; or maybe I imported it for some other purposes and forgot about it.

[taradiddles]

Thanks, I've added your comment to the doc.

Interestingly, IIRC rpm -K was working without having to import the signing key when I wrote the doc (back in 4.0 rc something). Maybe the key was removed by 4.0 updates; or maybe I imported it for some other purposes and forgot about it.

[Polygonbugs]

Thank you @taradiddles. I followed your tutorial QWT installation and finally made it successful. But after installing QWT, there is issue about two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS. Although OS is working well including shutdown of VM, could this be problematic (except visual experience)? I didn't yet test about seamless mode. Do anybody know how to set seamless mode? I can't see it on qvm-prefs command in R4.0.

[Polygonbugs]

Thank you @taradiddles. I followed your tutorial QWT installation and finally made it successful. But after installing QWT, there is issue about two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS. Although OS is working well including shutdown of VM, could this be problematic (except visual experience)? I didn't yet test about seamless mode. Do anybody know how to set seamless mode? I can't see it on qvm-prefs command in R4.0.

[taradiddles]

two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS

That's likely because you didn't turn off the vm's debug property (run qvm-prefs <vmname> debug false)

[taradiddles]

two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS

That's likely because you didn't turn off the vm's debug property (run qvm-prefs <vmname> debug false)

[Polygonbugs]

That's likely because you didn't turn off the vm's debug property (run qvm-prefs debug false)

Oh! Thanks. I forgot to disable debug property. Now it works charm! BTW, I'm wondering that seamless mode is dead option in Qubes-R4. I've searched a lot but I couldn't see how to do. If it is dead in R4, I think it should also be contained in as new issue.

[Polygonbugs]

That's likely because you didn't turn off the vm's debug property (run qvm-prefs debug false)

Oh! Thanks. I forgot to disable debug property. Now it works charm! BTW, I'm wondering that seamless mode is dead option in Qubes-R4. I've searched a lot but I couldn't see how to do. If it is dead in R4, I think it should also be contained in as new issue.

[marmarek]

@Polygonbugs the missing piece is a knob to switch it on/off. You can do it manually:

echo SEAMLESS | qvm-run -p --service VMNAME qubes.SetGuiMode

And to set it back to full desktop:

echo FULLSCREEN | qvm-run -p --service VMNAME qubes.SetGuiMode

[marmarek]

@Polygonbugs the missing piece is a knob to switch it on/off. You can do it manually:

echo SEAMLESS | qvm-run -p --service VMNAME qubes.SetGuiMode

And to set it back to full desktop:

echo FULLSCREEN | qvm-run -p --service VMNAME qubes.SetGuiMode

[marmarek]

Good news: I have my windows build environment refreshed and gave it some polish. Improvements in upcoming update:

• updated to Visual Studio 2017 and WDK 10
• use Xen Project build of PV drivers, signed by the Linux Foundation - means no need for test signing unless you want GUI agent, which is still self-signed
• removed global windows version check and moved it to guard only GUI agent - this means it's installable on Windows 8.1/10 (but no GUI agent there - one still need to use emulated VGA, with max resolution 1280x1024)
• looks like PV disk driver (VBD) is more stable on Windows 10, but I'll still leave it disabled by default
• updated for Qubes 4.0:
  • qubes.StartApp service - required for applications menu
  • fix DNS setup
  • enable rpc-clipboard feature, fixing clipboard support (this is actually dom0 change, not in QWT)

Things from the above list not fixed yet:

• private volume initialization for template-based VMs (manual copy is required, as noted above)
• properties (kernel, virt_mode, etc) needs still needs to be set manually for template-based VM (working on it)
• GUI agent for Windows 8/10 wont happen anytime soon (but this is rather #1861)

[marmarek]

Good news: I have my windows build environment refreshed and gave it some polish. Improvements in upcoming update:

• updated to Visual Studio 2017 and WDK 10
• use Xen Project build of PV drivers, signed by the Linux Foundation - means no need for test signing unless you want GUI agent, which is still self-signed
• removed global windows version check and moved it to guard only GUI agent - this means it's installable on Windows 8.1/10 (but no GUI agent there - one still need to use emulated VGA, with max resolution 1280x1024)
• looks like PV disk driver (VBD) is more stable on Windows 10, but I'll still leave it disabled by default
• updated for Qubes 4.0:
  • qubes.StartApp service - required for applications menu
  • fix DNS setup
  • enable rpc-clipboard feature, fixing clipboard support (this is actually dom0 change, not in QWT)

Things from the above list not fixed yet:

• private volume initialization for template-based VMs (manual copy is required, as noted above)
• properties (kernel, virt_mode, etc) needs still needs to be set manually for template-based VM (working on it)
• GUI agent for Windows 8/10 wont happen anytime soon (but this is rather #1861)

[MystesofEternity]

@marmarek Sorry if I am a bit confused but is your qubes-builder-windows kind of to setup a Windows HVM in Qubes or basically a Qubes .iso builder in Windows itself?

[MystesofEternity]

@marmarek Sorry if I am a bit confused but is your qubes-builder-windows kind of to setup a Windows HVM in Qubes or basically a Qubes .iso builder in Windows itself?

[marmarek]

@marmarek Sorry if I am a bit confused but is your qubes-builder-windows kind of to setup a Windows HVM in Qubes or basically a Qubes .iso builder in Windows itself?

No, it's only for building windows packages (.msi, .exe).

[marmarek]

@marmarek Sorry if I am a bit confused but is your qubes-builder-windows kind of to setup a Windows HVM in Qubes or basically a Qubes .iso builder in Windows itself?

No, it's only for building windows packages (.msi, .exe).

[marmarek]

And here it is: QubesOS/updates-status#574
@andrewdavidwong do you think it worth some announcement? IMO at least an email to qubes-users.

[marmarek]

And here it is: QubesOS/updates-status#574
@andrewdavidwong do you think it worth some announcement? IMO at least an email to qubes-users.

[andrewdavidwong]

do you think it worth some announcement? IMO at least an email to qubes-users.

Yes, definitely qubes-devel and qubes-users. Probably also the website once it leaves testing.

[andrewdavidwong]

do you think it worth some announcement? IMO at least an email to qubes-users.

Yes, definitely qubes-devel and qubes-users. Probably also the website once it leaves testing.

[andrewdavidwong]

Announcement threads:

• https://groups.google.com/d/topic/qubes-devel/P3v67IkAXJg/discussion
• https://groups.google.com/d/topic/qubes-users/hSL0kanaq_o/discussion

[andrewdavidwong]

Announcement threads:

• https://groups.google.com/d/topic/qubes-devel/P3v67IkAXJg/discussion
• https://groups.google.com/d/topic/qubes-users/hSL0kanaq_o/discussion

[demianrihs]

Qubes_Windows_Tools_4.0.1.3_20180720200245.log
dd_vcredist_amd64_20180720200951.log

Hello,

I've tried extensively to install windows 7 under Qubes OS r4. I managed to get the qubes-tools 3.2.2.3 working. But no chance to run 4.0.1.3. I am constantly getting this error message:

One or more issues caused the setup to fail. Please fix the issues and then retry setup.
Fore more information see the log file.

0x80070017 - Data error (cyclic redundancy check)

Could it be an issue with the C++ libraries provided with the old qubes tools? I tried to manually install VC_redist.x64 2017 version. But this is also failing

From this guide it was still not clear to me if it is possible to install qubes-tools 4.0.1.3 directly on a fresh win7 installation or if one has to first get 3.2.2.3 working and then upgrade.

[demianrihs]

Qubes_Windows_Tools_4.0.1.3_20180720200245.log
dd_vcredist_amd64_20180720200951.log

Hello,

I've tried extensively to install windows 7 under Qubes OS r4. I managed to get the qubes-tools 3.2.2.3 working. But no chance to run 4.0.1.3. I am constantly getting this error message:

One or more issues caused the setup to fail. Please fix the issues and then retry setup.
Fore more information see the log file.

0x80070017 - Data error (cyclic redundancy check)

Could it be an issue with the C++ libraries provided with the old qubes tools? I tried to manually install VC_redist.x64 2017 version. But this is also failing

From this guide it was still not clear to me if it is possible to install qubes-tools 4.0.1.3 directly on a fresh win7 installation or if one has to first get 3.2.2.3 working and then upgrade.

[Polygonbugs]

@demianrihs

I've tried extensively to install windows 7 under Qubes OS r4. I managed to get the qubes-tools 3.2.2.3 working. But no chance to run 4.0.1.3. I am constantly getting this error message: 0x80070017 - Data error (cyclic redundancy check)

I've tested it Window-10 on R4.0. I also have issue(=failure) when I try to install QWT 4.0.1.3 on the first attempt. What I see on QWT installation manager, it says that QWT is prematurely installed. But trying again (second attempt) shows me that "Install successful". First reboot after QWT seems okay though network function is not properly working (QubesNetworkSetup fail. Even manual setting IPv4 doesn't provide Internet). Second reboot after QWT Installation failed to boot since qrexec agent failed to initialized. Third reboot seems to connect qrexec agent (because 'qvm-run New-W10 explore.exe' is working) but doesn't show me any window.

From this guide it was still not clear to me if it is possible to install qubes-tools 4.0.1.3 directly on a fresh win7 installation or if one has to first get 3.2.2.3 working and then upgrade.

You cannot install QWT 4.0.1.3 directly on fresh(no or almost few update packages) Windows-7. You will need updates first! Also I recommend not to upgrade QWT from old version. There is user report that doing that doesn't start Windows normally.

BTW, you can report this issue here.

@marmarek , I will soon report full details to here. I think you have to delay QWT v4.0.1.3 to stable repository.

[Polygonbugs]

@demianrihs

I've tried extensively to install windows 7 under Qubes OS r4. I managed to get the qubes-tools 3.2.2.3 working. But no chance to run 4.0.1.3. I am constantly getting this error message: 0x80070017 - Data error (cyclic redundancy check)

I've tested it Window-10 on R4.0. I also have issue(=failure) when I try to install QWT 4.0.1.3 on the first attempt. What I see on QWT installation manager, it says that QWT is prematurely installed. But trying again (second attempt) shows me that "Install successful". First reboot after QWT seems okay though network function is not properly working (QubesNetworkSetup fail. Even manual setting IPv4 doesn't provide Internet). Second reboot after QWT Installation failed to boot since qrexec agent failed to initialized. Third reboot seems to connect qrexec agent (because 'qvm-run New-W10 explore.exe' is working) but doesn't show me any window.

From this guide it was still not clear to me if it is possible to install qubes-tools 4.0.1.3 directly on a fresh win7 installation or if one has to first get 3.2.2.3 working and then upgrade.

You cannot install QWT 4.0.1.3 directly on fresh(no or almost few update packages) Windows-7. You will need updates first! Also I recommend not to upgrade QWT from old version. There is user report that doing that doesn't start Windows normally.

BTW, you can report this issue here.

@marmarek , I will soon report full details to here. I think you have to delay QWT v4.0.1.3 to stable repository.