On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote: > On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek Marczykowski-Górecki > wrote: > > I haven't tested this version on 3.1, but I think it should work. Just > > uploaded to current-testing. > > Thanks! > > Everything I tested is flawless **until the #updates stage**. > > ================================= > > installation: no issues (up to #updates - see below) > > multi-monitor: not tested > tested resolution: 4 megapixels > seamless mode: working > full desktop mode: working > > secure clipboard: working > private storage: working > qvm-block: working > qvm-run: working > qvm-open-in-vm: working > qvm-copy-to-vm: working > auto-networking: working > > ================================= > > Test Procedure > > #install windows > > QubesVMM: create templateHVM: "win-7" > netVM: none; vCPU: 4; RAM: 4GB > Private Storage: 10GB; System Storage: 40GB > > qvm-start win-7 --cdrom=appVM:/path/to/iso > iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso > > disable UAC > disable updates > enable auto-logon > bcdedit /set testsigning on > shutdown > > #install QWT > > qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools > clone win-7 to win-7-qwt-1, win-7-qwt-2 > > for each qwt clone: > qvm-prefs -s win-7-qwt-? qrexec_timeout 600 > qvm-start win-7-qwt-? --install-windows-tools > > [note re: PV disk drivers. For my first test (with just 1 vm), I disabled PV > disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. No > idea if there is any causality there. Reason for enabling PV disk is that > installing .Net package required 30 minutes just to see any movement in the > progress bar. (Might not all be due to PV disk - slowness might be causing > other things to timeout?) With PV disk enabled, the update took less than 10 > secs. I might guess that many bug reports are due to the INSANELY slow non-PV > disk ops being mistaken for system hangs... To be fair, Virtualbox similarly > has bad disk performance prior to installing Guest Additions. Surprisingly, > no issues at all installing PV disk.] > > #update Windows **Problems here** > > wsusoffline update > > [future steps: > enable netVM > windows activation > windows update > ] > > ================================= > > Made it to the end of the offline update process with 2 identical clones > following the exact same procedure. One boots and is ready to go. The other > received dom0 notice about outdated GUI protocol. Will not complete boot > after repeated attempts. I can't make any sense of the logs - can't even > figure out which ones are relevant. Just to rule out any difference in > procedure that I might have overlooked, I have trashed both clones and > brought 2 fresh clones to just prior to the update process. Please let me > know how to proceed, ie which logs to collect. > > One oddity that I noticed was that the Qubes VM Window name doesn't appear to > be consistent. For example, with a Windows TemplateHVM named "win-7" and a > user/domain of user@host; the name of the Windows window will alternate? > between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all? > > I don't envy you Rafał. Thanks for working on this.
So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. They were installed with networking off so they should be identical. QWT (complete install) was installed without any errors. I've been starting and shutting down each of them repeatedly with these results (Qubes logs attached): win7-qwt1-1-fail: no desktop loaded; hanging on yellow state win7-qwt1-2-success: successful boot to desktop win7-qwt1-3-fail: no desktop; qrexec error win7-qwt1-4 success: successful boot to desktop (no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1") (no logs) #6: success (named "host") (no logs) #7: success (named "host") win7-qwt2-1-success win7-qwt2-2-fail: hanging yellow win7-qwt2-3-success (no logs) #4: fail (no logs) #5: fail (no logs) #6: success (named "host") (no logs) #7: fail (no logs) #8: fail (no logs) #9: success (named "win7-qwt2") As stated before, the VM window title is unpredictable - sometimes, the window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] host". This is true of both vm's. A race condition? I am inclined to suggest that the VMs function more properly when they are named "host". Also, after all the starts and stops, I've got a leftover VM window that wasn't cleaned up properly and can't be closed. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/23d971c4-ffff-48e0-a325-8ac56f3b7e84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
