Win 7, Qubes 3.2, qubes-windows-tools 3.2.2-3 struggles
Ed Welch
Getting going with linux I found pretty straight forward, no issues.
Trying to get a Windows 7 HVM template created, not going so well.
Thought I would post some of the issues I've had for posterity and also
see if I can get some help.
If you are like me and don't generally read long winded posts, please at
least scroll to my QUESTION at the bottom :)
Most of the instructions tell you to create a VM, however, none of them
tell you to increase the default VM specs. For win 7 64 it seems you
want to increase the RAM to 4096MB and primary partition to 40960MB
(40G) I know for a fact 20G is not enough to update windows 7 sp1 to latest.
You'll want to do this before anything else because it's more difficult
to do after you get started
Then I ran into the xen/cirrus video driver issue which causes windows
to freeze on the startup screen, found this issue with workaround:
https://github.com/QubesOS/qubes-issues/issues/2488
This workaround does the trick, but I think it's important to note a few
additional steps, after the last setup reboot and BEFORE YOU SHUTDOWN
windows and try to install the windows guest additions.
MAKE SURE to enable login without password through the netplwiz tool, it
seemed like this was the crucial step in avoiding this issue:
https://groups.google.com/forum/#!msg/qubes-users/Vbga8Z-DjHE/GVHIWIob5uIJ
Also, users mentioned in that thread the importance of adding more RAM,
however, for me it seemed that enabling login without password was the
step that avoided putting your VM in a totally unrecoverable BSOD loop.
Following the wiki instructions, I then installed the windows tools from
the qubes-dom0-current-testing repo (and also updated the qrexec_timeout
to 300 seconds) then switching back to the modified instructions for
working around the cirrus/xen bug I was able to boot into windows and
install the windows tools.
This is where I hit my next big stumbling point, during the installation
the PV drivers prompt you to reboot. DO NOT REBOOT until the
installation finishes, I did eventually see on this page 'Xen PV driver
components may display a message box asking for reboot during
installation – it’s safe to ignore them and defer the reboot.'
Really this needs to be promoted to
https://www.qubes-os.org/doc/windows-appvms/ IMO and in big bold letters
DO NOT REBOOT until the installation is completed kind of thing. If you
reboot before it finishes this is really unrecoverable and it's easier
to just blow away the vm and start again...
Ok, so now we get to where I'm stuck, my vm is installed,
qubes-windows-tools 3.2.2-3 is installed, however as soon as I start the
thing, it boots and the display immediately goes away, found this issue:
https://github.com/QubesOS/qubes-issues/issues/1896 which matches the
behavior I'm seeing, however, this was fixed some time ago, but not
totally sure when it was released??
My second, issue, which may actually be causing the first, seems to best
be described in this thread:
https://groups.google.com/d/topic/qubes-users/4OgwojFK-sI/discussion
Specifically I'm having the issue in the last comment, the only way I
can get any UI is if I boot with --debug, and when I do, I often see
that error linked: 'The GUI agent that runs in the VM 'win7' implements
outdated protocol (0:0), and must be updated.
After reading through that thread, several people were mentioning that
3.2.2-3 has seemed to make things less stable.
What I would like to do, is install the previous version of
qubes-windows-tools, but try as I might to manipulate the
qubes-dom0-update script into doing so I have not been able to do this,
I'm not even sure the older versions are kept in the repos??
QUESTION: Is there a way to install a specific version (whatever was
previous to 3.2.2-3) of qubes windows tools?
Thanks!
Ed
Ted Brenner
Ed
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/821726de-f5c1-d6a9-b15e-078e1f9cc56d%40edjusted.com.
For more options, visit https://groups.google.com/d/optout.
Ed Welch
I figured out how to install an older version of qubes-windows-tools
sudo dnf remove qubes-windows-toolssudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools-3.2.1-3.x86_64
From the testing repo: http://yum.qubes-os.org/r3.2/current-testing/dom0/fc23/rpm/
I was able to see the different versions so I chose the most recent prior to 3.2.2-3, which was 3.2.1-3.
And I have to say, this was a whole different ballgame, everything with this version went really smoothly, I'm up and running now with an updated win 7 instance, gui comes up fine, never even needed debug mode.
I'm not sure if Ted and I are just among the first to do a clean install with 3.2.1-3 or if there is something about our systems giving us these issues.
Anyone please let me know how I can help (filing issues in github, logs, etc) but for now I'm happy with how the older version is working.
Ed
Ted Brenner
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5b78e36d-376b-0950-4ea2-cd05197f50cd%40edjusted.com.
Ed Welch
Regards,
Ed
Ted Brenner
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bf3686dd-0265-6415-ba09-9e95abab69df%40edjusted.com.
Ed Welch
Also, it mentions that the Xen PV disk driver is disabled by default due to BSOD after installation. But then it runs fine after that. Does this mean that we can install it and just reboot after the BSOD? Or we should install everything but the Xen PV disk driver, then once it is stable, install the driver? And what do we lose by not having the Xen PV disk driver? Or rather, what do we gain?
Thanks!Ted
qvm-block
will not work for the VM' and originally I was hoping to be able to
do usb passthrough to the windows 7 vm. I've since learned this
functionality isn't implemented yet. I also learned that PCI
passthrough requires the VT-d extension (which I don't have) so
while my windows works fine, I have no way to connect devices to it
:( (well, that's not entirely true, some people have reported
success it seems with various configurations of the usbip project,
but my plan is to install qubes on another machine I have which does
have VT-d so I'm mostly waiting until I complete that installation)I'm not sure if there are other advantages to the PV disk drivers, having them installed has not caused me any issues.
I installed everything in one shot, enabling the PV disk drivers, and then rebooting when the installation was complete.
Good luck!
Ed
Drew White
There are bugs in the tools that I pointed out in version 2 of the tools, and they still aren't fixed.
The worse the issues got, the more I pressed it, and the more issues they put in instead of fixing.
Then they fixed one issue, and then started putting more in.
3.2.1.3 is alright and works, as I posted about months ago after I upgraded to 3.2.2.3 and it broke Windows and caused lag in the Qubes Video Driver along with a major flicker.
The only way to resolve that was to remove QWT and then perform a complete reinstall of it, without the video driver.
But to do that I had to start in safe mode, and enable the standard display adapter and disable the Qubes Video.
I've been complaining for so long about things it's not funny, and they have not resolved the issues. (yet) That was stared in Qubes 2.
Now at Qubes 4, I don't expect there to be any advancement in the Windows integration for the GPU side of things.
But I stick to Qubes for security, that's one thing that they did get right, the whole reason behind it.
So all in all, since QWT changed hands a couple of times, things went wrong.
So in essence, I just hope for the future because having multiple people work on the QWT system and it going wrong mainly after it changed hands, was expected.
So, in a few years, the bugs in QWT 2* GFX side might be fixed.
Maybe they might do a complete re-write and get it all resolved in a month or 2.
Ed Welch
> Problem is, they don't care.
many many threads for info, looking at git/documentation/etc. I really
have not gotten this impression at all, I regularly see developers
responding to threads and offering assistance.
support is not a primary focus of this project. Windows tools/support
seems to be mainly user contributed, and while mostly functional, Qubes
in no way offers the kind of windows experience running on bare metal
would get you.
This is perfectly ok with me, and in my personal opinion I think if
someone is looking for a windows machine with full hardware acceleration
(to support something like game playing), Qubes (or almost any
virtualization technology) is not going to be the answer.
If I were to offer any criticism to the qubes project, strictly
regarding Windows support, it would be that their documentation should
set expectations of what Windows support is available a little more
clearly. After looking at the Qubes homepage a few weeks ago before
heading down the road of installing it myself, I was mostly expecting
windows support to be on par with linux ( I was never expecting graphics
acceleration or much direct hardware, as it is made clear linux appvm's
do not support hardware acceleration). I was however expecting things
like usb passthrough to work, and I was troubled by problems with the
most recent version of QWT which the docs I don't think quite explained
(so I decided to help by submitting my experience to the news group
archive to hopefully help others)
On a personal note, after reading a handful of your emails last night, I
found the tone of all your emails leaving a rather poor taste in my
mouth. There was an arrogance and sense of entitlement that I think
totally detract from any useful information you may have been providing.
It sounds like you are doing good work with slackware and with good
purpose, but then I read comments like "I know more about qubes than the
developers do by now." and "I've been complaining for so long about
things it's not funny, and they have not resolved the issues. (yet)" and
I'm not sure if you realize just how off putting that is to someone who
is working very hard on an open source project.
The qubes developers do not owe us anything, rather quite the opposite,
we owe them immensely for all their hard work creating a fantastic
operating system!
Ed
Drew White
> On 03/10/2017 01:28 AM, Drew White wrote:
> > Problem is, they don't care.
> I'm new to this OS and new to this community, however, after searching
> many many threads for info, looking at git/documentation/etc. I really
> have not gotten this impression at all, I regularly see developers
> responding to threads and offering assistance.
Perhaps I should have provided more information in that one statement than providing the information in the whole post.
It's the whole post that provides the full details, not just one line.
Things change, things get passed from person to person and not everything is passed on properly. So things go wrong. They do their best, and there are bugs. Thing is, they aren't really focused on the Windows side for the tools, because the bugs that were there in version 2, if they were fixed, then the bugs they are trying to fix now would not be there due to the root cause being fixed. And that gives the impression that they don't care that much about the GFX side, because everything else is working, and there are just some idiosyncrasies of it. I don't mean that they don't actually care, it's more of a turn of phrase rather than a literal meaning.
> >
> > There are bugs in the tools that I pointed out in version 2 of the tools, and they still aren't fixed.
> >
> > The worse the issues got, the more I pressed it, and the more issues they put in instead of fixing.
> >
> > Then they fixed one issue, and then started putting more in.
> >
> > 3.2.1.3 is alright and works, as I posted about months ago after I upgraded to 3.2.2.3 and it broke Windows and caused lag in the Qubes Video Driver along with a major flicker.
> >
> > The only way to resolve that was to remove QWT and then perform a complete reinstall of it, without the video driver.
> > But to do that I had to start in safe mode, and enable the standard display adapter and disable the Qubes Video.
> >
> > I've been complaining for so long about things it's not funny, and they have not resolved the issues. (yet) That was stared in Qubes 2.
> >
> > Now at Qubes 4, I don't expect there to be any advancement in the Windows integration for the GPU side of things.
> >
> > But I stick to Qubes for security, that's one thing that they did get right, the whole reason behind it.
> >
> > So all in all, since QWT changed hands a couple of times, things went wrong.
> > So in essence, I just hope for the future because having multiple people work on the QWT system and it going wrong mainly after it changed hands, was expected.
> >
> > So, in a few years, the bugs in QWT 2* GFX side might be fixed.
> > Maybe they might do a complete re-write and get it all resolved in a month or 2.
> >
>
> I would say my experiences thus far have given me the impression windows
> support is not a primary focus of this project. Windows tools/support
> seems to be mainly user contributed, and while mostly functional, Qubes
> in no way offers the kind of windows experience running on bare metal
> would get you.
>
Well, as soon ass they started work on version 4, version 3 went to the very back burner. The developers told me that version 3 would be not worked on very much, if at all, by the developers after version 4 comes out.
I agree that the system in general is okay.
There are just a few things wrong with it, that still have yet to be resolved that have been there since version 2 of Qubes, and perhaps earlier too.
There are things that they could have done differently at the very start which would have made this operating system one of the best out there the way that it is built. But they chose what they chose. They had their reasons for chosing it.
And as I say, it's all jsut personal opinion.
Daniel Nelson
I tried what you suggested about backing out the latest QWT and installing the previous version. I tried it first with simply uninstalling from my VM, with quirky results, so I went ahead and created a fresh VM. This particular behavior continues, though, also with the GUI agent outdated protocol error on exit, and usually with two Win7 related QubesDB files that need to be manually deleted prior to relaunching as well.
yura...@gmail.com
> Did you ever make additional progress on your problems with QWT? I encountered all the same issues you did, and the one I've not been able to solve is always having to run my Win7 apps in debug mode, thus losing the possibility of lovely seamless integration.
>
> I tried what you suggested about backing out the latest QWT and installing the previous version. I tried it first with simply uninstalling from my VM, with quirky results, so I went ahead and created a fresh VM. This particular behavior continues, though, also with the GUI agent outdated protocol error on exit, and usually with two Win7 related QubesDB files that need to be manually deleted prior to relaunching as well.
Did you try the opposite approach and use the packages from the testing repositories?
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
I'm unaware if the fix is still in testing, however the MegaTraveller guy verified (28 December, 2016) that this worked for him, in this thread https://github.com/QubesOS/qubes-issues/issues/2488
Also, as annoying and time consuming it may be, you might want to make a fresh HVM install again. As far as I've understood, it's not recommended to re-install QWT.
I would however suggest to make a fresh backup of your Win7 from the moment it's just freshly installed, so you don't have to do more work than needed in the future.
Daniel Nelson
Thanks very much for the additional link. I'll do more reading.
As to your questions... I was unable to fetch QWT from the live repo. I've been using only what I can get from the test repo.
I tried both ways of doing things already... meaning that I tried uninstalling the tools from the Win7 VM, removing them from Qubes, fetching the previous version, then installing them into the VM. Since that didn't work I then did it the other way (deleting the VM and starting from scratch, but still with the previous version of QWT). The first way gave a pretty unstable Win7 VM. The second way worked fine, but the exit errors and lack of seamless functionality was the same as with the latest version of QWT.
I'll dig more into the link you provided and see if I can find some joy. Thanks again!
PhR
when working with Qubes, I write all information into my own Wiki.
Here my notes regarding the installation of a Window 7 HVM:
Windows HVM
Skip to end of metadata
See also: https://www.qubes-os.org/doc/windows-appvms/
- Update Windows Tools
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
- Mount External HDD containing the windows installer ISO to the
VM untrusted
qvm-usb -a untrusted sys-usb:4-3
- Create new windows VM
qvm-create win7 --hvm --label green
- Start new windows VM with attached installer-ISO
qvm-start globits --cdrom=untrusted:/run/media/user/WDEXT2TB/win7pro-32-de.iso
(will start the VM and run the installer ISO)
- First restart after ~4 min
restart manually qvm-start globits
- Further installation, restart manually
qvm-start globits
- Further installation, restart manually
qvm-start globits
- Start into Desktop / Updates -> decide later
- Allow unsigned drivers by opening a CMD as administrator
bcedit /set testsigning on
- Install Windows Tools
qvm-start globits --install-windows-tools
- Change qrexec timeout because User Folder will be moved
qvm-prefs -s <vm-name> qrexec_timeout 300
- Enable Debug Mode via Qubes Manager GUI
- Enable auto-Login by starting netplwiz within Windows vm
- Enable Seamless Mode / Disable Debug Mode via Qubes Manager GUI
Attention:
i had big problems getting seamless mode to work, and found out the reason after lots of troubleshooting.
It seems that seamless mode will not work with all display resolutions.
I have 3 K-display with a native resolution of 2.880 x 1.620 Pixels.
With this resolution seamless mode didn't work, I had to change the resolution to a standard resolution.
You might also look here:
https://groups.google.com/forum/#!msg/qubes-users/Ia73yb4lCGA/s8Qp9dl4CQAJ
https://github.com/QubesOS/qubes-issues/issues/1896
Which resolution are you using in Qubes?
- PhR
Daniel Nelson
The one thing I've not done too much fiddling with is the resolution. I've tried 1024x768 without joy. I will continue to investigate further with different resolutions, and I will try also to more permanently change the video driver in use.
Thanks again!
Drew White
> Thanks for all the additional notes. Everything you did perfectly matched what I've done except that I also had to copy the win7.conf and edit it to change the video from "xen" to "cirrus," which is also pretty well documented in various places. I had to do this both during Windows install, and then again during QWT install, but it worked as advertised.
> The one thing I've not done too much fiddling with is the resolution. I've tried 1024x768 without joy. I will continue to investigate further with different resolutions, and I will try also to more permanently change the video driver in use.
>
> Thanks again!
Why do you all have to change from Xen to Cirrus in the config?
I use XEN as my video. And I have no issue with many graphical things now.
Only time I have issues is when I try to start the Windows Guest when I'm running 5 monitors. As long as I start it with only 1, then proceed to add the rest, it's fine. But I've said all this before so I swill not repeat it all over again.
But that's the only real issue I have with the video side of it.
So I am just curious as to why so many people I see are having to change to Cirrus from XEN?
Adrian McLeod
Drew White
> That seems to be a great question! I have no idea what the answer is. :-)
> I can only say that I experienced the same problem symptoms that several people before me did - that Windows setup hung at the initial boot screen with glowing logo. Following the same steps that helped many others also helped me (changing to Cirrus driver). All the details to the how are summarised nicely here: https://github.com/QubesOS/qubes-issues/issues/2488. I don't recall any mention of the why, though.
I have had it lock once before because of other issues, which i just had to restart the pc to unlock the loops to get it working again.
> I guess I can also say that my system is a standard Intel Skylake Core M7 utilising the on-processor Intel HD graphics, and that my BIOS is a combination of Coreboot and Tianocore, purely UEFI. Just some fundamental driver incompatibility maybe.
>
>
> Incidentally, in case it might help anybody that comes after me and reads this thread...
>
>
> I upgraded from the previous build of QWT to the latest (3.2.2-3) since the previous version didn't work particularly better for me.
> Since then I was able to run Windows apps at least twice in seamless mode, no debug! It's pretty random, though. It fails to display a window at all most times, and the VM has to be killed. I will try to find time to look deeper, maybe increase the loglevel of some of the components and see more of what's happening when it fails vs. when it succeeds. Not sure on when I can find the time for that, but I'll try to remember to report back if I find anything that allows me to get it working consistently all the time. For now I've accepted running it always in debug mode for the stability.
>
1366x768
I also have my PC running at 1080p
My Dual Monitor Desktop is one monitor at 1920x1080 and the other at 1600x900
And that works fine.
But anything larger than that I have to run the system BEFORE i activate those screens and have the UI be notified of the size change to then do the resize after it's all working correctly and active.