@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, thanks!
> >
>
> OK :)
Sorry for the delay, I had planned to test and report back here sooner.
I followed your guide and I managed to restore networking/internet to Windows 7
in Qubes 4 by doing what you recommended. Thanks for sharing this! :-)
- I'll try some more user-testing and report back here, including how I tested
it, but I might not get it done until after a few days after the 15th February,
as I have an upcoming long-time upcoming large exam on that date which is
feeling to me like ripping teeth out + regular work at same time, so I will be
a bit disconnected to say the least. The kind of Win7 user-testing I was
thinking about is straight forward but a bit time consuming though, restoring a
couple of Windows 7 backup VM's, and try the different approaches and see if it
goes the same way. I'm in particular unsure about the windows job services
disabling feature, but on the other hand the re-name of the service .exe file
seems like it'll stick.
- I think it's great if you post your guide for others to see :) You can always
leave a disclaimer, such as no code has not been audited in this particular
case, however that it worked for a few of users who tried it (it worked for me
on my first try, more to come though). If people have all available
information, including the disclaimer, then they can make calls for themselves,
so that responsibility is not put on you if something should go wrong.
- Regarding the copy to and from Win7, I think you're right, it's probably
safe, at least mostly. I have to shake off that paranoia feeling I have about
bit-rot though, it keeps dragging back my doubt. It's probably after years of
taking measures against possible but remote risk of bit-rot disasters, that
this thought keeps nagging at me like a haunting ghost from the shadows. I
don't trust many file-transfer mechanisms to begin with, so I think it may
affect my judgment here, I tend to question even the best file-transfer
programs and mechanisms. Which is a bit problematic if I can't read much code,
and few people dare to stick their neck out and say file-systems or
file-transfer mechanisms are safe, which is also understandable. It's fair
enough not wanting to give reassurances on these issues, it's a hard place to
make anything that is really reliable given the best technology currently
available, and some people can get really aggressive if something goes wrong,
unfortunately. But for that reason too makes it really hard to find an
objective truth on these kind of systems. It does leave one with food for
thought, or dare I say food for worries. Maybe the best to do here is to run a
hash check on before/after transfer on the Win7 files deemed too important, but
outside important files not to worry too much? A bit of both?
--
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/9c98d308-aa34-4731-a348-731e12e0d845%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
