Testing Windows and QWT in R4.1

I have tried what happens in Qubes R4.1 (Version 20201014 Alpha) with Windows and QWT So far, the following results are obtained:

  • For Windows 7 with QWT installed, the VM from R4.0 can be imported, but not started - error in libxenlight : Couldn't open /sys/bus/pci/drivers/pciback/allow_interrupt_control: File or directory not found The VM stays in an intrermediate state, shown as running or starting, but it cannot be shutdown or killed, claiming it were not running.

  • For Windows 10 with QWT installed, the VM from R4.0 can be imported and started, but somewhere in the boot process, the VM crashes with the error message INACCESSIBLE BOOT DEVICE, an error I already have seen in my earlier tests on Qubes R4.0. This error does not make sense as the VM was started, so it has access to the boot device. This might have to do with switching to a Xen disk driver???

  • For Windows 7 without QWT, the VM from R4.0 can be imported and started. The QWT can be installed, like documented for R4.0, even with the option to move the user profiles. The VM seems to behave quite normally, but is cheating on that behalf: The Qube Manager shows the VM as running (green dot), although the Qubes PRC Agent, which should have been started automatically, is not running. The agent cannot be started manually, showing error 1067 (Process terminated unexpectedly). Communication with Qubes does seem to work only partially, since file copy to/from other VMs does not work, but the VM stays running. - The screen resolution stays fixed at 1920 x 1024 (my screen is 1920 x 1200), and the only other option shown is 800 x 600. Trying to change the resolution renders the VM inoperative - it cannot even be killed, and Qubes has to be restarted to get access to it again.

  • An AppVM based on this Windows 7 template cannot be started. It crashes with the libxenlight error, too.

  • For Windows 10 without QWT, the VM from R4.0 can be imported and started. However, the VM stays invisible, until qvm-features gui and qvm-features gui-emulated is set to 1. The Xen drivers and QWT can be installed, like documented above. Then, the VM seems to behave quite normally, but is cheating on that behalf: The Qube Manager shows the VM as running (green dot). The Qubes RPC agent is not started, although its start type is set to Automatic, but it can be started manually. Communication with Qubes does not seem to work, since file copy to/from other VMs does not work, but the VM stays running, as long as qvm-features qrexec is not set. - The screen resolution is set to 1024 x 768, but can be changed to 1920 x 1080 or 800 x 600, and the system stays responsive.

  • An AppVM based on this Windows 10 template can be started and behaves like the template.

So there are small changes from the previous version (20200914) of Qubes R4.1, but there remains still a lot to do with respect to QWT and the Xen drivers. Is anyone out there willing to dive into the Windows and drivers mess?!


Thanks for testing!

I think the main problem is qrexec - in R4.1 there is a protocol change. The old protocol is still supported, but the agent (VM) part needs to support protocol negotiation. For Linux it was implemented here, similar change is needed in Windows implementation.

This message doesn’t look related to the Windows VM startup - unless you have some PCI devices connected there. But then still, it should be harmless. If the VM remains in intermediate state something is happening there - maybe simply GUI isn’t visible (which would be similar to “W10 without QWT” case). Was seamless GUI enabled there? If so, then here too was a protocol change, and the old version is still supported(*), and no extra changes should be needed for version negotiation. You can try viewing emulated VGA output with qvm-start-gui --force-stubdom <vmname>.

I think it means PV disk driver crashed. Or is in some way incompatible. The initial boot is done with the help of emulated disk (which stays in use if PV drivers included with QWT are not installed). There are some debugging hints at https://www.qubes-os.org/doc/windows-debugging/, but I’m not sure how relevant they are to PV drivers. AFAIR there was some method to get debug output from those drivers, but it might require rebuilding them with debug enabled…

(*) Unless you use GUI domain separate from dom0 - this feature requires new GUI protocol in the VM too.

@marmarek I still use dom0 as GUI domain; so far, I just experimented with sys-gui only for Linux VMs.

  • Windows 7
    In R4.0, seamless mode was enabled in this VM. There were no PCI devices - at least, I did not specify any. In R4.1, the VM starts and then, rather early in the boot process, crashes withou showing any output, and the Start failed message appears. The qvm-start-gui command returns immediatle witout any output.
  • Windows 10
    That’s plausible. Unfortunately, I don’t have the resources and knowledge to do any debugging in Windows.

Hi. Did you try this?

Hi, I tried to build it according to this link, using Fedora-32 with wine and docker installed, but the first docker command aborted with the following message:

Step 2/11 : RUN microdnf install -y mingw32-gcc mingw64-gcc mingw32-gcc-c++ mingw64-gcc-c++ mingw32-winpthreads-static mingw64-winpthreads-static mono-core cabextract wine.i686 tar unzip make curl vim-enhanced genisoimage patch git svn file rpm-build createrepo ---> Running in f5e2e021d5c6
OCI runtime create failed: this version of runc doesn't work on cgroups v2: unknown

This is a known issue on Fedora since 31+ and this why you should use for example CentOS 8 or Debian 10 for using Docker. For Fedora 31+ Podman is massively used as replacement for Docker and I doubt Docker people will fight against this or at least, they would need to be compatible with newer cgroups.

1 Like

Thanks that helped a step further. I installed docker on Centos 8 and got it running. But now, an error occurs at step 4, probably because of a version incompatibility in wine:

Step 4/11 : RUN dnf downgrade --releasever=28 -y wine.i686
 ---> Running in 87724c53f60d
Fedora 28 openh264 (From Cisco) - x86_64        3.7 kB/s | 5.1 kB     00:01    
Fedora 28 - x86_64 - Updates                    1.0 MB/s |  30 MB     00:29    
Fedora 28 - x86_64                              1.1 MB/s |  60 MB     00:54    
 Problem: cannot install both wine-core-3.5-1.fc28.x86_64 and wine-core-5.22-1.fc33.x86_64
  - package wine-dxvk-1.7.2-2.fc33.x86_64 requires wine-core >= 4.13, but none of the providers can be installed
  - wine-core-3.5-1.fc28.i686 has inferior architecture
  - cannot install both wine-core-3.5-1.fc28.i686 and wine-core-5.22-1.fc33.i686
  - package wine-3.5-1.fc28.i686 requires wine-core(x86-32) = 3.5-1.fc28, but none of the providers can be installed
  - conflicting requests
  - package wine-4.0-1.fc28.i686 requires wine-core(x86-32) = 4.0-1.fc28, but none of the providers can be installed
  - cannot install both wine-core-4.0-1.fc28.x86_64 and wine-core-5.22-1.fc33.x86_64
  - wine-core-4.0-1.fc28.i686 has inferior architecture
  - cannot install both wine-core-4.0-1.fc28.i686 and wine-core-5.22-1.fc33.i686
  - problem with installed package wine-dxvk-1.7.2-2.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
The command '/bin/sh -c dnf downgrade --releasever=28 -y wine.i686' returned a non-zero code: 1

I have no idea where I should search now to add --allowerasing or so. I suppose it’s a problem in the build procedure provided by tabit, but where can I find that - I have never used docker before.

The same error occurs when trying the build with debian 10 under Qubes R4.1.

Yes. This is fedora-32 wine issues while you trying to install dotnet40 via winetricks
dotNetFx40_Full_x86_x64.exe - Microsoft .NET Framework 4
Dockerfile need some fixes.

I’ve fixed downgrade: https://github.com/fepitre/qwt-crossbuild/tree/fix-dockerfile

The part with winetricks is not working even if I tried with multiple dotnet4X versions. I don’t have time to debug winetricks issues so I hope that would help someone.

1 Like

I tried now several different configurations and came a bit farther with using fedora-32, where I got a rather funny result:

  • In a normal fedora-32 VM, I could install dotnet40 and dotnet45 via winetricks. If I specified --unattended, the installation ran to the end, o.k. Without this switch, several windows popped up, requiring confirmation of license issues, but in the ent, dotnet got installed, too.

  • Doing the same in the docker environment, produced different errors for dotnet40 and dotnet45 in step 7. While dotnet45 could not be installed due to an incompatibility between wine-5.22, which is documented, the dotnet40 installation terminated saying it was cancelled - seeming to hint that the --unattended switch might not have worked and one of the license dialogs went wrong.

I attach the corresponding logs (unfortuately as JPGs, because the forum software won’t let me do otherwise). I hope this might help further.

1 Like

I’ve got it working (up to video driver). I’ve removed docker stuff because there is no need for that. Let me polish things and send you my branch.

1 Like

I invite you to have a look to https://github.com/fepitre/qwt-crossbuild/ and you can check build instructions in README. Please note this is a version without GUI component. I’ve refactored a little bit things to have normal Qubes component build process :). I won’t probably go farther on this because I’ve decided to continue the work initiated from Marek to attempt to revive Qubes Windows components last year based on the work done in qwt-crossbuild. I’ll will focus on them in order to have us a build of QWT in R4.1 as in R4.0.

Tested on a Windows 10 PRO:

[user@windows-mgmt qwt-crossbuild]$ qvm-run -p work-qubesos-win "cmd.exe"
Microsoft Windows [Version 10.0.19042.631]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cmd.exe& exit
Microsoft Windows [Version 10.0.19042.631]
(c) 2020 Microsoft Corporation. All rights reserved.


Build failed. Message limit only 32000.
So, parts of qwt-crossbuild-dom0-fc32.log

-> Updating sources for qwt-crossbuild...
--> Fetching from https://github.com/fepitre/qwt-crossbuild master...
--> NOT verifying tags
--> Merging...
-> Installing core RPM packages...
Created symlink /etc/systemd/system/sockets.target.wants/dbus.socket → /usr/lib/systemd/system/dbus.socket.
Created symlink /etc/systemd/user/sockets.target.wants/dbus.socket → /usr/lib/systemd/user/dbus.socket.
Created symlink /etc/systemd/system/dbus.service → /usr/lib/systemd/system/dbus-broker.service.
Created symlink /etc/systemd/user/dbus.service → /usr/lib/systemd/user/dbus-broker.service.
Created symlink /etc/systemd/system/timers.target.wants/unbound-anchor.timer → /usr/lib/systemd/system/unbound-anchor.timer.
Created symlink /etc/systemd/system/timers.target.wants/dnf-makecache.timer → /usr/lib/systemd/system/dnf-makecache.timer.
-> Installing package groups...-> Building qwt-crossbuild (qubes-windows-tools.spec) for fc32 dom0 (logfile: build-logs/qwt-crossbuild-dom0-fc32.log)
--> build failed!

rm -rf /home/user/qubes-builder/chroot-dom0-fc32//home/user/qubes-src/qwt-crossbuild/pkgs/dom0-fc32/*
sudo chroot /home/user/qubes-builder/chroot-dom0-fc32 su -c 'cd /home/user/qubes-src/qwt-crossbuild; env BACKEND_VMM=xen  rpmbuild --define "dist .fc32" --define "fedora 32" --define "_rpmdir pkgs/dom0-fc32/" --define "qubes_builder 1" --define "backend_vmm xen" --define "source_date_epoch_from_changelog Y" --define "clamp_mtime_to_source_date_epoch Y" --define "use_source_date_epoch_as_buildtime Y" --define "dist .fc32" --define "fedora 32" --define "_rpmdir pkgs/dom0-fc32/" --define "qubes_builder 1" --define "backend_vmm xen" --define "source_date_epoch_from_changelog Y" --define "clamp_mtime_to_source_date_epoch Y" --define "use_source_date_epoch_as_buildtime Y"  --define "_sourcedir /home/user/qubes-src/qwt-crossbuild" -bb qubes-windows-tools.spec' - user
warning: line 7: It's not recommended to have unversioned Obsoletes: Obsoletes:	qubes-core-dom0-pvdrivers
warning: line 7: It's not recommended to have unversioned Obsoletes: Obsoletes:	qubes-core-dom0-pvdrivers
error: Bad source: /home/user/qubes-src/qwt-crossbuild/243329.tar.gz: No such file or directory
make[2]: *** [/home/user/qubes-builder/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:82: dist-package-build] Error 1
make[2]: Leaving directory '/home/user/qubes-builder'
make[1]: *** [Makefile.generic:191: packages] Error 1
make[1]: Leaving directory '/home/user/qubes-builder'
make: *** [Makefile:262: qwt-crossbuild-dom0] Error 1

in qubes-builder/qubes-src/qwt-crossbuild, run make get-sources, it should have been pulled earlier. I’ll check.

I’ve pushed force master branch to have the same than nogui one so you would certainly need to clean the sources first. Sorry this is very developing stuff. Also, normally sources for archive dependencies in qwt-crossbuild are now fixed.

1 Like

yahooo :slight_smile: hugely thanks to @fepitre.

-> Installing package groups...-> Building qwt-crossbuild (qubes-windows-tools.spec) for fc32 dom0 (logfile: build-logs/qwt-crossbuild-dom0-fc32.log)
--> Done:
make[1]: Leaving directory '/home/user/qubes-builder

I just tried to build under Fedora-32 and got to make qubes-dom0 COMPONENTS="qwt-crossbuild", which aborts with the following message:

-> Preparing fc32 build environment
-> Initializing RPM database...
-> Retrieving core RPM packages...
-> Verifying signatures...
Filename: /home/user/qubes-builder/cache/fc32/base_rpms/acl-2.2.53-5.fc32.x86_64.rpm is not signed. Exiting!
make[1]: *** [/home/user/qubes-builder/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:44: /home/user/qubes-builder/chroot-dom0-fc32/home/user/.prepared_base] Fehler 1
make[1]: Verzeichnis „/home/user/qubes-builder“ wird verlassen
make: *** [Makefile:262: qwt-crossbuild-dom0] Fehler 1

Are qubes-developers keys imported in your qubes-builder AppVM ?

Sorry - I Just imported the Qubes keys. I’l retry with the developers keys.