On Tuesday, September 13, 2016 at 5:16:48 PM UTC, 3n7r...@gmail.com wrote: > 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/0f756bab-e728-4313-a132-6889de315f49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
win7-qwt1-1-fail.tar.gz
Description: Binary data
win7-qwt1-2-success.tar.gz
Description: Binary data
win7-qwt1-3-fail.tar.gz
Description: Binary data
win7-qwt1-4-success.tar.gz
Description: Binary data
win7-qwt2-1-success.tar.gz
Description: Binary data
win7-qwt2-2-fail.tar.gz
Description: Binary data
win7-qwt2-3-success.tar.gz
Description: Binary data
