Bug 1227001 - Using DNF to with --installroot fails where yum works
Using DNF to with --installroot fails where yum works
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
: Reopened, Triaged
: 1229442 (view as bug list)
Depends On: 1163028
  Show dependency treegraph
Reported: 2015-06-01 11:58 EDT by Sam Tygier
Modified: 2016-10-04 15:14 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-21 11:04:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sam Tygier 2015-06-01 11:58:26 EDT
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:
 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
Comment 1 Radek Holy 2015-07-24 05:41:21 EDT
Thanks for the report. We'll take a look.
Comment 2 Radek Holy 2015-07-24 08:08:57 EDT
*** Bug 1229442 has been marked as a duplicate of this bug. ***
Comment 3 Phil Regier 2015-08-20 03:00:09 EDT
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).
Comment 4 Radek Holy 2015-08-20 06:21:00 EDT
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.
Comment 5 Phil Regier 2015-09-14 15:55:07 EDT
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!
Comment 6 Jaroslav Mracek 2016-01-14 04:08:00 EST
This bug will be fixed by pullrequest: https://github.com/rpm-software-management/dnf/pull/428
Comment 7 Mike McCune 2016-03-28 19:16:15 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 8 Fedora End Of Life 2016-07-19 10:26:55 EDT
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

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 9 Igor Gnatenko 2016-07-21 11:04:48 EDT
Fixed in upcoming DNF 2.0.

Note You need to log in before you can comment on or make changes to this bug.