Testing Windows and QWT in R4.1

Yes, most likely my qwt iso is non-fuctional. At least I do not see if installation succeeds. Is there someplace I can get a reference working one?

Just start the windows qube via console:
qvm-start --install-windows-tools $QUBENAME

it will mount the qwt iso and you should be able to manually start the installer

Strange enough, but now I do not even see a CDROM (it was there during the install process, but I do not think it installed properly).

On another windows qube cdrom is in place, but it just jumps to “wait for shutdown” script and does not seem to install anything :-/

May also be an issue with LTSC. Will try to make a regular Win10 qube after a while. Still wonder why QWT are not in 4.1 repo :-/

Yes, my QWT build is definitely broken. The installer just does nothing.

I just remembered I’ve had the same problem using LTSC.
While the “wait for shotdown” cmdprompt is open just open the cd drive in explorer and look for the installer and manually install it. While the installer is running, some driver installs from it will ask you to reboot, ignore the popup or click no and wait for the installer to finish. Once the actual installer is done and asks you for a reboot just click yes and the qvm-create-windows-qube will continue with the install.

Sooo, this worked (batch files do not). Now it is stuck at “sed: can’t read /etc/qubes-rpc/policy/qubes.Filecopy : no such file or directory”. UPD: not stuck, apparently everything works as intended at this point. But the install script is certainly broken.

So, to sum this up: works, but still requires manual intervention when running qvm-create-windows-qube :)) also I spend whole day chasing ghosts.

Is qvm-create-windows-qube part of the main sources now? The github page says plans were to integrate it upstream for 4.1, but I had not heard anything about that till now.

noo, not again. now GUI vanished completely and qvm-features gui and gui-emulated does not bring it back :(( upd: gui should be set to 0. somewhat counterintuitive :))

Hello. I have 4.1 RC1 installed and trying to build QWT 4.1.65 from GitHub - tabit-pro/qubes-windows-tools-cross: Qubes Windows Tools build with mingw, wine and qubes-builder
I’m getting this error

I tried to install commands as suggested in message, but getting error

Any help would be appreciated.

Could you open issue with repo issue tracker and get more details about build steps?

Unfortunately, I am not registered on Github, and this error is generated in disp-vm, untursted-torrified, and untrusted-sys-firewall-sys-net vm’s after trying to build qwt iso command:

make BUILDERCONF=example-configs/qubes-os-r4.1.conf COMPONENTS=windows-tools-cross windows-tools-cross-dom0

I couldn’t succeed neither on 4.1 beta 1 in disp-vm, so as I can recall I succeeded to build it in untrusted cube, not disp-vm on beta1.
I have made a backup of it, though.

Is it legit to use that one built on 4.1 beta1 in untrusted-vm (I increased private storage to 10GB, of course on all vm’s), or I have to build it everytime Qubes OS 4.x is upgraded?

Could it be debian-based VM? That might be the issue

Anyway, if you have successfully built once, just keep results - iso or rpm.

1 Like

One remaining problem with QWT under Qubes R4.1 is the restriction of available screen resolutions to 3 or 4 not very useful values. This restriction can be removed however, for the different Windows versions supported by QWT 4.1-65:

  • For Windows 7, do not select the option Qubes GUI Agent when installing the Qubes Windows Tools. Then you will lose the possibility to select seamles display mode, but you can set the screen resolution of the VM to useful values. On the other hand, if the GUI agent is installed and seamless mode is enabled, the screen resolution of the main window is probably not so important., but the display of the start button is still missing.

  • For Windows 10 or 11, when trying to change the screen resolution, select the additional options, which can be found lower on the selection screen (somewhat different in 10 and 11). There QEMU Monitor is displayed as available display, and you can select the adapter properties of this monitor at the bottom. In the window which is then displayed, select the Monitor tab, and on this tab, unselect the option to restrict the displayed modes to those not displayed for this monitor (sorry for the clumsy wording, but that is Microsoft). Then select the Graphic Adapter tab, and there you can now select a decent screen resolution.

But I am still hoping that someone writes a new version of the Qubes GUI Agent, for Windows 7 and 10 / 11. :wink:

2 Likes

Thanks for the response.
It couldn’t be debian-based VM, since I couldn’t have manage to get to the command in the issue, since at the beggining we have to use dnf packager right? If it was Bedrock Linux vm, yes this could be possible, hahah.
Now as you suggested, I used qwt-4.1.65 iso I built in 4,1 beta1, and the “clean” fully updated win7 SP1 qube restored from the backup (updated to Jan, 2020, disabled login screen, testsigning on, uac disabled). My primary goal is to be able to access the other internal hdd from Qubes, let’s call it HDD2, which is also bootable for now - win7. My data and app that has no alternative in Linux world is there and once I achieve fully functional win7 cube in terms of that particular app accessed on HDD2 from Qube’s win7 cube, I will reformat that other win7 hdd, trying to put only win7 qube on HDD2). Here are my findings:

  1. Installed qwt with the default options. Restarted as requested again with --cdrom with qwt iso.
  2. Tried to attach HDD2 block device. No luck.
  3. Started installation from the qemu cd rom, choose the option “Change”,
  4. Added Xen SCSI disk controller, only Xen VIF, network, drivers not installed. Restarted as requested.
  5. Success. Attached, accessed, and use blocked device HDD2 and data on it successfully!
  6. Shut down cube.
  7. Immediately made a backup of it.
  8. Shut down the computer.
  9. Turn on the computer.
  10. Started win 7 cube.
  11. Once started, tried to attach HDD2 again. Device attached, but id disk management partition recognized as RAW, not NTFS. Now, this happened as well in v4.1 beta1 and it screwed up my hdd2 win 7 bootable partition, so I had to rescue it with Mini tool PW and Macrium. It took me 2 days. Didn’t know then why it happened.
  12. Immediately shut down win 7 cube.
  13. Attached HDD2 to the other linux cube. Linux cube sees the content of HDD2?!
  14. Tried to start again win 7 cube.
  15. Nope! Cannot connect to qrexec for as much as I set it: 60, 300, 600, 359, just nope. I have already wrote about this on another topic.
  16. Checked quest-win7 log in /var/the-restof-path/ as usggested by dialog box after unsuccessful win7 cube start, but it only says Logfile Opened.
  17. There is also quest-win7-dm.log file in the same folder, and there are more info in it, but I wouldn’t want to throw it all here if you don’t ask for it. I’m not able to recognize any useful line suggesting an issue/error.
  18. Tried as GWeck suggested earlier qvm-features gui 1 and qrexec timeout 600, with no luck. Tried to set gui to 0 as you suggested, but no luck. Tried as --default, no luck.
  19. Restored win7 cube from the step 7.
  20. Repetead steps 10 and 11 succesfully.
  21. Unlike step 12, this time HDD2 boot partition is recognized as unallocated.
  22. Repeated step 13. Unlike in it, this time, although mounted, boot partition (content) cannot be accessed and linux “sees” multiple file systems on it: ntfs and nonexistent exfat, exfps.
  23. Restarted linux cube, again attached HDD2 bootable partition - everything ok. Partition mounted as ntfs, fully working and accessible
  24. Tried to start qube from step 20. Unlike in step 16, it started! Why on earth this would be even possible, when the same qube from step 16 didn’t?
  25. Tried to attach HDD2 again - qube windows dissapears but qube still running as seen in qube manager - USB widget shows that block device is still attached to the cube! OMG…
  26. Dettaching block device and win7 cube finally shuts off, which can be only concluded looking into the green/yellow circle next to the cube in Qube Manager.
  27. Let’s try to start win7 cube once again. It started.
  28. Tried to attach HDD2 again. Qube window doesn’t disappear?! OMG. In Disk management, HDD2 seen as unallocated, not RAW, or NTFS.
  29. Repeated step 23, and unlike it, wothout restarting linux cube, block device HDD2 content is fully accessible. OMG, there is simply not a single pattern that can be followed.

Now, totally depressed, several things can be concluded by me.

  1. It’s not about win 7ncube.
  2. It’s not about HDD2 since it’s fully working when booted without any single issue and constantly monitored by manufacturer software.
  3. it’s not about qwt because there is no pattern in win7 cube acting, unless no-pattern is the pattern.
  4. It has to be dom0 then, considering no-pattern in linux cube acting as well when attaching hdd2 to it.

Now, I think my issue is important, because I haven’t seen anyone else reported issues with attaching internal block devices to win cube so maybe developers aren’t aware of it (yet). On the other hand I assume it is not that often that someone wants to attach second internal block device to win cube, thus making my issue not important for developers, which especially is frustrating because I’ve been waiting for this for 7 years, and 4 years for v4.1 which was supposed to finally work with win cubes…

Any idea, or at least a comfort are welcomed, hahah

I prefer not to use block device hot attaching with Windows VM. Instead of it could be used persistent attach (qvm-block with -p option) or USB device attach.

After incorrect shutdown Windows usually tries to run safe mode or recovery console which doesn’t start Qubes GUI agent and qrexec services, so you can’t see VM screen. You could make this boot system screen visible with debug check option in VM settings tab or by setting ‘gui-emulated’ feature to 1:
qvm-features [windows] gui-emulated 1

That might be Windows kernel exception aka BSOD because of hot block plugging.

Stop hot attaching block devices to Windows :slight_smile:

Thanks for the response.
I have no choice; block device I want to attach is simply not USB, but internal SATA HDD, so it’s not possible to attach it as USB device.
That leaves me with --persistent option.
I couldn’t find if it’s enough to start only for the first time as:
qvm-block attach --persistent wincube dom0:sdXXXX

or I have to use this command every time I start win cibe?

If I have to start it every time, is there any automation procedure so when I start win cube from Qube Manager, it will be started with these parameters (I couldn’t find any “starting parameters” or such an option in Qubes->Settings).

Thanks in advance for your time.

EDIT: OK, I tried it and it seems to work. It looks like it is enough to use -p option only for the first time. Started cube, everything works flawlessly. Shut down the cube, started it again form Qube Manager without extra steps, only by clicking Start/Resume and it attached internal HDD again, and everything works.
Now it’s time to test your procedure for attaching USB device without qwt.
Thank you so much jevank!

Here are my findings.
My win7+qwt-4.1.65 standalone HVM on Q4.1 works flawlessly so far.

In order to enable seamless mode, there are 2 keys containing “SeamlessMode” DWORD in the registry:

  1. HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools
  2. HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools\qga

it is not enough to set the first one to “1” in order to get seamless mode. After restart, this value is reset to “0”.
If I set only the other one to “1”, I’m getting into seamless mode, and it turns out that the first one is also automatically set to “1”.
Therefore, it is not necessary to set both entries to “1”, but only the second entry.

The resolution of a seamless window is automatically set to dom0 native resolution (at least for me) no matter how big seamless window is, so simple maximize, or alt+f11 works flawlessly. So neat! I have checked this via calling “Win” key → Control panel → “Display resolution” .

In a non-seamless win7 qube, it is not possible to set resolution to dom0’s native resolution. It looks like it’s max height is lower for the height of a dom0 panel height + reserved space on it’s borders + the height of a top win7 cube window title bar. If the dom0 panel is set always to be hidden, then the resolution is automatically set to dom0 minus the height of a top win7 cube window title bar. In a fullscreen mode (alt+F11) the resolution is automatically set to dom0 native resolution.

WARNING: If you have set some startup items/apps in your win 7 cube (like I did), beside chosen app started in seamless mode, all other startup apps will also start in their own seamless windows, and you might run into unexpected/unknown issues (to me). If startup apps are set as minimized to tray / hidden, their windows will not be visible but they can be called via their keyboard hotkeys if there were ones.
If you don’t run into issues with this (like I didn’t) just close all startup apps seamless windows and you can continue to work in a desired/chosen app seamless window without an issue.

I tested now the new version 4.1-65.1, provided this week by @jevank. What was working in the previous build is still working. Additionally, now all Windows versions including 7 allow programs to be started from the XFCE menu and from starter icons placed on the desktop. So now there is a way to start applications in Windows 7 seamless mode, if no window of this VM is displayed. Still, it would be helpful if the Windows Start button was displayed in seamless mode, like it was with QWT 4.0.1.3 (sometimes, not always).

In seamless mode for Windows 7, graphics are displayed very slowly: When the frame of a window is dragged around the screen, the contents of this frame, i.e. the real window, follows sluggishly, and sometimes a “ghost window” consisting of an empty black rectangle remains on the screen. Starting a Windows menu by hitting the Windows keyboard key is also really slow. It may take some 5 to 10 seconds until the contents of this menu are displayed, and submenus are shown even more slowly. The previous version QWT 4.1-65 (from October or so) did not show this behaviour.

2 Likes

Thank you for your feedback.

Still, it would be helpful if the Windows Start button was displayed in seamless mode, like it was with QWT 4.0.1.3 (sometimes, not always).

I don’t remember seeing Start button displayed ever, need to check it.

No special changes in GUI components, so it might be by another reasons.

I’m planning couple more changes and will write a changelog.