What I mean is this:
The updater hangs here (I left it running for 4+ hours).
Clicking on “Cancel updates” brings up another window:
How to reproduce: start the updater, select some templates, click on Update, disconnect the Ethernet cable (or disconnect the WiFi). Then re-connect the network 30s later.
I’ve been seeing this behavior a lot…and now you’ve explained it. I do have random dropouts in my network.
It’s frustrating to be in this situation: it’s hung but you can’t quit until it completes! I’ve often simply issued a kill -9 on the process. (IMHO there should be a “force” quit option.)
I have complained about it, but when I do, I read in response, probably because I couldn’t give any idea why it was happening, was: “don’t use the graphical updater.”
So thank you for finding something that hopefully someone can troubleshoot.
Oh wow. Now that’s a good solution. (sarcasm)
Do you use apt-cacher?
Do you face the same issue after reboot and reupdate?
I have also seen this issue and I thought it is related to my bad policy settings.
I’m not barto, but I do use the cacher.
Related issue:
https://github.com/QubesOS/qubes-issues/issues/8742
No, I do not use the cacher.
It’s a straight, simple setup, installed as R4.2.1 and constantly updated, now on R4.2.3.
Using sys-whonix as Dom0 & Whonix update qube, and plain sys-firewall as the update qube for the rest.
Yes, absolutely! I missed this, probably because it’s a release candidate bug.
Four months on, and the updater still hangs on the slightest network glitch 
Using R4.2 up-to-date.
