Testing Windows and QWT in R4.1

User Support General
36

More good news: The qrexec communication works with Qubes R4.0.3, too. Installation of this new vesion 4.1.1 of Qubes Windows Tools is also possible for Windows 7 and 10, and the resulting systems behave nearly as under Qubes R4.1, with some minor differences:

  • The installation option Move user profiles seems to be ignored here for both Windows 7 and 10.

  • Windows 10 allows to set screen resolution to many diffeerent values, not just the three ones presented under Qubes R4.1.

  • Selecting Seamless mode is just ignored (tested only with Windows 10), and Qube manager does not block.

File and clipboard copy both work in both directions for both versions of Windows. So the qrexec communication seems o.k. As far as I understand it, this means that the Xen drivers are compatible with both Qubes versions. Network communication using the original network driver, not the optional Xen PV driver, works too (tested with Windows 10).

3 Likes
37

@fepitre @wind.gmbh The problem with aborting the build in the second make statement arises from a version change of rpm. In Fedora-32, the version is 4.15.1, while it is still expected to be 4.14.0. The command rpm --version returns a differently formatted string, and the result string of rpm --checksig has changed, too, such that the check for a correct signature fails.

In order to make the check successful, the following changes have to be applied to the script qubes-builder/qubes-src/builder-rpm/prepare-chroot-base:

  • Line 16:
    RPM_VERSION="$(rpm --version | awk '{print $3}')"
    change to
    RPM_VERSION="$(rpm --version | awk '{print $2}')"

  • Line 18:
    if [ "$(printf '%s\n' "$RPM_VERSION" "4.14.0" | sort -V | head -n1)" = "4.14.0" ]; then
    change to
    if [ "$(printf '%s\n' "$RPM_VERSION" "4.15.1" | sort -V | head -n1)" = "4.15.1" ]; then

  • Line 20:
    PGP_SIGNED=' signatures OK'
    change to
    PGP_SIGNED=' digests signatures OK'

The second make statement works then.

Caution: If these changes are applied, the build works only for rpm version 14.5.1. If it is required to work for both versions 14.4.0 and 14.5.1, more complex changes are needed at that point.

This problem is related to the Qubes issue #5526, where the same situation occured during the build of an R4.1 iso.

Generally speaking, the signature check is somewhat fragile, depending on a version string and parsing of text output of version-dependent rpm commands, but I must confess that I have no better idea.

38

Starting AppVMs based on the Windows templates gives very mixed results. Partially, they look somewhat queer, and the qrexec communication does not seem to work correctly. I think, there is still a lot more research needed …

39

Finally everything works (GUI, Audio, Network) in Qubes 4.1

qubes-windows-tools-4.1-65.iso

win-7-3
win-7-31920×1080 412 KB

3 Likes
40

Is there a way to get the iso without setting up all the builing environment?

Thanks

1 Like
41

It’s not good for every day work on real job.
I mean win7 hvm + proxy vm.
Too sluggish.
Recommend use qubes as network server and route traffic from proxy vm to another baremetal PC host with Windows 10 and graphical card.

https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm

build instructions here :

remember, its not official

1 Like
42

I checked now the new version 4.1-65 of QWT under Qubes R4.1, and the results are very promising:

  • Installation works for both Windows 7 and 10 without problems. I tested just using the default configuration, i.e. all options without Xen disk and network drivers.

  • Both templates and newly created AppVMs based on these templates work, allowing file and clipboard copy to/from other VMs, for both Windows 7 and 10.

  • Private storage for templates and AppVMs is correctly separated for both Windows 7 and 10.

  • Audio (microphone and speaker) work (most of the time - see below) in both Windows 7 and 10, although the sound is somewhat scratchy.

  • For Windows 7, seamless mode works and can be enabled/disabled while the VM is running.

There are some caveats, still:

  • If Windows 7 is run in seamless mode, the start button is not displayed, like it was under Qubes R4.0 with QWT 4.0.1.3. Apllications can be started via the XFCE menu, and show their windows on the desktop. If focus is set in one of these windows, the Windows menu can be displayed by hitting the Windows key on the keyboard.

  • Under Windows 7, audio sometimes did not work, and the control panel showed a message that no audio devices did exist. Sometimes this was accompanied by an error message that the audio driver were not signed - although it is a Microsoft driver and testsigning is on.

  • For Windows 7, screen resolution is resticted to 1920 x 1200 (my physical screen size) and 800 x 600. For Windows 10, the supported resolutions are 1920 x 1080 (HD), 1024 x 768 and 800 x 600. Changing the screen resolution is possible, but has some funny effects if the VM is running in seamless mode.

  • Selecting or deselecting seamless mode for Windows 10 crashes the Qube manager, but leaves the VM in its previous state.

  • AppVMs work as expected if they are created after QWT is installed in the template. AppVMs created before mess up their devices, as the template uses drive letter Q: for the private volume, which has the consequence that these earlier created AppVMs do not find their user profiles and thus cannet be really used. Trying to repair this situation is more or less impossible, since Winows makes a terrible mess in its drive letter assignments. This, however, is no problem of Qubes or QWT, but stems from the “superior” Microsft software quality. (They should have learned this around 1990, and their efforts with Vista and later only made it worse!)

To sum it up: QWT 4.1-65 is already very good and can be used with faith in Qubes R4.1. So, there is a lot of hope that Qubes can remain a valid and stable basis for running Windows in a trustwothy way.

2 Likes
43

If Windows can be / has to used under Qubes, as usually, depends on the requirements and the environment. Putting Windows in a separate machine protected by a Qubes network proxy is o.k. for a stationary environment, where you can have several computers. In a mobile situation, where you have just one laptop, running Windows as Qubes VM(s) is, in my opinion, the only option to run this system safely.

No discussion: running Windows natively without some protective shield and accessing the internet is somewhat an information suicide!

44

I repeated the tests of QWT 4.1-65 on Qubes R4.0.3, with similar, but in several aspects differing results:

  • The option Move user profiles does not work for both Windows 7 and 10, such that using templates and AppVMs is not possible, at least not without much effort.

  • Audio does not work for both Windows 7 and 10.

  • Windows 7 behaves similarly to the installation under R4.1, including functioning file and clipboard copy. The full screen resolution is a bit lower, 1920 x 1142.

  • Windows 10 at first seems to work, allowing, like Windows 7, file and clipboard copy. So, the qrexec communication seems to be set up correctly. A full range of different screen resolutions is available. But: After the next reboot, Windows 10 does not start anymore, but stays in the starting state and is killed after qrexec timeout.

So, for Qubes R4.0.3, it is currently better to stick to QWT 4.0.1.3.

1 Like
45

Hello:)
I tested the new QWT 4.1-65 on Qubes 4.1 and tried to install Windows 7 and Windows 10 as a template VM. My problem is that the template vm has no nettwork at both systems. If I set up an AppVM there networking is working. Of course I selected sys-firewall as an netvm ,before starting windows:) It will be very nice and helpful to tell me how I can fix that:)
I found that descritpion ,but I don’t know where to find that “qubes network” in msconfig:
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: to find the VM’s ip, run qvm-prefs vmname visible_ip in dom0. Caveat: a cloned/restored/… VM will likely have its IP changed so you’ll have to remember to update your network settings.
  • Gateway: to find the ip, run qvm-prefs vmname visible_gateway in dom0.
    I installed qwt without any changes, maybe I should try it with these network drivers?
    And another question: If I install qwt at Windows 10 I don’t need to install the xen storgage 9.00 drivers like I have to do in Qubes 4.0 before, or?

Thank you in advance for ur help and stay healthy
Much greetings Rasta

46

I checked my installation and had network access from both Windows 7 and 10 templates if and only if their NetVM is set to sys-firewall before starting them.If, as is default for templates, their NetVM is set to none / deafult (n/a), they start without a network interface, i.e. they have no network hardware.

I installed QWT without the PV network driver, because I had already some trouble in the previous version of QWT (see above), as the PV driver does not seem to work with Qubes DHCP. Maybe it behaves differently from my installation.

I’ll try with msconfig later on , so stay tuned …

47

So, I did a few mistakes in configuring network in win7 manual and uses 255.255.255.0 as mask ,but it has to be 255.255.255.255. Now it is working.
And I reinstalled the template vm with xen disk and network drivers this time and a own build win7 ultimate.iso including sp1 and updates. It seems that everything is working. Qwt 4.1 and qubes 4.1 is really good for the first days!:slight_smile: I am doing my Home-Schooling with that settings, running teams on fed32 and sometimes at win7 vm and did not have much problems:)
You can send a file to the win7 vm and the other way around. And secure clipboard copy is working,too. The qubes private is q: and the move of the user data was correct. Audio is working so far, too:) A template based appvm ist working,too. U just have to change the Ip in the windows network settings corresponding to the VM and network is working,too:)
I will try a few things more and update as soon I got some more informations and set up and Windows 10 VM,too and look what errors I will get there.
But in a nutshell many things are already working and that is a big hope for a stable secure win vm in the next years!

Just an other question: Is there any doc about how to link and windows desktop file to a qubes starmenu shortcut like the tool qvm-create-windows-qube ist doing it after installing the packages via cocolately?
Thank you again and stay blessed!

Lovely greetings

Rasta

1 Like
48

Just an other question: Is there any doc about how to link and windows desktop file to a qubes starmenu shortcut like the tool qvm-create-windows-qube ist doing it after installing the packages via cocolately?

You may create a destop starter symbol like for any Linux-based VM, by rightclicking on an empty desktop location and then tryping <your-Windows-VM-name> and selecting one of the programs offered in a list. This starter works as expected, starting the VM if it is not yet running, and then starting the application, in seamless or non-seamless mode as spefied for the VM. You may even drag the icon to the task bar and start it from there.

1 Like
49

The Windows 10 VM may crash after qrexec timeout. This can be avoided by setting qvm-features <VMname> qrexec "", i.e. setting this paramter to blank. Still, qrexec communication seems to work, because file copy is operational.

If the Windows 10 VM does not start visibly, its gui can be started manually via qvm-start-gui <VMname>. Alternatively the parameter gui and gui-emulated may be set to 1, i.e. qvm-features VMname> gui 1 and qvm-festures gui-emulated 1.

Still, this is not quite reproducible and needs further testing.

1 Like
50

I tried installing the new qubes windows tools at a Windows 10HVM,too. But there I am not able to get a stable working vm. Sometimes copy between other vm*s is working sometimes not. I am always creating an template vm first and then try appvm’s. Seamlessmode of course is not working, too and qubes manager chrashed. but I will try what will be if I change it in the registry to value 1,if then system will boot or not the next days.
And I tried to install the xen 9.00 pv storage drivers and bus before installing qwt. So win10 will boot, but if u install new qwt the template vm will not boot anymore and hang up at booting.
The best option was just to install qwt with standart settings in a fresh create hvm with the known settings for an win10 vm:) mostly copy file betwenn the vm is working on this way. but I will try some more trial and errors this weekend:)

but for the win7 vm, seamless mode persistently via win registry is working, memory balance not,but no problem usually, the template and appvm are working. audio,too. Just sometmes it will be a bit laggy if u open a big app like adobe photoshop in it ,but that is stressfull for ur cpu and else and must not work perfectly and is good enough to use it:)

stay healthy!

51

That is exactly what I observed! (Just shows how reliable W10 is, and they always tell us to switch from W7 to W10 - Grrr!) :unamused:

52

No I reinstalled my Windows 7 template VM, and have exactly the same problem as the last time but now I cannot get i working again. Just in the appvm the network is working and not in the template vm. I tried it with the xen network drivers and without. Maybe u can tell me what I can try. The right gateway and else is need is that from the Win7 template vm or?
I don*t know why, but that is annoying. I need a solution to get networking working faster and not after many days of work:D I try to reinstall it later and set the netvm soon before the first start

53

For Windows 7, I have the following behaviour:

  • If the template VM is connected to sys-firewall on startup, i.e. the Qube manager shows sys-firewall as NetVM before starting the template VM, it will have a network device and will be connected to the internet.

  • If the template has no NetVM, i.e. the Qube manager shows default (n/a) as NetVM before starting the template VM, it wil have not network adapter (shown in the Windows network manager). Setting the NetVM in the Qube manager after starting the VM will have no effect until the next boot of the VM.

  • The AppVM, which normally is connected to sys-firewall, behaves the same way as the template VM, if it is connected to sys-firewall.

  • Starting both template VM and AppVM with network enabled is likely to cause trouble, because they may come up with the same IP address.

Windows 10 may behave the same way, but after the next boot may not work at all. It is more or less erratical.

54

So , I finally know the fix, but don*t know what exactly the problem was. Now I reinstalled it (always with xen network and pv drivers, the other way I will not have much effort) and before I update qubes 4.1 from the current testing repo. I think there is a driver or anything else new, which makes sys-firewall working in my win. Of course I need to set up the network at the adapter section in win manualy, but then it FINALLY will work. But of course I had to try thsi one more to be sure for 100 % :wink:

And at this qubes install I missed to enable that sys-net should handle all my usb controllers, too. Do u know if there is a a way to enable this after instaling?

So, I try a fesh Qubes installation at my 2nd laptop to figure out if that is the problem. I installed 4.1 with sys-net ,sys-usb everything dispvm and a custom storage pool. I installed a win7 vm and hat the same network problems and cannot get it working. then I run a update of the current testiing repo and it is working with manual setup,xen drivers and else… hm?!

According to Windows 10, I tried a few more installs ,but with the xen drivers it is not running. maybe file copy is working one time. For me the stablest is to use a Windows 10 pro.iso , update it completely and install net 4.8 , maybe 5, too. Do a restart everytime its necessary and at the last step install the qwt 4.1 with move of user data enabled and standart installation settings. So u will get a working Windows 10 HVM ,like in qubes 4.0 without the xen drivers, but that did not matter much.

I saw that ur using ly display manager for logging? I tried it with sddm kde and lightdm xfce and both. Sometimes I think that sddm and kde have a better performance in the windows hvms, especially in win7 seamless mode. But I like to have the ly display manager like u can the at the gihub page in this posts. But if I download the file and run make the I am always getting 1 error. Do u have an compiled rpm file that I can use to install or tell me the steps to get it running? Because sometimes I am using i3 desktop, and with the other managers I cannot logout and login to a plasma or xfce session . Then it will not load in completely and I have to reboot. I can imagine that with the ly manager it is working and I have good perfomance,too cause it is a small one. Soon it is weekend and I will do some trial and error again. Have to get more space in my dom0 root volume and a few things to do :smiley:

So after I am trying a few several updates with new kernel 5.1x ,sys net and sys-firewall are working again and starts, but only my my wlan is working like with kernel 5.9.14-1 and I don’t know how to get my wired connection working again. The network card is detected, but that is a bit off topic for here, but I noticed problems with my windows Hvm and the new kernel…It don’t start anymore and I am alyways getting an qrexec error and the vm halted. I think that is a problem with qwt and the new kernels?!
I definitely need to get working my dual boot from a ssd again or I have to buy a second ssd if that is not working for some work until I got the vm running again and stable that it will not crash again after the next updates;) I will try it what u told me in the other topic @GWeck . Thank you for ur help. U have got a big knowledge about such things!

fix: okay that problem was fixed easily and I just need to run again qvm-prefs VM qrexec_timeout 300- It seems that this was overwritten at the last update, but now the win vm*s are working like before.

stay healthy

55

I am attempting to install Windows 7 with QWT as a Stand alone VM on Qubes 4.1. I originally attempted to restore my stable win7 VM from Qubes 4.0.3 and it would not run as in the OP.

I created my VM with this command:

qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new

Since I’m not familiar with the build process I have downloaded the QWT 4.1-65 rpm from here

https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm

and I am following the instructions here

https://github.com/0rb677/dotfiles

sudo dnf install mock
sudo groupmems -a user -g mock
sudo mount -o remount,dev /dev/xvdb /home
git clone https://github.com/tabit-pro/qway-qubes-repo
mock -n -r qway-qubes-repo/fedora-qbs.cfg --rootdir /home/user/temp --resultdir \
/home/user/rpms --sources qway-qubes-repo/qubes-windows-tools/ --spec \
qway-qubes-repo/qubes-windows-tools/qubes-windows-tools.spec

rpm -i qubes-windows-tools-4.1-65.noarch.rpm 
qvm-prefs win7new memory 4096
qvm-prefs win7new maxmem 4096
qvm-prefs win7new kernel ''
qvm-volume extend win7new:root 30g
qvm-prefs win7new qrexec_timeout 300
bcdedit /set testsigning on
netplwiz (disable password)
qvm-start win7new --instal-windows-tools
set network manualy
qvm-features win7new audio-model ich6
qvm-prefs win7new memory 2048
qvm-prefs win7new maxmem 2048

I have some questions:

  1. Is using this QWT 4.1-65 rpm going to be reasonably safe /secure
  2. I am unfamiliar with “mock” , please inform what it does and if those command lines are pertinent to my use case.
  3. I assume that since I have the rpm, I should copy that into Dom0 before executing the command . Correct?
rpm -i qubes-windows-tools-4.1-65.noarch.rpm

on edit: Of course I have read the information on “mock” at
https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
so I have an idea what it does, but I am specifically trying to decipher its use in this case

Thank you very much for your assistance.