Fedora 33: intermittent network issue with RPMFusion and COPR repositories

Resolving make me think to a DNS issue? But it is only a guess.
It’s weird that neither mirror is working.

Try for instance
resolvectl -4 query repo.fedora.md
What happens?

This is a different problem.


Here’s the info:

resolvectl -4 query repo.fedora.md
repo.fedora.md: – link: enp34s0

– Information acquired via protocol DNS in 728us.
– Data is authenticated: no

But each message lets think that there is a network issue.
Network isn’t strictly related to the ISP or to the destination mirror. The issue could be everywhere.
When dnf is stuck waiting for timeouts, are you able to resolve names? To ping the copr website? To reach any of the mentioned links?

1 Like

Yes, I can reach the links through a web program. The odd thing is, sometimes it works (the dnf not waiting for response) and sometimes not.

Now, I get this messsage:

RPM Fusion for Fedora 33 - Free 680 kB/s | 897 kB 00:01
RPM Fusion for Fedora 33 - Nonfree - NVIDIA Dri 14 kB/s | 8.3 kB 00:00
RPM Fusion for Fedora 33 - Nonfree - Steam 6.8 kB/s | 1.7 kB 00:00
RPM Fusion for Fedora 33 - Nonfree - Updates 4.5 kB/s | 1.2 kB 00:00
RPM Fusion for Fedora 33 - Nonfree 270 B/s | 278 kB 17:35
Dependencies resolved.’

Maybe it has been fixed?

Edit: Nevermind. I’m back to square one… Is fedora supposed to always check through RPM fusion repo’s and updates when trying to search for an application using dnf search?

Not really, see:

1 Like

Generally, yes. DNF does a quick check to see if the metadata it has cached is up to date. You can run transactions with particular repositories disabled by using the --disablerepo=.. options. See man dnf for more.

1 Like

I mean. The network is not only the cable. Look at the network layers, from level 1 to level 7 of the ISO/OSI model. As said before, it could be the resolver, the DNS, the ISP, the cable, the router, the mirrors, whatever.

If you see this:

it is network related, what else?

1 Like

I’m seeing a lot of the same issues as the OP. For me it seems to be a DNS issue. Simplest example is that I can ping google dot com but I can’t ping winehq dot org. But, from a VM on the same machine, I can ping winehq dot org just fine.

btw when I say “can’t ping”, I mean I type the ping command and hit enter and it just sits there with absolutely no output!


[pe@dn:~]$ resolvectl -4 query winehq.org
winehq.org: – link: wlp111s0

– Information acquired via protocol DNS in 61.8ms.
– Data is authenticated: no

Mine is also a new install of F33. I was not having this issue with F32 or any other distro currenly.

Glad to help debug if I can do anything.

If it were a DNS problem, the ping command would exit with an host unknown error. If the ping command sits there without any output it looks like the address resolution was successful, but that packets are dropped. Please take into account that many servers around the internet, even if they are working, they drop ping requests. So the ping command is not always useful to diagnose the problems.


interestingly, if I let ping (or dnf when it is stuck, or gnome-software when it is stuck) sit there for 30 min or so, they begin to work correctly.

If I force my wifi interface DNS setting to Then ping and dnf and gnome-software start working perfectly!!! But if I let DNS be automatic with nothing filled in, it gets my home router as the DNS server and all those services become intermittent for some servers.

Using Settings->Wifi then settings gear for my interface, then ipv4 tab

Most likely it uses your ISP DNS as an upstream resolver by default.
In some cases local ISP resolvers are known to be unreliable.
So, you’d best replace it with a major public DNS provider.

1 Like