[R3-RC1] Windows update broken on a fresh Windows installation

[Vít Šesták]

I've installed a fresh Windows 7 Home Premium x64 SP1 on my HVM, but I can't perform Windows update. When I try to check for updates, it is “Checking for updates…” forever. This happens on a very fresh install with no 3rd party software installed.

I was also able to reproduce that with Windows 7 IE 11 VM downloaded from http://dev.modern.ie/tools/vms/ , which behaves the same.

I'd like to ask if this can be a trouble related to Qubes. I've unsuccessfully tried to fix that with MS Support and I was told that it seems like environment (virtualization-related) issue rather than a Windows-related issue (after several hours of attempting to fix that). I am not sure where the issue might be. Can it be something network related? I hope that Windows should have reported some timeout or something similar instead of hanging forever. However, 1. this was denied by MS support and 2. this is the only related thing that I am aware that might be influenced by Qubes.

I've used my laptop OEM product key (which is legally OK in this case, even for a VM). So I have used no cracks or something like that. I've also verified the SHA1 sum of “Windows 7 Home Premium with Service Pack 1 (x64) - DVD (English)” at https://msdn.microsoft.com/en-us/subscriptions/downloads/hh442898.aspx#searchTerm=windows%207%20home%20premium%20service%20pack&ProductFamilyId=0&Languages=en&Architectures=x64&PageSize=10&PageIndex=0&FileId=0 and it matches, so I must have downloaded the correct version. (I simply don't believe that there was so sophisticated targeted attack on me related to HTTPS (e.g. CA-related attack) or SHA1 (i.e. collision related attack, which is very far from being easy today) or directly to Microsoft. And even if there was, disabling updates this way does not sound plausibly at such sophisticated attacks.)

Do you have similar issues? Do you have any idea where the problem is or how can I fix that?

Regards,
Vít Šesták 'v6ak'

[Vít Šesták]

One interesting observation: It seems that manual checking for updates is broken, but when I enable fully automatic updates, they work. Which is very very very crazy.

This seems to reject any network issues hypothesis. In this case, I've however no idea where the issue might be. If it was a Windows-related issue happening on a fresh Windows install for many users, I hope that Microsoft would be aware of that.

Reagrds,
Vít Šesták 'v6ak'

[Jake]

On 06/20/2015 08:14 AM, Vít Šesták wrote:

One interesting observation: It seems that manual checking for updates is broken, but when I enable fully automatic updates, they work. Which is very very very crazy.

This seems to reject any network issues hypothesis. In this case, I've however no idea where the issue might be. If it was a Windows-related issue happening on a fresh Windows install for many users, I hope that Microsoft would be aware of that.

i'm using R2 and i am having a similar problem to vit here - have installed a win7 x64 vm from a valid windows install disk, but it will not update, even when i turn on automatic updates. this has made the vm essentially useless since i need updates to test some windows software that is being developed.

windows will not update, even after a fresh reinstall and before installing qubes windows tools. when i attempt to check for updates, the vm just spins indefinitely (no errors afaict) and eats ~25% cpu.

does anyone have a workaround to make win7 x64 updates work?

regards,
jake

Reagrds,
Vít Šesták 'v6ak'

On Saturday, June 20, 2015 at 10:00:13 AM UTC+2, Vít Šesták wrote:

I've installed a fresh Windows 7 Home Premium x64 SP1 on my HVM, but I can't perform Windows update. When I try to check for updates, it is “Checking for updates…” forever. This happens on a very fresh install with no 3rd party software installed.

I was also able to reproduce that with Windows 7 IE 11 VM downloaded from http://dev.modern.ie/tools/vms/ , which behaves the same.

I'd like to ask if this can be a trouble related to Qubes. I've unsuccessfully tried to fix that with MS Support and I was told that it seems like environment (virtualization-related) issue rather than a Windows-related issue (after several hours of attempting to fix that). I am not sure where the issue might be. Can it be something network related? I hope that Windows should have reported some timeout or something similar instead of hanging forever. However, 1. this was denied by MS support and 2. this is the only related thing that I am aware that might be influenced by Qubes.

I've used my laptop OEM product key (which is legally OK in this case, even for a VM). So I have used no cracks or something like that. I've also verified the SHA1 sum of “Windows 7 Home Premium with Service Pack 1 (x64) - DVD (English)” at https://msdn.microsoft.com/en-us/subscriptions/downloads/hh442898.aspx#searchTerm=windows%207%20home%20premium%20service%20pack&ProductFamilyId=0&Languages=en&Architectures=x64&PageSize=10&PageIndex=0&FileId=0 and it matches, so I must have downloaded the correct version. (I simply don't believe that there was so sophisticated targeted attack on me related to HTTPS (e.g. CA-related attack) or SHA1 (i.e. collision related attack, which is very far from being easy today) or directly to Microsoft. And even if there was, disabling updates this way does not sound plausibly at such sophisticated attacks.)

Do you have similar issues? Do you have any idea where the problem is or how can I fix that?

Regards,
Vít Šesták 'v6ak'

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/38870151-3e16-4ff4-82ad-3c81b44daebe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vít Šesták]

The only workaround I know is enabling automatic updates. Not nice, but it somehow works.

Regards,
Vít Šesták 'v6ak'

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Sep 30, 2015 at 12:59:23PM +0000, Jake wrote:
> On 06/20/2015 08:14 AM, Vít Šesták wrote:
> >One interesting observation: It seems that manual checking for updates is
> >broken, but when I enable fully automatic updates, they work. Which is
> >very very very crazy.
> >
> >This seems to reject any network issues hypothesis. In this case, I've
> >however no idea where the issue might be. If it was a Windows-related
> >issue happening on a fresh Windows install for many users, I hope that
> >Microsoft would be aware of that.
> >
>
> i'm using R2 and i am having a similar problem to vit here - have installed
> a win7 x64 vm from a valid windows install disk, but it will not update,
> even when i turn on automatic updates. this has made the vm essentially
> useless since i need updates to test some windows software that is being
> developed.
>
> windows will not update, even after a fresh reinstall and before installing
> qubes windows tools. when i attempt to check for updates, the vm just spins
> indefinitely (no errors afaict) and eats ~25% cpu.
>
> does anyone have a workaround to make win7 x64 updates work?

What version of qubes-core-vm package do you have? Versions >=3.0.13
contains workaround for similar problem:
https://github.com/qubesos/qubes-core-agent-linux/commit/4e4400

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWDDyWAAoJENuP0xzK19csQ18H/36vfLWeNKgY0bAa1piN+bU0
zElVaXMF3EYxkIH4nnN3TOcZsPqJis5VAtSiXG+Dh6yRSpr9FtwnRdZ9ovIseuQw
Nff2RUqANeKzjAUhgrc/DfpC1981jLf/aZln5gWstW5eCJ9sy79MAKXWNiKn6DMn
eyVnIu6BiyeiDOEEMr1x4kT7nTxydKvnWyeyP87ygIx+zyjuHYXXRZfLElfqvVtg
1o67bYSLO5u5U3CaRoZp1lGLLLxI2wxC7LnNOMgNODMIIOysEMo9F3635sFjYzPi
GO0oJY8dSb+stWEPBY212QfdE8/X3qvCXTR61PaowifM6RWDlTv7RqFtVdKvw90=
=zh3A
-----END PGP SIGNATURE-----

[Vít Šesták]

I am confused about it. Does qubes-core-agent-linux run in dom0? (The name does not suggest so, but your answer would not make sense if it didn't.) If so, what package name does it have? If it is qubes-core-dom0 (3.0.22-1) or qubes-core-dom0-linux (3.0.15-1), then it is in version ≥ 3.0.13.

Regards,
Vít Šesták 'v6ak'

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Oct 01, 2015 at 12:39:58PM -0700, Vít Šesták wrote:
> I am confused about it. Does qubes-core-agent-linux run in dom0? (The name
> does not suggest so, but your answer would not make sense if it didn't.) If
> so, what package name does it have? If it is qubes-core-dom0 (3.0.22-1) or
> qubes-core-dom0-linux (3.0.15-1), then it is in version ≥ 3.0.13.

No I was right - its about qubes-core-vm package, which runs in the VM.
This is where network from (H)VM is connected :) More specifically:
netvm/firewallvm.

PS Could you stop top-posting? ...

iQEcBAEBCAAGBQJWDZDuAAoJENuP0xzK19csre8H/RzxLrM2pg3rFA4Ex8nAKZxl
R308eaeCnYGNx1C0GFhkvNezP0YyRTWP7F0uWqp56JxSAf4s9sPhFg8DV/NW5aNJ
BXuZ8OzdH1EbNa/3Jp+qZBY77oHXE8SqpDWdtOZQY8cJyh5Dcs1Cf5qDOTr+8yNb
2cIJuLtcJ3zkQcStByniYAs3iIIKQf5wWJtA9yP2rDCbIpw8s3TRbr7rYg03lbMW
vkglMyQynZyjrk3y+8mOf9Oe6gLQj3ET5+cknkFLlRYLOZyU214FftoRW5rEa9MO
WnkgNDuXcleu9+fCXymooLJjpaMtZ/RMkNiqR/CENLyPsusnaixF6tDoQ13+67k=
=VeIF
-----END PGP SIGNATURE-----

[Vít Šesták]

No I was right - its about qubes-core-vm package, which runs in the VM.
This is where network from (H)VM is connected :) More specifically:
netvm/firewallvm.

Aha, got in. In both cases (sys-net and sys-firewall), it is in version 3.0.16-1.
 

PS Could you stop top-posting? ...

I usually use either inline replies (if reasonable) or top-posting. Provided that one knows the context of the thread (e,g, it is a fresh thread), the quoted message is some less important information (and it probably could be even missing). The good of top-posting is that the quoted text (i.e. the text that is likely not read) is easy to skip. And when one wants to see the history (maybe the use case for somebody who just arrived), thread view seems to be the best tool for that.

[Vít Šesták]

After a clean install of Windows 7 Home Premium with SP1 and some updates, I've found something interesting. I've downloaded some DVD with various updates (*.msu) for Windows, see https://support.microsoft.com/en-us/kb/913086 . I tried installing those updated manually. However, I sometimes got stuck at “Searching for updates on this computer…” (see the attachment). Restart usually solves the problem. So, I had to restart the VM after installing 1-3 updates.

And there is the interesting thing: As far as I know, this might be related to the Windows update checks issues. This however apparently is not related to network, as there should be no networking needed for this.

But… where the problem might be?

* Disk emulation – I doubt that such problem would not occur anywhere else.
* Human I/O – unlikely
* Xen HVM technology itself (?)

Regards,
Vít Šesták 'v6ak'

[Tim W]

I am having similar issues.   Another note to this issue is that I find on my install win 7 pro the network connection map gui shows stuck no being able to access internet yet it is access the net find and can use browsers ping dns res.  I think this might also be tied into this issue.  There must be a certain sevice or protocol that is not passing out of the fw or net vms.  

The issue you speak of with having to do mutl restarts could be the way applies updates and not being able to reboot auto or to hold the booting process at a certain point.  Not sure on it though.  I have not yet had that problem but I have only installed a single update as sp1 was part of the os iso.

Doing updates manually is a bit of a PITA especially at first as they do not make it easy to figure out the updates that are needed.

But other than that so far the window pro 7 with windws tools seems to be working smoothly.   I have it built as a template but have yet to create any appvms off it.  I wanted to get it fully updated first.  

I have to say after using qubes for so long I find the seamless mode very comfortable vs using the win desktop.

[Tim W]

FYI I used the windows tools from the testing repo incase that matters and its 3.1 fully updated.

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not 100% sure what may be causing it but I've seen Windows Update
take hours (!) on a VM even without Qubes Tools. I think that
particular VM was a fresh install without SP1, so it needed a lot of
updates. It did update finally but definitely shouldn't take *that* long
.
- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJWsymIAAoJEIWi9rB2GrW74RkH/3NCUIGaKPUVR7s+Se5+alRV
RNLxV2LiDB59Ma8XqPAy7hIJlR03dg+r41QV50WSt4ZRX9s4JbsCpogBdsoFdRsG
BcJUPLjsVIUZSwuhP27UgU2PhcZQN3Orjwc4+1hDsGvnF5Af5+Cs1I/izojU5Kqh
h6rt0tHZklVpGTCEsN2t1p3KTjHx4mXeKuDT0EX0mzCBLG3dnRDW3MSn6c/7v+Hx
5tjY4S+EBfSsKj6ucgUcU5pt4uyUNFzrL2einqXpbztJ4T8GhmhrWJigfJCLoTeD
1k14UKIgZs/lzzeuWQbH+RRPIMit5a6H74Q7J6wl7Pg5wsdxMZT0GcY76bGcY78=
=TlUm
-----END PGP SIGNATURE-----

[raah...@gmail.com]

yes this happens, ever since windows 10 came out, even on a normal windows 7 fully updated system. I sometimes have to wait at least an hour. Maybe it has something to do with them wanting you to automatically install win 10? dunno lol. But it indeed can be frustrating. Eventually it finds the updates.