Created attachment 1575359 [details] Terminal text from installation attempt Description of problem: On Workstation-Live: After opening a terminal window, the following command was tried initially (sudo dnf install -y gimp) and the failure first occurred. Then I switched to using (sudo dnf --repo=fedora --releasever=30 install -y gimp) to check if it was a repo problem and got the same failure. The failure only occurs with large packages like the main gimp package. the other smaller items load okay. It seems like DNF gets lazy and shuts off the stream. After the failure DNF switches mirrors, but the same failure happens. The failure will reoccur for all the repos that it tries. The load goes to about 30 to 50 percent and the shuts down. Version-Release number of selected component (if applicable): Rawhide (f31) drop 0529 and prior drops. DNF is at 4.2.5-1.f31 How reproducible: 100% Steps to Reproduce: 1. Open terminal 2. Issue command sudo dnf install -y gimp or sudo dnf --repo=fedora --releasever=30 install -y gimp 3. The install will fail through as many mirror switches as you care to wait for Actual results: Installation fails Expected results: Installation success Additional info: This was a bare metal install of Workstation Live with all disk space reclaimed on a Lenovo M58p with an E8400 processor. I have attached a file which is a copy of the terminal text from an installation attempt as described.
That looks like a mirror issue; the mirror you're getting dealt by mirrormanager is sending you data very slowly. If you adjust the repo config to point to a different, specific mirror (via baseurl) rather than using the mirror list, can you still reproduce?
I should note that I haven't had any problems like this with running updates and installs on other PCs here running F30 on the same network with no adjustments to the repo parameters. Are you saying this might be a problem with a local parameter in the Rawhide (F31) drop that has to do with mirrors? I would like to try this, but I need some help with how to make the change. I've never done this before. I need to know how I can identify the url for a repo and where to make the change.
Created attachment 1575839 [details] Terminal results of trial to gather more info
Created attachment 1575840 [details] Copy of edited fedora/repo file
I received the following suggestion for something to try to see if the problem is a mirror problem: "Edit /etc/yum.repos.d/fedora.repo (take a backup first just in case). In the [fedora] section, comment out the line that starts 'metalink' and uncomment the line that starts 'baseurl', and change the 'download.fedoraproject.org' in that line to 'dl.fedoraproject.org'. That should work for a quick test." After editing the fedora.repo file, I did a cat of the file to be sure the edits were as specified, and closed the terminal. I opened a new terminal and ran (sudo dnf install -y gimp). The failure persisted after the change. I have attached a copy of the edited fedora.repo file, and a text file showing the terminal results. Just for fun I did a restart of the system then opened a terminal and tried (sudo dnf install -y gimp) and got the same failing result.
Interesting. So either dnf is hitting this bailout condition wrongly (i.e. it *thinks* the transfer is really slow, but it actually *isn't*) or the transfer *really is slow* for some reason, but your other systems are apparently not affected. Can you tell whether the transfer of the file really is very very slow?
From watching the download rate in the download line provided by dnf and watching the network with system monitor, the transfer rate is running at full speed until it bails out. As another data point, I also tried running (sudo dnf upgrade --refresh). There were quit a few updates the small ones were able to load, but the larger one's bailed just like the install did. Some of the medium size ones were able to complete by getting incremental pieces of the package from from a couple of different mirrors.
I just compared the installed package versions for packages with "dnf" in their name. With one exception the packages installed on my test machine with Rawhide (f31) are the same as those installed on my F30 machines which do not exhibit this bug. The exception is that the F30 machines include dnf-yum and the F31 machine does not have dnf-yum. I then installed yum-dnf with (sudo dnf install -y dnf-yum) and did a restart on the machine. Then I opened a terminal window and ran (sudo dnf install -y gimp) and found that the bug is still present.
I just compared the versions of the Network Manager packages between by properly running F30 systems and the Rawhide (F31) test system. There are several packages that are at a newer version (1.20.0) in the Rawhide (F31) system. The F30 systems have the same packages at version 1.16.0. Might a component of the new Network Manager be the home of the bug?
It's possible, I guess? I can't really say, though, without looking at the details of how dnf is deciding when this rate cut-off has been hit. I'll try and take a look at that tomorrow.
Created attachment 1576682 [details] Journal taken with (journalctl -ae > dnfbugjournal.txt after failure I tried the (sudo dnf install -y gimp again and took the newly attached journal after the failure with journalctl -ae > dnfbugjournal.txt.
This is a strange issue, because we have the same code base in Fedora 30 and rawhide. Please could you check that following packages you have with same version in Fedora 30 and Rawhide? dnf, libdnf, librepo. Also the version of curl could be relevant. If the problem with network is temporal, please try to lover `minrate` (defaults is 1000), or increase timeout (default is 30 seconds) configuration option in /etc/dnf/dnf.conf. Could you also provide a feedback whatever the configuration changes help?
(In reply to Jaroslav Mracek from comment #12) > This is a strange issue, because we have the same code base in Fedora 30 and > rawhide. Please could you check that following packages you have with same > version in Fedora 30 and Rawhide? dnf, libdnf, librepo. Also the version of > curl could be relevant. > > If the problem with network is temporal, please try to lover `minrate` > (defaults is 1000), or increase timeout (default is 30 seconds) > configuration option in /etc/dnf/dnf.conf. > > Could you also provide a feedback whatever the configuration changes help? The versions are as follows: dnf 4.2.5-1.fc30 4.2.5-1.fc31 libdnf 0.31.0-3.fc30 0.31.0-3.fc31 librepo 1.10.2-2.fc30 1.10.2-2.fc31 curl 7.64.0-7.fc30 7.65.0-1.fc31 In regard to /etc/dnf/dnf.conf: In both the F30 system and the Rawh9ide F31 system, the dnf.conf files are the same and do not contain the parameters for 'minrate' or 'timeout'. The contents of both dnf.conf files are identical and are as follows: [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True
I have tried this on Rawhide (F31) 0624 drop and it doesn't seem to happen any more. I did several installs with a variety of sizes from a single small package to some with many packages including large packages. Of course the one mentioned in this report was in the group. Are there any additional things I should try?
I just checked the versions you asked about again and I see the libdnf is no longer installed and curl has been updated. In any case, DNF seems to be working for installs now.
In this case I believe that the issue was outside of dnf (other component). Also the issue is not reproducible anymore therefore I am closing it.