Cannot update (Reading from proxy failed)

User Support
1

I tried updating the salt way (sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm) as well as the GUI way, with approximately the same results, which are attached (ignore the Whonix error, that is transient and I was able to update Whonix using the GUI).

Here is what it looks like trying to update apt sources in debian-11 template (which should be unmodified):

apt update_2022-10-05_16-07-40
apt update_2022-10-05_16-07-40742×487 96.7 KB

(note the simultaneous GUI messages about qubes.UpdatesProxy)

Because of these, I updated my /etc/qubes-rpc/policy/qubes.UpdatesProxy to the following:

$tag:whonix-updatevm $default allow,target=sysWhonix
$tag:whonix-updatevm $anyvm deny
$type:Template $default allow,target=sysNet

don’t worry about the different names I have chosen, those are essentially the same as the snake-case version that comes with Qubes, but I have the convention for my system that any name with a - in it is a template.

Anyways, I’m still getting the errors updating debian or fedora, so please advise if I’m missing a troubleshooting step or if I looked at the wrong proxy settings.

2

I believe it is now recommended to use the new qrexec policy format in the /etc/qubes/policy.d/ directory - see the README file it contains.

However, using the /etc/qubes-rpc/policy/qubes.UpdatesProxy file will still work but the $type: value should be TemplateVM (not Template) so the whole line for templates should be:

$type:TemplateVM $default allow,target=sysNet

3

You should use /etc/qubes/policy.d/30-user.policy created by exploring 90-default.plocy.

Also, I wouldn’t use sys-net as updateVM, but at worst sys-fitewall.

4

Thanks, that was an oversight using sysNet.
https://github.com/QubesOS/qubes-core-qrexec/blob/master/Documentation/multifile-policy.markdown gives a 404.

  1. Does the old way override the new way (policy.d)? The new way doesn’t seem to work based on the fact that I have this line in 30-user.policy that is getting ignored:
    qubes.UpdatesProxy * bwsync @default allow target=sysFire
  2. Should I delete the old file?
  3. What does DESTVM mean in either system?
  4. Is it irrelevant for proxies and only used for other policies?
5

Another question is why didn’t this work out of the box (or if it did, what broke it)? I just recently did a fresh install of Qubes 4.1, and then restored some qubes from backup, but that shouldn’t goof this up, right?

6

Without not knowing whole both files it would be hard for me to tell exactly.

7

I have deleted it and it it seems to work for me.

8

Well since you said I could delete qubes.UpdatesProxy, I did, so the only file left is /etc/qubes/policy.d/30-user.policy (6.1 KB)
Note that even after full reboot this policy doesn’t seem to do anything different.

So neither the old way or the new works, surely there has to be some way to update my qubes!! @AndyZ, do you know how to update in 4.1?

9

Your 30-user.policy file looks ok so what I would do next is…

  1. Assuming your Whonix updates are working, in 30-user.policy, temporarily change sysFire to sysWhonix just to confirm the update url’s are reachable.
  2. Launch a browser and confirm internet can be reached through sysFire
  3. Check Services tab in the settings for sysFire: Is the qubes-updates-proxy service listed and ticked? - If not, select it from the drop down, add and tick it or choose “(custom…)” (from the drop down), click “Add”, type in the name of the service qubes-updates-proxy, and click “OK”.
  4. Restart all relevant qubes and try the update again.
10

That fixed it, thanks!