Description of problem: I am trying to install a Scientific Linux chroot within a Fedora 22 host. Instructions do not work with dnf, but do with yum-deprecated. Version-Release number of selected component (if applicable): Host Fedora 22, guest Scientific Linux 6.6 Steps to Reproduce: Setup: mkdir -p /data/vm/chroot/sl6/var/lib/rpm rpm --root /data/vm/chroot/sl6 --initdb cd /data/vm/chroot wget http://linuxsoft.cern.ch/scientific/6.6/x86_64/os/Packages/sl-release-6.6-1.x86_64.rpm sudo rpm -ivh --nodeps --root /data/vm/chroot/sl6 sl-release-6.6-1.x86_64.rpm At this stage instructions say I should do: sudo yum --nogpg --installroot /data/vm/chroot/sl6 install yum If I replace this with: sudo dnf --nogpg --installroot /data/vm/chroot/sl6 install yum I get: Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-6.6&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink If I run: sudo yum-deprecated --nogpg--installroot /data/vm/chroot/sl6 install yum then the install works
Thanks for the report. We'll take a look.
*** Bug 1229442 has been marked as a duplicate of this bug. ***
I don't *think* this is quite the same bug, exactly, but I get a very similar message trying to install a Fedora 22 root: [root@localhost ~]# dnf --installroot=/lxcroot install vpnc Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink I get much better results if I give "--releasever=" explicitly: [root@localhost ~]# dnf --installroot=/lxcroot --releasever=22 install vpnc Fedora 22 - x86_64 758 kB/s | 41 MB 00:55 ... So it looks like the host mirrorlist is being used with the guest's releasever variable. If this is correct behavior, then would the problem be with the SL instructions? Either way, a careful selection of repos and --setopt arguments would enable a variety of workarounds for those currently getting this error from similar operations; unfortunately, I can't quite seem to figure out where the variable is coming from (one successful install appears to fix the problem so that --releasever is no longer necessary).
You've described the problem very well. *So far*, DNF takes the repositories from the host while the release version is taken from the guest [1]. You two demonstrate how it can be useful for one and annoying for another one. If you are preparing a chroot with the same system as the host, you probably like the fact that you don't need to manually configure the repositories in the chroot in advance (or run a "rpm -ivh --root /path foo-release.rpm"). On the other hand, if you are preparing a chroot with a different system, you don't want the host's repositories to be used there. YUM does some guessing based on what is already present in the chroot (YUM's configs etc.). It seems that DNF inherited just part of this behaviour. We are currently considering what would be the best (let's discuss it in the bug 1163028 if necessary). Phil, IMO, what you see is what YUM does as well. I cannot guarantee you that DNF will behave the same in the future but anyway, what was your expectation? [1] FYI, the release version is derived from special packages providing this information. Once you install something, such package is always pulled in as a dependency. That's why you don't need to set --releasever then. In case of SL, it's the sl-release package, for example. But let's don't remember this undocumented fact.
D'oh! Somehow I didn't get the CC; otherwise I would have noticed and acknowledged earlier that your explanation was very helpful, Radek. I didn't expect any particular behavior, except that I expected the sort of rigorous, documented consistency/predictability that I've come to treasure in proper RPM/yum/dnf-based distributions (Red Hat, CentOS, and Fedora first and foremost). Whatever data are used to determine the actions that rpm/yum/dnf will take, it would be nice if they were documented somewhere so that as related patterns continue to evolve, downstream documentation can evolve with it instead of bitrotting immediately. The point is of course not to manually tinker with the file in question, but to inform better workflows. If this behavior may yet be evolving then as far as I'm concerned your explanation here is sufficient interim documentation (Google brought me here, so hopefully others will find your explanations as helpful as I did) until the long-term intentions are ironed out. Bug 1163028, as you pointed out, also has useful information though I don't think I have anything valuable to add there at this point. Thanks, Radek!
This bug will be fixed by pullrequest: https://github.com/rpm-software-management/dnf/pull/428
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
Fixed in upcoming DNF 2.0.