Bug 1645638

Summary: Local installation with dnf is unable to find /bin
Product: [Fedora] Fedora Reporter: Sage Russell <spam>
Component: dnfAssignee: Marek Blaha <mblaha>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: dmach, mblaha, mhatina, packaging-team-maint, rpm-software-management, spam, vmukhame
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-05 16:33:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
debugdata none

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.