Fedora 33: intermittent network issue with RPMFusion and COPR repositories

Did you just term the 99.95 Mbps speed to be not good enough?

*Anger intensifies

Haha, indeed I did! Okay okay, it is pretty good.

Here’s what’s happening, according to the terminal:

Copr repo for PyCharm owned by phracek 0.0 B/s | 0 B 07:27
Errors during downloading metadata for repository ‘phracek-PyCharm’:

How do I solve this?

1 Like

Well, the COPR is certainly there and alive and there hasn’t been any announcement about COPR having infra/network issues, so it’s something to do with your setup:

Anyone else seeing a slow responses from COPR?

Well, due to COPR, my Software Catalog also gets slow… But that’s about it. After COPR update times out, the command that I would be running would be working without any problems.

For the time being, just disable these repositories.

We need to be slightly pedantic here to be able to diagnose the issue: it’s not “because of COPR”. It’s because for some reason, your connectivity to COPR (as was for RPMFusion which magically fixed itself) is poor. Now we need to diagnose why this is. It could be anything from a slow DNS resolver or server to an issue with your ISP, or another slow mirror (although I’m not sure if COPR uses mirrors).

I can’t think of a way to diagnose this off the top of my head—will have to think about it a bit. Others, any ideas?

Also, to confirm: your system isn’t laggy in general usage, right? It’s only this particular issue? It’d help to update to topic title to make it more specific. A generally laggy system implies performance degradation—which we’re not seeing here.

I don’t know about the ISP being the problem. How come this never occured when I used another Linux distribution?

No, there is not general lag. The terminal only seems to stay stuck when updating RPM Fusion (Yep, happened again) and COPR

I have tried reinstalling the system, to no avail. What seems to be the problem? I have never suffered this from other distro’s, or even Windows for that matter.

Not sure yet tbh. The other distributions use different mirrors, infrastructure/IPs for example, so that’s already quite a difference.

OK. So to be specific, the issue is that interaction with certain repositories, RPMFusion/COPR, is slow on your configuration.

Let’s also note this here: it isn’t the terminal hanging, that’s DNF waiting for the repository data. You can open another terminal tab or window to use the terminal if you need to.

OK, you need to slow down and try to understand what is causing the problem. A reinstall only helps if there was something wrong with your installation, and there’s no evidence to suggest so. If it’s a networking related issue, reinstalling will not magically fix it.

1 Like

At first I did think something was wrong with my installation due to not being able to boot into my USB the first time, resulting in a blank black screen.

And what I mean by terminal getting stuck is that dnf is waiting for RPM Fusion data, like you suggested, not that it is actually stuck and I have to terminate the process. This also causes Software catalog to go into almost an endless loop.

It seems to me that Fedora is not usable, atleast in my case. The best option may be to switch to a more, functioning distribution, as there isn’t any reasonable cause to this, unless you have something in mind.

This is geting incredibly frustrating, again. I can’t even install anything due to dnf waiting for RPM fusion…

Fedora 33 openh264 (From Cisco) - x86_64 1.6 kB/s | 2.5 kB 00:01
Fedora Modular 33 - x86_64 4.8 MB/s | 3.3 MB 00:00
Fedora Modular 33 - x86_64 - Updates 1.5 MB/s | 785 kB 00:00
Fedora 33 - x86_64 - Updates 39 kB/s | 9.3 MB 04:06
Fedora 33 - x86_64 8.7 MB/s | 72 MB 00:08
google-chrome 49 kB/s | 3.6 kB 00:00
RPM Fusion for Fedora 33 - Free - Updates 97 kB/s | 43 kB 00:00
RPM Fusion for Fedora 33 - Free 1.1 MB/s | 897 kB 00:00
RPM Fusion for Fedora 33 - Nonfree - NVIDIA Dri 7.5 kB/s | 8.3 kB 00:01
RPM Fusion for Fedora 33 - Nonfree - Steam 7.3 B/s | 1.7 kB 04:05
RPM Fusion for Fedora 33 - Nonfree - Updates 810 B/s | 1.2 kB 00:01
RPM Fusion for Fedor100% [====================] 9.0 B/s | 70 kB 00:00 ETA
Errors during downloading metadata for repository ‘rpmfusion-nonfree’:

This is how it looks like after a few minutes of doing a dnf install command…

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.

2 Likes

Here’s the info:

resolvectl -4 query repo.fedora.md
repo.fedora.md: 178.168.120.183 – 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!

and:

[pe@dn:~]$ resolvectl -4 query winehq.org
winehq.org: 4.4.81.124 – 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.

2 Likes

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