Tried to clean cache, but it seems to be a problem with the repo.
Found some solutions in the net, but don’t really understand them and before I change something… I ask here.
Hey, just my quick opinion.
Try to resolve all these addresses first.
If you can’t, then you know where the problem is, DNS.
If you didn’t make any change to the repolist, then the problem is hightly on the repos.
Try to check your system proxy config, it seems that some proxy blocked the connection.
I think that you can specify also a proxy in the dnf config, check there as well, normally, you don’t want to use a proxy for upgrades.
Let’s try to debug the problem step by step. First questions: what is in /etc/qubes-rpc/policy/qubes.UpdatesProxy? Did you ever modify it? Are you comfortable sharing it? (Feel free to send it just to me.)
There should be something like this there:
# Default rule for all TemplateVMs - direct the connection to sys-net $type:TemplateVM $default allow,target=sys-net
This basically says that sys-net should act as the proxy vm for updates. Do you have sys-net?
I did not modify anything. So maby the system modifies something after dom0 update, but I’m wondering why it modifies so, that I can not connect to the updates on the templateVM.
Contents of file /etc/qubes-rpc/policy/qubes.UpdatesProxy:
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
Don’t know, why it formats the text that way.
There is the sys-net and it works well for all app-Vms or for the standalones.
If you rebooted sys-net, then I have no idea what to do. (Also make sure you correctly spelled qubes-updates-proxy.) Did you try swiching back to the Fedora template?
I cloned the fedora 33 template, deleted some unnecessary apps and just have now an extra fedora 33 template for the sys-net and sys-firewall. Have no idea, why debian 10 template got the problem.
I can not even start it (debian 10 template) now: “can not connect to qrexec agent”… strange. If i start it with “update now”, it starts, but can not load any app.
Stick to Debian for sys-net, but create another networked qube that is based on Fedora. Then make sure it has the qubes-updates-proxy setting on and update /etc/qubes-rpc/policy/qubes.UpdatesProxy in dom0 accordingly.
I think the solution without debian, but with copied fedora for the sys-net is better. I think fedora is a little bit more secure. So no need to use debian at all or maby just for some special appVMs.
@qun if this is solved feel free to mark the post that solved it as the “solution”. You can do so by clicking the … on the bottom right of the reply in question. If no single post does this, you’re welcome to write a summary of the solution as a new post and mark that one as the solution.
So the problem was somewhere in the debian 10 template. After changing the sys-net to fedora 33 template the issue was gone. Thanks to @427F11FD0FAA4B080123 for the help!