Updating Qubes with whonix

Hi, is there any way of disabling updating software updates through Whonix? I am not sure if the repositories are blocking tor or what, but for awhile now I have been unable to update any software on qubes, either through the update tool or going through the linux command line. In the command line I keep getting 500 unable to connect errors whenever a repository is attempting to be fetched.

Q → Gear icon → Qubes Tools → Qubes Global Config → Updates tab → change “Dom0 update proxy” and “Default update proxy” settings.
Also make sure that you don’t have custom qubes.UpdatesProxy policies that override the policies defined in Qubes Global Config.

Many thanks for your response! I am still having problems locating it. The Q I assume is the one in the upper left hand corner of the screen. The only gear Icon I see in that menu is “System Tools” the 3rd item down, right below the Terminal emulator. There however is no “Qubes Tools” in that menu. However the is a “Qubes Tools” right below the gearbox “System Tools” but there is no “Qubes Global Config” there (nor in “System Tools”) There is a “Qubes Global Settings” however and I click in that and I get the Qubes OS 4.1 Global Settings Window. I don’t see an updates tab, or any tabs there. Only a section for “Updater checks” with 2 check boxes for dom0 and qube updates. There is a Qubes Update under the Qubes tools, but that is the typical updator box that I have had trouble updating. So I am still a little confused where to find the dom0 update proxy setting.

So you have Qubes OS 4.1?
Just to note, that Qubes OS 4.1 support ended a few months ago:

For Qubes OS 4.1 you can try to change the policy files manually.
Find the policy files with qubes.UpdatesProxy policy in dom0:

grep -r "qubes.UpdatesProxy" /etc/qubes/policy.d/

And edit the files.
You can also check the /etc/qubes-rpc/policy/qubes.UpdatesProxy file in case you have policies with old qrexec policy format.

1 Like

Thanks. I will see what I can do to manually edit those files. One of the reasons I have not upgraded to the new Qubes OS is because my updater is not working and files are not downloading due to the whonix issues, and I am not going to reinstall it from scratch as I have a ton of virtual machines I have custom set up for various purposes that I would have to do from scratch. The latter is not happening…

Do you have Whonix 16 template or Whonix 17 template?
If it’s Whonix 16 then try to install Whonix 17 template.
Also try to update Whonix Gateway template first and restart sys-whonix before trying to update other templates using sys-whonix.

Yes, I have tried to update the whonix templates and get the same errors I get when updating the other Oses that appear to be the torr ips being rejected on the other end:
“returned non-zero exit status 20”

"_error:
Failed to return clean data
retcode:
126
stderr:
Request refused
"

I am on Whonix16 now, but I will see if I can get the whonix template to install. However, I am guessing I might have some of the same troubles reaching the update servers for whonix17 because tor seems to be blocked.

Maybe it’s some issue with old Tor package in Whonix 16 template.
If you can’t connect to Tor itself in sys-whonix then maybe try to use a bridge.

Thanks. I tried modifying the policy files manually, commenting out the lines referencing whonix and rebooted. I also tried to change the network interface to sys-whonix to the normal default connection and that did not work either. I even deleted sys-whonix and every other whonix VM (it would not let me delete the two template VMs gw-16 and ws-16)…but there appears to be some other code blocking updates as I get an error Denied: qubes.UpdateProxy. I am starting to feel like this computer is doomed to never get updates again because this thing seems overlyinsistent of running it through tor which refuses to connect to updates.

You need to change sys-whonix to e.g. sys-net in the policy files, not to remove or comment out the policies.

Thanks. That makes sense. Although I just went in and uncommented out those lines and swapped out sys-net, but I am still getting that Denied: qubes.UpdateProxy error on an update attempt. Is there another setting that I might need to modify to allow updates to proceed through sys-net?

Enable qubes-updates-proxy service in sys-net Settings → Services tab.

Thanks! I just added the qubes-updays-proxy service in sys-net and qubes-update-check and updays-proxy-setup just in case. I rebooted, and tried updating again and got the same error.

Disable updates-proxy-setup service for sys-net, it’s conflicting with qubes-updates-proxy service.

Thanks once again for your help. I disabled qubes-updates-proxy service and rebooted, and still am getting the errors when I try to update.

You need to enable qubes-updates-proxy and disable updates-proxy-setup service for sys-net. Not enable both of them or disable both of them.

Thanks again. Actually I misspoke on the prior post. What you just described is what I did. I have qubes-updates-proxy enabled and i got rid of the other ones I enabled including updates-proxy-setup. Still getting Denied: qubes.VMRootShell error on updates after that change.

Maybe the same issue as here:

Try the fix from there.

Would a backup and restore not preserve these?

What if you have a hardware failure someday?

I suppose that might work. My only question resolves around what happens after the upgrade if I have backed up old VMs and templates. They will be based on older fedora versions etc. and when I restore them could that be an issue, or might there even be some incompatibilities with the new upgrade? If they will work seemlessly then that definitely works and could be a solution.