Could it be debian-based VM? That might be the issue
Anyway, if you have successfully built once, just keep results - iso or rpm.
Could it be debian-based VM? That might be the issue
Anyway, if you have successfully built once, just keep results - iso or rpm.
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.
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:
Now, totally depressed, several things can be concluded by me.
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
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:
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.
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.
I found a possible reason for the slow menu display: I had a flickering screen after an update and corrected this by setting
$ xfwm4 --replace --vblank=off &
as @kommuni recommended in Flickering screen after 4.1 update. This seems to be the cause for the slow menus. Changing the vblank_mode
to xpresent
corrected this problem for the main menu and somewhat for the submenus. I have updated my post on this.
With regard to the start button: As far as I can reconstruct it, QWT cannot display the round Windows 7 default start button. But if this button is changed to a rectangular button, as can be selected by Classic Shell, it could be displayed.
I had applications in Applications menu even with QWT 4.1.65. All I did was to enabled administrator account, then refreshed applications in win7 qubes settings and voila - they were all there.
Beside this, I set strong password for administrator, put user "user’ in users group, removed write/execute permissions for user “user” for drive Q - private storage, as well as removed “Authenticated Users” for drive Q, created another standard user “userx” regarding permissions for Q, so If I want to write files or install some persistence apps on drive Q, I can do it only via shift + context menu as userx, while logged in as “user”. All strong passwords set.
Never too much security
The problems with the slow menu display seem to be connected with using an Nvidia grphics card and the workaround against the flickering screen. On another machine with Intel graphics, window and menu update behave normally.
i have deleted this post to avoid confusing others
powercfg -H off
[user@dom0 ~] qvm-features win10 audio-model ich6
[user@dom0 ~] qvm-features win10 stubdom-qrexec 1
Thanks for helping me troubleshoot this. I will start over fresh and incorporate your recommendations and report back soon.
In step 2 is fine. It doesn’t require QWT or smth special with windows 10.
Thanks to @jevank I have been able to get Windows 10 standalone VM working on Qubes 4.1rc2 with QWT. I have identified a few problems but only one is critical:
The first and only major issue is the win10 VM clock does not stay in sync between reboots. I will manually perform a successful internet time sync in the Wiin10 VM (settings> date & time > sync now) then reboot and the clock will revert back to what appears to be UTC (although my timezone will remain EST). This happens with the “set time automatically” option both ON and OFF.
The second issue is everytime you boot the win10 VM Qubes/Dom0 notification banner will pop up “Failed: qubes.NotifyTools - Failed to execute qubes.NotifyTools from win10 to dom0”
Is anyone else experiencing the clock issue?
I have documented all the steps I took to install a working Windows w/ QWT in Q4.1rc2 below to help others. If anyone has any suggestions on how to improve it before I publish it in the main forum please let me know.
EDIT: TO ANYONE READING DO NOT FOLLOW THE GUIDE BELOW IT IS NOT YET FINALIZED AND HAS SOME ERRORS I AM CLARIFYING IN DISCUSSIONS BELOW
STEP 1: Download Windows ISO (the latest as of writing is 21H2 Build 19044.1288)
My Windows 10 iso is stored in the vm “windows-iso”
STEP 2: Execute commands in Dom0 to setup Windows VM called “win10”
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win10
qvm-prefs win10 vcpus 2
qvm-prefs win10 memory 4096
qvm-prefs win10 maxmem 4096
qvm-prefs win10 kernel ''
qvm-volume extend win10:root 50G
qvm-volume extend win10:private 40G
qvm-prefs win10 netvm sys-firewall
qvm-features win10 audio-model ich6
qvm-features win10 stubdom-qrexec 1
qvm-start --cdrom=windowsiso:/home/user/win10pro.iso win10
STEP 3: Install Windows 10
Set default username to “user”
Set default password to “password”
Run windows update and install all available updates
Turn on automatic logon using registry editor
Turn off hibernation. Open windows terminal with admin rights:
powercfg -H off
Shutdown
Note, the VM will shutdown several times during installation and you will need to manually start again to continue installation.
STEP 4: Build latest QWT Source: @jevank
Install Fedora 33 template VM:
dom0: sudo qubes-dom0-update qubes-template-fedora-33
Create standalone fedora 33 VM “qwt-builder” with 15G private storage space
In qwt-builder VM terminal execute commands to build QWT:
cd ~
sudo dnf -y install git make mock
git clone https://github.com/QubesOS/qubes-builder
cd qubes-builder
make install-deps
make remount
make BUILDERCONF=example-configs/qubes-os-r4.1.conf COMPONENTS=builder-rpm get-sources
make BUILDERCONF=example-configs/qubes-os-r4.1.conf BASEURL=https://github.com GIT_PREFIX=tabit-pro/qubes- INSECURE_SKIP_CHECKING=windows-tools-cross COMPONENTS=windows-tools-cross get-sources
make BUILDERCONF=example-configs/qubes-os-r4.1.conf COMPONENTS=windows-tools-cross windows-tools-cross-dom0
sudo rpm -Uhv qubes-packages-mirror-repo/dom0-fc32/rpm/qubes-windows-tools*.noarch.rpm
sudo losetup -f /usr/lib/qubes/qubes-windows-tools.iso
STEP 5: Install QWT in Win10 VM
5a) execute this command in dom0 to attach QWT iso to win10 VM and boot
qvm-start win10 --cdrom qwt-builder:loop0
5b) In win10 file explorer find mounted iso and install QWT. Accept default options. if asked to reboot deny.
5c) Before restarting verify Win10 VM CPU is idle and reboot. after the vm powersoff do not restart.
5d) execute these two commands in dom0 with win10 powered off:
qvm-features win10 gui 1 qvm-prefs win10 qrexec_timeout 300
5e) start win10 VM. A GUI may not appear. Use Dom0 GUI to initiate an additional reboot BUT before you do wait until win10 CPU is idle (~5min). I am not 100% the logic of this step but i think some configuring is going on so let it run just in case. If anyone confirms this unecessary let me know. once your GUI is up check and confirm QWT is running correctly. poweroff.
5f) dom0:
qvm-prefs win10 default_user user
Glad it helps. Welcome to the club
try this
qvm-features win10 timezone localtime
Will be fixed in 4.1.66, it is almost ready
couple words to your tutorial:
qvm-start-gui --force-stubdomain win10
Trying to attach a block device crashes my Windows VMs with the error SYSTEM THREAD EXCEPTION NOT HANDLED
, no matter if qrexec-stubdom
is set or not.