Bug 1645638 - Local installation with dnf is unable to find /bin
Summary: Local installation with dnf is unable to find /bin
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-02 17:16 UTC by Sage Russell
Modified: 2018-11-05 16:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-05 16:33:49 UTC
Type: Bug


Attachments (Terms of Use)
debugdata (8.29 MB, application/x-tar)
2018-11-05 13:43 UTC, Sage Russell
no flags Details

Description Sage Russell 2018-11-02 17:16:21 UTC
Description of problem:
Local Install of DNF is unable to find /bin/mv and other executables in /bin, however, the package is able to install normally using rpm.

Version-Release number of selected component (if applicable):


How reproducible: Consistently with local installs. Example is with Splunk, however is not specific to Splunk (it was just a recent package I was trying to install)


Steps to Reproduce:
1.  dnf install ./splunk-7.2.0-8c86330ac18-linux-2.6-x86_64.rpm
2.
3.

Actual results:
[root@sandbox]# dnf install ./splunk-7.2.0-8c86330ac18-linux-2.6-x86_64.rpm
Last metadata expiration check: 0:57:34 ago on Fri 02 Nov 2018 11:11:07 AM EDT.
Error:
Problem: conflicting requests
- nothing provides /bin/mv needed by splunk-7.2.0-8c86330ac18.x86_64
- nothing provides /bin/uname needed by splunk-7.2.0-8c86330ac18.x86_64

Expected results:
Successful installation

Additional info:
If I run via RPM, it works:

[root@sandbox]# rpm -i ./splunk-7.2.0-8c86330ac18-linux-2.6-x86_64.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:splunk-7.2.0-8c86330ac18 ################################# [100%]
complete

Comment 1 Marek Blaha 2018-11-05 08:10:10 UTC
Please, what the "local install of DNF" means? Installroot? We will need more information about how to reproduce the bug - including the steps needed to create "local installation". Also please run the last command with --debugsolver param:

# dnf install --debugsolver ./splunk...

This command will create debugdata directory in your working directory. Please make a tarball of it and attach it to the bugzilla.

And last but not least - we need to know installed versions of dnf, libdnf, libsolv:
# rpm -q dnf libdnf libsolv

Comment 2 Sage Russell 2018-11-05 13:43:09 UTC
Created attachment 1501893 [details]
debugdata

Comment 3 Sage Russell 2018-11-05 13:45:09 UTC
"Local install" just means that this only happens when trying to install from the local filesystem.  If I were to use a remote repo (e.g. 'dnf install xxx') that works without issue. Only occurs when installing from local system like the 'yum localinstall xxx' command.

Versions:
dnf-4.0.4-1.fc29.noarch
libdnf-0.22.0-6.fc29.x86_64
libsolv-0.6.35-3.fc29.x86_64

I wasn't aware of the --debugsolver switch.  Appreciate the info.  Debug file attached as requested.

Comment 4 Marek Blaha 2018-11-05 16:33:49 UTC
Hi, the coreutils package stopped providing /bin/mv, /bin/uname (and a lot of other pre UsrMove paths) starting from F29. Now it only provides /usr/bin/* binaries. That means dnf is in this case behaving correctly. There really is nothing providing required binaries.

The solution is to change requirements of splunk package - so it depends either on /usr/bin/mv|uname either on coreutils package itself.


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