I was experimenting with Fedora recently and saw that one a lot. And one perfectly ordinary package would simply fail to install after it checked (and listed) all of the mirrors and failed to find it. (Other packages work fine.)
I was using a cacher (sys-cacher). If I shut it off that one package would install, but I’d still get the complaint you describe.
Anyhow, I’m just grasping at straws here, but if you are using a cacher, try disabling it.
That depends greatly on which one you’re using! The one I use has a policy entry in dom0 AND also has some edits in certain config files in the template that is trying to do the update (not the cacher, but instead the one(s) you’re having trouble updationg).
First things first, you are using one, for certain?
Yes, thanks. That’s why I wrote “He should” instead of “He has to”.
Beside other reasons to already switch to new file and format, this should be kept on mind, from the link you posted above:
Due to a potential issue described in Qubes Security Bulletin #38, we have been getting rid of $…
However, we highly recommend using only @.
Ok, how exactly that post helped you to resolve your issue? @BEBF738VD just explained in it that you can still use qubes.UpdatesProxy, but how to use it he explained in his post I quoted? Now I’m confused how you resolved your issue actually.
Since you did not identify the root cause of the issue this is almost
useless, and of little help to other users.
You did not say, (and no one asked), what qube you were using to update.
You could get this information from /etc/qubes/policy/30-user.policy,
/etc/qubes/policy/90-default.policy, and /etc/qubes-rpc/policy/qubes.UpdatesProxy
You did say that you had a template-cacher
You did not say if you had a cacher qube.
The error message you reported is inconsistent with use of cacher,
since it references https access to the repositories.
As explained in the “info” for cacher, it cannot use https access, and
has to rewrite this to http://HTTPS/// - this is because https access
means that the traffic is encrypted when it reaches the caching proxy
and so cannot be dealt with.
If you were using cacher, then you would have seen a different error
message, relating to use of https repositories.
If you were using cacher, then (since other templates seemingly worked fine),
when you changed the update proxy those other templates would have
stopped working. This is because they would have repo definitions that
used http://HTTPS/// and other proxies would not know what to do with that*.
To summarise:
We don’t know what proxy you were using.
We don’t know what templates you were able to update.
We don’t know what caused the problem.
The problem was resolved by changing the update proxy to either sys-net or
sys-firewall, but we don’t know which, or what template that qube
used.