Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On 02/08/18 00:18, Yuraeitha wrote:
@Ivan
On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
On 02/04/18 19:26, Yuraeitha wrote:
On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
Also it seems like some functions "might (maybe)" work as intended, for example
I can copy files between VM's and Win7, on a Win7 that was installed on Qubes 3.2., but
backup restored on Qubes 4. Others seem like they can do this too. Also it seems it's a
common problem not to be internet in the restored Q3.2-Win7, perhaps the code is
different in regards to how it ties networking with Qubes 4? I have no idea about the
rest of the mechanics from a users perspective though, and most certainly not as a
developer as I unfortunately don't have such skills, I wish I could help more.
I just spent a bit of time restoring my windows VM from 3.2, here are a
few notes that might be helpful to work around some bugs that you're
probably hitting too (I haven't filed any issues yet):
- PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
the real pref value. -> use qvm-prefs vmname virt_mode to make sure
you're really in HVM mode.
- Networking: the PV network adapter was stuck at "Identifying" ;
pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
shows that the requests were sent to the gateway's ip and were rejected.
The reason seems to be that in R4.0 VMs are now using the exposed
"/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
was the same as "/qubes-gateway" (see [1]). In my setup,
"/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
is 10.137.0.6. DNS requests are rejected because they're sent to
10.137.0.6 instead of 10.139.1.{1,2}
workaround 1-> manually set the DNS servers to
/qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
but the PV adapter was still suck at "identifying" and my Amazon Kindle
for PC app complained about finding no network (it seems there's a
windows "connectivity" API/flag that some apps use). However you will
have to do this each time after boot since Qubes tools will reset the
network settings.
workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
messing with your network settings, and manually set the VM's IP and DNS
servers in the PV adapter network setting. Everything should then work
OK, the only problem being that you'll have to make sure you keep your
network settings synced (esp. the IP when you clone the VM).
- Copying to/from the Win VM: works perfectly - you just have to type
twice the destination VM (once in Windows, once in Qubes/dom0), since
Qubes Tools aren't updated to reflect R4.0 new "way".
note: before finding what was causing the connectivity problem I tried
to update xen's windows PV drivers [2] but it broke the VM (ie. it
wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
to fiddle with this.
I was thinking about posting those steps on qubes-users@ but I don't
feel I had done enough testing on my VM yet. I see you're quite active
on qubes-users so feel free to redact/post some of my remarks if you
think they'll help.
[ an unofficial wiki would be a helpful bridge between the MLs and
Qubes' official documentation: it's difficult to skim through all the
related ML posts and IMO Qubes' official documentation shouldn't include
crappy workaround hacks like the ones I've described above ].
[1] https://www.qubes-os.org/doc/vm-interface/
[2] https://www.xenproject.org/developers/teams/windows-pv-drivers.html
@Evan
Ivan :)
Thanks Evan! This really looks promising, I will go and try it out tomorrow if
I can scrap some free-time to try it out. I'll post here the moment I've tried
it, hopefully I can get the internet working.
BTW I assumed there was a single "Qubes Tools" service responsible for
setting the network, launching qubesdb daemon, ..., but I noticed a bit
after my post that each task was handled by a different service. So you
can simply disable the "Qubes Network Setup" service instead of renaming
the .exe
Also,
https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c
indeed shows that qubesGateway (/qubes-gateway) is used for DNS (line
287). The code is easy to understand and adding the new DNS variables, +
setting the servers accordingly (if the variables aren't empty) should
be straightforward. I don't have a Windows build environment to test any
changes though.
It's also very ensuring to hear that it's safe to copy files between Win7 and
other VM's. I was a bit stressed out over this one due to worry of bit-rot.
Well, it is working but I can't say how safe it is. But I imagine that
R4.0 would disable such copy operations if they were deemed unsafe.
I'll get back to you when I've tried this out,
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
Hi Marek,
On 02/08/18 03:13, Marek Marczykowski-Górecki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Feb 07, 2018 at 02:18:59PM -0800, Yuraeitha wrote:
@Ivan
On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
On 02/04/18 19:26, Yuraeitha wrote:
On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
Also it seems like some functions "might (maybe)" work as intended, for example
I can copy files between VM's and Win7, on a Win7 that was installed on Qubes 3.2., but
backup restored on Qubes 4. Others seem like they can do this too. Also it seems it's a
common problem not to be internet in the restored Q3.2-Win7, perhaps the code is
different in regards to how it ties networking with Qubes 4? I have no idea about the
rest of the mechanics from a users perspective though, and most certainly not as a
developer as I unfortunately don't have such skills, I wish I could help more.
I just spent a bit of time restoring my windows VM from 3.2, here are a
few notes that might be helpful to work around some bugs that you're
probably hitting too (I haven't filed any issues yet):
- PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
the real pref value. -> use qvm-prefs vmname virt_mode to make sure
you're really in HVM mode.
- Networking: the PV network adapter was stuck at "Identifying" ;
pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
shows that the requests were sent to the gateway's ip and were rejected.
The reason seems to be that in R4.0 VMs are now using the exposed
"/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
was the same as "/qubes-gateway" (see [1]). In my setup,
"/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
is 10.137.0.6. DNS requests are rejected because they're sent to
10.137.0.6 instead of 10.139.1.{1,2}
Yes, exactly. Actually /qubes-primary-dns entry is present on R3.2 too,
but is the same as /qubes-gateway.
workaround 1-> manually set the DNS servers to
/qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
but the PV adapter was still suck at "identifying" and my Amazon Kindle
for PC app complained about finding no network (it seems there's a
windows "connectivity" API/flag that some apps use). However you will
have to do this each time after boot since Qubes tools will reset the
network settings.
workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
messing with your network settings, and manually set the VM's IP and DNS
servers in the PV adapter network setting. Everything should then work
OK, the only problem being that you'll have to make sure you keep your
network settings synced (esp. the IP when you clone the VM).
- Copying to/from the Win VM: works perfectly - you just have to type
twice the destination VM (once in Windows, once in Qubes/dom0), since
Qubes Tools aren't updated to reflect R4.0 new "way".
I guess this should be easy to fix, just need to skip the first prompt
and provide "$default" as destination name in qrexec call.
Looks this file is relevant:
https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs
Compare "Copy to other VM" and "Edit in DispVM" entries.
note: before finding what was causing the connectivity problem I tried
to update xen's windows PV drivers [2] but it broke the VM (ie. it
wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
to fiddle with this.
There is also difference in emulated hardware - in R3.2 we use MiniOS
based stubdomain, with "qemu-traditional" (vry old, mostly
unmaintained qemu fork), while in R4.0 we use Linux based stubdomain,
with recent version of upstream qemu (2.10.1 at the moment).
This may cause problems when migrating HVMs between R3.2 and R4.0. There
is a way to switch some VMs on R4.0 to the old qemu, and it is
automatically done when restoring HVMs from R3.2 backup:
qvm-features VMNAME linux-stubdom ''
('' means to _disable_ linux stubdomain...)
When testing new installations, I recommend using new qemu (default
settings when you create VM). You can copy windows tools installation
iso from R3.2, it's in /usr/lib/qubes/qubes-windows-tools.iso.
good to know !
(...)
BTW I assumed there was a single "Qubes Tools" service responsible for
setting the network, launching qubesdb daemon, ..., but I noticed a bit
after my post that each task was handled by a different service. So you
can simply disable the "Qubes Network Setup" service instead of renaming
the .exe
Also,
https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c
indeed shows that qubesGateway (/qubes-gateway) is used for DNS (line
287). The code is easy to understand and adding the new DNS variables, +
setting the servers accordingly (
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@awokd On Thursday, February 8, 2018 at 12:10:18 AM UTC+1, awokd wrote: > On Wed, February 7, 2018 10:38 pm, Yuraeitha wrote: > > > > > > Have you ever experienced crashes while running search files on disk from > > the Windows menu? If so, maybe we can turn off the search function to > > avoid any issues? > > Disk activity seems to trigger it for me too. I still get the occasional > crash when anti-virus scan runs for example, but it's been rare enough I > haven't looked into it any further. I already have search disabled so yes, > try it out too! Will do, hopefully it'll make a difference. It's frustrating that anti-virus does it too though. Maybe we can disable it on the AppVM, but only keep it enabled on the template of Windows? I never got around to get Windows template to work though, but I imagine it might be a way to bypass the anti-virus issue on daily use-cases. I'm pondering about the Superfetch service too, I recall from earlier days that Windows Superfetch could give issues, but as far as I remember it was never truly verified, at least not as an official note. Situations seem to be when having too little RAM on a hardware Windows install, perhaps it causes issues too with too little RAM on a VM install? I'll try disable mine, but I'm not sure if it will change anything related to the stability, other than its intended function of a bit faster application-start of course. Another issue I found, which I'm not yet sure is a problem or not, seems to be when closing Windows via the Qubes 4 widget, that it happens a lot, lot faster, compared to if you close Windows with the Windows own shutdown button, which is slow, but will eventually shutdown entirely in Qubes as well. I haven't verified it yet, but it does look like the Qubes 4 doesn't give room for updates to tick. Perhaps the intention here is that Qubes 4 widget is meant for AppVM versions of Windows, while the template should be shutdown with Windows's own shutdown command? It's fortunate that seamless mode doesn't have to be enabled on the Windows template to make use of the AppVM seamless mode. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3907a2ac-49b7-4486-be57-85055a880458%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Thursday, February 8, 2018 at 2:13:42 AM UTC+1, Marek Marczykowski-Górecki
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, Feb 07, 2018 at 02:18:59PM -0800, Yuraeitha wrote:
> > @Ivan
> >
> > On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> > > On 02/04/18 19:26, Yuraeitha wrote:
> > > > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> > > >>> Also it seems like some functions "might (maybe)" work as intended,
> > > >>> for example I can copy files between VM's and Win7, on a Win7 that
> > > >>> was installed on Qubes 3.2., but backup restored on Qubes 4. Others
> > > >>> seem like they can do this too. Also it seems it's a common problem
> > > >>> not to be internet in the restored Q3.2-Win7, perhaps the code is
> > > >>> different in regards to how it ties networking with Qubes 4? I have
> > > >>> no idea about the rest of the mechanics from a users perspective
> > > >>> though, and most certainly not as a developer as I unfortunately
> > > >>> don't have such skills, I wish I could help more.
> > > >>
> > > >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> > > >> few notes that might be helpful to work around some bugs that you're
> > > >> probably hitting too (I haven't filed any issues yet):
> > > >>
> > > >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> > > >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> > > >> you're really in HVM mode.
> > > >>
> > > >> - Networking: the PV network adapter was stuck at "Identifying" ;
> > > >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> > > >> shows that the requests were sent to the gateway's ip and were
> > > >> rejected.
> > > >> The reason seems to be that in R4.0 VMs are now using the exposed
> > > >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> > > >> was the same as "/qubes-gateway" (see [1]). In my setup,
> > > >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> > > >> is 10.137.0.6. DNS requests are rejected because they're sent to
> > > >> 10.137.0.6 instead of 10.139.1.{1,2}
>
> Yes, exactly. Actually /qubes-primary-dns entry is present on R3.2 too,
> but is the same as /qubes-gateway.
>
> > > >> workaround 1-> manually set the DNS servers to
> > > >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> > > >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> > > >> for PC app complained about finding no network (it seems there's a
> > > >> windows "connectivity" API/flag that some apps use). However you will
> > > >> have to do this each time after boot since Qubes tools will reset the
> > > >> network settings.
> > > >>
> > > >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> > > >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> > > >> messing with your network settings, and manually set the VM's IP and
> > > >> DNS
> > > >> servers in the PV adapter network setting. Everything should then work
> > > >> OK, the only problem being that you'll have to make sure you keep your
> > > >> network settings synced (esp. the IP when you clone the VM).
> > > >>
> > > >> - Copying to/from the Win VM: works perfectly - you just have to type
> > > >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> > > >> Qubes Tools aren't updated to reflect R4.0 new "way".
>
> I guess this should be easy to fix, just need to skip the first prompt
> and provide "$default" as destination name in qrexec call.
> Looks this file is relevant:
> https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs
>
> Compare "Copy to other VM" and "Edit in DispVM" entries.
>
> > > >> note: before finding what was causing the connectivity problem I tried
> > > >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> > > >> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> > > >> Qubes Tool's drivers were at the same version as Xen's (8.2), so no
> > > >> need
> > > >> to fiddle with this.
>
> There is also difference in emulated hardware - in R3.2 we use MiniOS
> based stubdomain, with "qemu-traditional" (vry old, mostly
> unmaintained qemu fork), while in R4.0 we use Linux based stubdomain,
> with recent version of upstream qemu (2.10.1 at the moment).
> This may cause problems when migrating HVMs between R3.2 and R4.0. There
> is a way to switch some VMs on R4.0 to the old qemu, and it is
> automatically done when restoring HVMs from R3.2 backup:
>
> qvm-features VMNAME linux-stubdom ''
>
> ('' means to _disable_ linux stubdomain...)
>
> When testing new installations, I recommend using new qemu (default
> settings when you create VM). You can copy windows tools installation
> iso from R3.2, it's in /usr/lib/qubes/qubes-windows-tools.iso.
>
> (...)
>
> > > BTW I as
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Feb 07, 2018 at 02:18:59PM -0800, Yuraeitha wrote:
> @Ivan
>
> On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> > On 02/04/18 19:26, Yuraeitha wrote:
> > > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> > >>> Also it seems like some functions "might (maybe)" work as intended, for
> > >>> example I can copy files between VM's and Win7, on a Win7 that was
> > >>> installed on Qubes 3.2., but backup restored on Qubes 4. Others seem
> > >>> like they can do this too. Also it seems it's a common problem not to
> > >>> be internet in the restored Q3.2-Win7, perhaps the code is different in
> > >>> regards to how it ties networking with Qubes 4? I have no idea about
> > >>> the rest of the mechanics from a users perspective though, and most
> > >>> certainly not as a developer as I unfortunately don't have such skills,
> > >>> I wish I could help more.
> > >>
> > >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> > >> few notes that might be helpful to work around some bugs that you're
> > >> probably hitting too (I haven't filed any issues yet):
> > >>
> > >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> > >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> > >> you're really in HVM mode.
> > >>
> > >> - Networking: the PV network adapter was stuck at "Identifying" ;
> > >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> > >> shows that the requests were sent to the gateway's ip and were rejected.
> > >> The reason seems to be that in R4.0 VMs are now using the exposed
> > >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> > >> was the same as "/qubes-gateway" (see [1]). In my setup,
> > >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> > >> is 10.137.0.6. DNS requests are rejected because they're sent to
> > >> 10.137.0.6 instead of 10.139.1.{1,2}
Yes, exactly. Actually /qubes-primary-dns entry is present on R3.2 too,
but is the same as /qubes-gateway.
> > >> workaround 1-> manually set the DNS servers to
> > >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> > >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> > >> for PC app complained about finding no network (it seems there's a
> > >> windows "connectivity" API/flag that some apps use). However you will
> > >> have to do this each time after boot since Qubes tools will reset the
> > >> network settings.
> > >>
> > >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> > >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> > >> messing with your network settings, and manually set the VM's IP and DNS
> > >> servers in the PV adapter network setting. Everything should then work
> > >> OK, the only problem being that you'll have to make sure you keep your
> > >> network settings synced (esp. the IP when you clone the VM).
> > >>
> > >> - Copying to/from the Win VM: works perfectly - you just have to type
> > >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> > >> Qubes Tools aren't updated to reflect R4.0 new "way".
I guess this should be easy to fix, just need to skip the first prompt
and provide "$default" as destination name in qrexec call.
Looks this file is relevant:
https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs
Compare "Copy to other VM" and "Edit in DispVM" entries.
> > >> note: before finding what was causing the connectivity problem I tried
> > >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> > >> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> > >> Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
> > >> to fiddle with this.
There is also difference in emulated hardware - in R3.2 we use MiniOS
based stubdomain, with "qemu-traditional" (vry old, mostly
unmaintained qemu fork), while in R4.0 we use Linux based stubdomain,
with recent version of upstream qemu (2.10.1 at the moment).
This may cause problems when migrating HVMs between R3.2 and R4.0. There
is a way to switch some VMs on R4.0 to the old qemu, and it is
automatically done when restoring HVMs from R3.2 backup:
qvm-features VMNAME linux-stubdom ''
('' means to _disable_ linux stubdomain...)
When testing new installations, I recommend using new qemu (default
settings when you create VM). You can copy windows tools installation
iso from R3.2, it's in /usr/lib/qubes/qubes-windows-tools.iso.
(...)
> > BTW I assumed there was a single "Qubes Tools" service responsible for
> > setting the network, launching qubesdb daemon, ..., but I noticed a bit
> > after my post that each task was handled by a different service. So you
> > can simply disable the "Qubes Network Setup" service instead of renaming
>
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
On Wed, February 7, 2018 10:38 pm, Yuraeitha wrote: > > Have you ever experienced crashes while running search files on disk from > the Windows menu? If so, maybe we can turn off the search function to > avoid any issues? Disk activity seems to trigger it for me too. I still get the occasional crash when anti-virus scan runs for example, but it's been rare enough I haven't looked into it any further. I already have search disabled so yes, try it out too! -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/464d2dd904f520d68ff82d47a4ca4d4b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@awokd On Sunday, February 4, 2018 at 8:44:31 PM UTC+1, awokd wrote: > On Sun, February 4, 2018 5:23 pm, Yuraeitha wrote: > > > Another user in another Qubes 4 Win7 thread somewhere in Qubes-users > > mail-list, suggested to reduce the page-file for Windows SWAP inside the > > Windows VM. It worked for him, and when I tried it out, it worked for me > > too. It's possible this is what you encounter, try reduce the Windows > > page-file and see if it works? > > That was yours truly. I think it's more the act of setting the swap file > to a fixed size (of 1GB) that helped stabilize mine, but maybe you're > right and it's actually the size reduction. ohh, I apologize for forgetting your name at that time, back then most people were still strangers to me, and it takes a while for me to remember names. But I know I won't forget your name again now as I already remember it since a few topic discussions between back then and now ^.^ About the page-file size, I'm not sure either. I tried to restore a new Windows 7 backup again, and I tried giving the page-file 1.1GB as well as 2GB, to see if it would become unstable. It seems it was unstable on the first restart for the lower one (the one I started with), but after the second restart it became stable. This may also be due to the change of AppVM RAM which was 4GB before changing, and was given 2GB after changing the page-file. Which further complicates it. But after these two restarts, it was pretty smooth again, like the other Win7 I have tried it on before that. However, it once again became unstable during Windows updates + using the Search-files feature in Windows 7 start menu. Perhaps this instability is related to the drive's file-system (NTFS) of different and various sorts? It seems the page-file can remove the most frequent crashes by far, but a few others can cause it too, like searching the file-system while the system is busy with something else perhaps? I have a weak CPU on this laptop though, it's an Intel Core M-5Y10c @ 800Mhz. 8GB RAM. So I haven't used a strong system to test Win7 on. Although Windows 7 aside, everything in Qubes which is within normal-use runs more or less smoothly, and Windows 7 can run almost smoothly on this poor laptop. Although I'm not yet sure if running it on a stronger machine may make Win7 more smooth, or cause less crashes. Have you ever experienced crashes while running search files on disk from the Windows menu? If so, maybe we can turn off the search function to avoid any issues? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/82bff806-e3b7-4465-b1c0-a84e3251cd83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Are there currently anyone assigned to update Qubes-Windows-Tools?
@Ivan
On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> On 02/04/18 19:26, Yuraeitha wrote:
> > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> >>> Also it seems like some functions "might (maybe)" work as intended, for
> >>> example I can copy files between VM's and Win7, on a Win7 that was
> >>> installed on Qubes 3.2., but backup restored on Qubes 4. Others seem like
> >>> they can do this too. Also it seems it's a common problem not to be
> >>> internet in the restored Q3.2-Win7, perhaps the code is different in
> >>> regards to how it ties networking with Qubes 4? I have no idea about the
> >>> rest of the mechanics from a users perspective though, and most certainly
> >>> not as a developer as I unfortunately don't have such skills, I wish I
> >>> could help more.
> >>
> >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> >> few notes that might be helpful to work around some bugs that you're
> >> probably hitting too (I haven't filed any issues yet):
> >>
> >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> >> you're really in HVM mode.
> >>
> >> - Networking: the PV network adapter was stuck at "Identifying" ;
> >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> >> shows that the requests were sent to the gateway's ip and were rejected.
> >> The reason seems to be that in R4.0 VMs are now using the exposed
> >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> >> was the same as "/qubes-gateway" (see [1]). In my setup,
> >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> >> is 10.137.0.6. DNS requests are rejected because they're sent to
> >> 10.137.0.6 instead of 10.139.1.{1,2}
> >>
> >> workaround 1-> manually set the DNS servers to
> >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> >> for PC app complained about finding no network (it seems there's a
> >> windows "connectivity" API/flag that some apps use). However you will
> >> have to do this each time after boot since Qubes tools will reset the
> >> network settings.
> >>
> >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> >> messing with your network settings, and manually set the VM's IP and DNS
> >> servers in the PV adapter network setting. Everything should then work
> >> OK, the only problem being that you'll have to make sure you keep your
> >> network settings synced (esp. the IP when you clone the VM).
> >>
> >> - Copying to/from the Win VM: works perfectly - you just have to type
> >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> >> Qubes Tools aren't updated to reflect R4.0 new "way".
> >>
> >>
> >> note: before finding what was causing the connectivity problem I tried
> >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> >> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> >> Qubes Tool's drivers were at the same version as Xen's (8.2), so no need
> >> to fiddle with this.
> >>
> >> I was thinking about posting those steps on qubes-users@ but I don't
> >> feel I had done enough testing on my VM yet. I see you're quite active
> >> on qubes-users so feel free to redact/post some of my remarks if you
> >> think they'll help.
> >>
> >> [ an unofficial wiki would be a helpful bridge between the MLs and
> >> Qubes' official documentation: it's difficult to skim through all the
> >> related ML posts and IMO Qubes' official documentation shouldn't include
> >> crappy workaround hacks like the ones I've described above ].
> >>
> >>
> >> [1] https://www.qubes-os.org/doc/vm-interface/
> >> [2] https://www.xenproject.org/developers/teams/windows-pv-drivers.html
> >
> > @Evan
>
> Ivan :)
>
> > Thanks Evan! This really looks promising, I will go and try it out tomorrow
> > if I can scrap some free-time to try it out. I'll post here the moment I've
> > tried it, hopefully I can get the internet working.
>
> BTW I assumed there was a single "Qubes Tools" service responsible for
> setting the network, launching qubesdb daemon, ..., but I noticed a bit
> after my post that each task was handled by a different service. So you
> can simply disable the "Qubes Network Setup" service instead of renaming
> the .exe
>
> Also,
>
> https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c
>
> indeed shows that qubesGateway (/qubes-gateway) is used for DNS (line
> 287). The code is easy to understand and adding the new DNS variables, +
> setting the servers accordingly (if the variables aren't empty) should
> be straightforward. I don't have a Windows build environment to test any
> changes
