I confirm with Windows 10 and stubdomain updated. Thanks, I’ll place issue on github.
2 Likes
Does qvm-start-gui VMNAME or qvm-start-gui --force-stubdomain VMNAME bring the window back?
nope
Ouch
I removed the PV disk drivers (see Migrate backups of Windows VMs created under Qubes R4.0 to R4.1. Now the VMs do not crash anymore when trying to attach a USB block device, but the device is not seen by Windows - no matter if the device is attached as a persistent or a dynamic device.
5a. When i run qubes-tools-x64, I get error message “This installation package is not supported by this processor type. Contact your product vendor”.
We didn’t build 32bit version, try Windows x64.
I’d try to restart sys-usb qube and check physical connections. Also, I’d restore win qube from backup and try. Out of that, I have no other idea (is there any message in event viewer, is the disk seen in disk management, but as unallocated space?)
This system has no sys-usb qube, because keyboard and mouse are connected via USB. The physical connection should be o.k., because the drive can be connected to Linux VMs. The Windows disk manager and the device manager do not see the drive, so there is no connection of the qube to the drive.
I am sorry to hear that. I guess QWT 4.1.66-1 with its Xen PV drivers installed doesn’t help as well?
I have the same problem, but with internal HDD, not USB attached via qvm-block, and --persistent option helps. Otherwise, qube crashes with
*** STOP: 0x0000007e (0xc0000005, 0xf72ddc76, 0xf791e920, 0xf791e570)
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
code…
I did not install the “Move user profiles” option in QWT when setting up the TemplateVM. An AppVM based on a Windows 10 TemplateVM seems to behave basically like a disposable VM - everything in a Windows AppVM is reverted back to baseline at reboot - is that correct?
Almost everything. Certainly everything on the C drive.
The caveat is: the contents of PhysicalDisk1 (the 2nd volume) are retained on each boot. Currently on your system it is not initialized/formatted and is likely nearly all zero data.
So, you personally can use that if you wish to format and store data to retain from boot to boot (that would be where a moved profile would have gone). However, an attacker could do the same and store data on it, perhaps in an attempt to further signature your windows account, even without formatting it.
So, not exactly fully disposable, but…close?
B
1 Like
wow that is great thanks for the explanation
If during the QWT setup on a Windows 10 TemplateVM i selected the “Move user profiles” option and then deployed an AppVM based off that TemplateVM - changes made within the user profile persist between reboots?
Yes.
Unless you do what I did..
I store files and (mostly portable) apps on an exclusive external storage.
@brendanhoar, do you think it is overkill, or unnecessary as additional precaution?
Hard to say without knowledge of your threat model.
For some workflows, I set up a Windows template and (effectively) use Windows in a disposable fashion - in that case, any data saved would need to go to external/remote storage. It can be useful in this case to write scripts (bat/cmd or ps1) to automate some tasks (depends on workflow).
For other workflows, I set up a windows AppVM, with local files, but don’t put it on a network.
B
Thanks for the response.
-
Never, ever it is allowed to user to write/execute to/from Q: Always, it can execute from C: (writing to it is disposable anyway).
-
When I want to write and execute, it hast to be on/from external storage and in template based AppVM. I’m not hiding, and sys-firewall is default VM. I don’t execute from C: This is when I use win app which has no alternative in a Linux world and why I waited for 4.1 for four years. When jevank fixes at-the-moment-a-must-attaching via --persist (if this is about him at all), this appVM will basically look useless to the one who starts it and doesn’t know that it has to attach external storage cause everything happens there. As of now, qvm-block detach after each use…
-
When I don’t want to write, I use dvm, and execute only from C: I’m hiding there behind sys-whonix. But I indeed have no special need for Windows dvm. If I need dvm, it’s the Linux one. But I’d like to set proper unggogled-chromium as I have under Windows, and so far still couldn’t customize it satisfactory under Whonix. I’ll try with other distros, it’s on my to-do list. I’ll be happy to get a recommendation.
-
When jevank fixes choppy sound for win qubes, one app goes offline as multimedia. And that would be all from Windows.
Basically no browsing except always contacting several same specific sites for the win app stated under 1. Everything else - Linux.
How can I change the MAC address for my different Windows-10-VM?
I just noticed they are all using my real MAC address.
I tried qvm-prefs win10 -s mac 00:16:3E:5E:6C:05
does not recognize this command
Update: Just drop the -s from the command it works
Dupe.
A new fix for fullscreen HVM issue under R4.1 is now available in current-testing repo.