Failed to update Fedora32

Hey!
I can not update my fedora32 template. Did not change anything, but it suddenly does not work.
Get the following errors:

Fedora 32 openh264 (From Cisco) - x86_64 0.0 B/s | 0 B 00:02
Errors during downloading metadata for repository ‘fedora-cisco-openh264’:

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.

Best regards
qun

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.

Hey, I can resolve them in any appVM, but I have no idea how can I resolve them in the templateVM.

How can I check the system proxy and what is it?
dnf.conf on the fedora32 template has proxy=http://127.0.0.1:8082/

Don’t really understand the proxy thing on qubes os.

It shows me the failed connection to the fedora-cisco-openh264 and fedora-modular, but i have no such mirrors in my fedora-updates.repo

so what’s that??

is it just because the Fedora 32 end the support??

So I’m installing Fedora 33 template now.

#Edit: still the same problems after changing the templateVM to the fedora 33

no problems with the standalone VM, so it seems to be the problem of the system. Anybody an idea?

nobody any idea??
I can not install anything on the templateVM

It seems to be a problem on dom0, because I install the new templateVM and still have the same problem

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?

Thanks for the answer!

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.

So your qubes.UpdatesProxy seems to look good. More questions:

  1. What is your sys-net based on? Is it a minimal template or the regular one?

  2. Run qvm-service sys-net in dom0. Is there a line that says qubes-updates-proxy on?

  1. sys-net is based on debian 10… i suppose the regular one.
  2. qvm-service sys-net just says: clocksync on

Run

qvm-service sys-net qubes-updates-proxy on

in dom0. Reboot sys-net and try updating again.

nope… no changes

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?

1 Like

ooook, thanks!
If i set the sys-net on fedora 33, so everything works well. The problem seem to be with the debian 10 template.

But i don’t want to set the sys-net on the same template as the rest of the system. Hmmm…

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!

1 Like