Template Update Errors (new thread for Fedora)

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.

how to disable the cacher-template?

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?

I have a template-cacher template yes, that’s correct. Are you referring to the config files located here:

/etc/qubes-rpc/policy/?

I also get a flood of error messages “qubes.UpdatesProxy denied” whenever I try to update other templates

edit /etc/qubes-rpc/policy/qubes.UpdatesProxy

Find the line starting with $type:TemplateVM and change the target=

change it to what? sys-net? I’ve tried that and it returns the same error

In =>4.1 you should delete qubes.UpdatesProxy and use /etc/qubes/policy/30-user.policy created and based on 90-default.policy

After each change you should run

systemctl restart qubesd

Never. To sys-firewall.

While the new format might be preferred, the old format has not been deprecated yet, and will not be until at least Qubes 5.0.

Source: Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS

The old policy format will still be supported until at least Qubes 5.0.

In fact, default Qubes salt formulas still use the old format.

1 Like

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 @.

I made the change as suggested…so far so good, one update completed successfully…

Kindly select which reply helped you solve your issue and mark it as answer, so this can be closed.

ok sure.

No, that can’t be the solution. This one could be.

No that was the solution. Why can’t it be the solution?

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.

I followed the instructions as given, updated, and then everything updated successfully.

1 Like

Good for you.

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.

Do you see how unhelpful this is?