Created attachment 713251 [details] debug log Description of problem: I have an intranet Fedora repository that is rsync'ed daily. All intranet Fedora systems have yum repo.d files and pull updates from it. The default Fedora repos are disabled (enabled=0). I have also been able to use this system in the past with preupgrade just fine. With fedup, the tool downloads from Internet mirrors. I have even moved the default Fedora repo.d files out of the /etc/yum.repos.d folder, but fedup continued to use the Internet. Version-Release number of selected component (if applicable): fedup-0.7.3-1.fc17.noarch How reproducible: Always Steps to Reproduce: I've tried the following commands, but none of them do anything differently: # fedup-cli --network 18 --debuglog fedupdebug.log --disablerepo=fedora*,updates* # fedup-cli --network 18 --debuglog fedupdebug.log --disablerepo=fedora,updates,default-installrepo # fedup-cli --network 18 --debuglog fedupdebug.log --disablerepo=fedora,updates,default-installrepo --repourl pc1-fedora-updates1=ftp://miracle.foo.com/pub/fedora/updates/\$releasever/\$basearch/ --repourl pc1-fedora1=ftp://miracle.foo.com/pub/fedora/releases/\$releasever/Everything/\$basearch/os/ # fedup-cli --network 18 --debuglog fedupdebug.log --disablerepo fedora,updates,default-installrepo --addrepo pc1-fedora-updates1=ftp://miracle.foo.com/pub/fedora/updates/\$releasever/\$basearch/ --addrepo pc1-fedora1=ftp://miracle.foo.com/pub/fedora/releases/\$releasever/Everything/\$basearch/os/ Actual results: Download rates of ~100kB-500kB/sec. Internet bandwidth is limited to a 6MBit combined set of four T1s. Expected results: Download rates of >10MB/sec. Additional info: Thread on test list: http://lists.fedoraproject.org/pipermail/test/2013-January/113378.html I am attaching the debug log from the last several runs.
fedup needs to download two types of things: boot images and packages. For packages, you should be using the 'cost' setting to tell yum to prefer your repositories over others. See yum.conf(5): cost: relative cost of accessing this repository. Useful for weighing one repo's packages as greater/less than any other. defaults to 1000 To get boot images, fedup needs to find the repo that contains the .treeinfo file and all the boot images - releases/$releasever/Fedora/$basearch/os is the usual mirror path. This isn't part of set provided by the .repo files, so it has to be set up specially by fedup. If you have your own mirror of the 'Fedora' tree, you can use the --instrepo flag to tell fedup to fetch the boot images from your mirror. If you set 'cost=XXX' in your repo configs and use --instrepo to override the default instrepo, does fedup download everything from your intranet?
Fedup is not treating boot images and packages as separate repos. TEST 1 I added "cost=1001" to my intranet repo - even though Fedora's repos were already disabled (enabled=0) and "yum update" was already successfully pulling from my intranet repo without this setting. # fedup-cli --network 18 Fedup continued to pull from the Internet. I switched to "cost=999" just in case the documentation was wrong but fedup still pulled from the Internet. TEST 2 I added "--instrepo" and pointed to my intranet. # fedup-cli --network 18 --instrepo ftp://miracle.foo.com/pub/fedora/releases/\$releasever/Everything/\$basearch/os/ (I modified my Everything folder to include images/ and a correct .treeinfo) Fedup pulled from the intranet repo (both images and packages). So in conclusion: 1. Fedup ignores yum.repo.d files. I could have no files inside /etc/yum.repo.d and fedup continues to use its built-in repo. 2. The command-line options of "disablerepo", "repourl", and "addrepo" are useless. Fedup downloads their metadata, but ignores them at download time and uses its built-in repo (or --instrepo) anyway. Perhaps the command-line options should be cleaned up if this is expected behavior. Otherwise, having fedup separate the logic between image and package repos would fix this. Fedup can continue to use its builtin (or overridden with --instrepo) for images, and it needs to honor yum.repo.d files or the command-line options to add a repo.
It actually does honor yum.repo.d files. You can see this in the debug log: [ 6.598] (II) fedup.yum:setup_repos() repo default-installrepo seems OK [ 6.657] (II) fedup.yum:setup_repos() repo pc1 seems OK [ 7.017] (II) fedup.yum:setup_repos() repo pc1-fedora seems OK [ 7.143] (II) fedup.yum:setup_repos() repo pc1-fedora-updates seems OK Notice that the "fedora" and "updates" repos are not listed, because they aren't enabled. The reason you're seeing this behavior is the way yum and URLGrabber handle mirror selection. First: the install repo is special. It needs to be present for fedup to do anything, because the normal repos don't have boot images. (It also contains about 4100 of the most common RPMs.) Second: Given a choice of multiple repos that contain the same package, yum should use whichever one(s) have the *lowest* cost. Third: Once yum fetches something from a mirror, it prefers to keep using that mirror unless something goes wrong. So. When you run fedup, yum fetches the images from the install repo, and then tries to fetch packages. Since very likely all the packages it needs are available at the mirror it's already using, it continues to use instrepo rather than switching. The 'cost' argument is what changes that, but I'm not sure why yum doesn't seem to be honoring it in this case.
*** Bug 1046088 has been marked as a duplicate of this bug. ***
Does this bug include `exclude=...` from yum.conf?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.