View Issue Details

IDProjectCategoryView StatusLast Update
0016676CentOS-8dnfpublic2019-11-01 16:36
Status newResolutionopen 
PlatformServerOSCentOSOS Version8
Product Version8.0.1905 
Target VersionFixed in Version 
Summary0016676: Can't install a list of packages like we can in CentOS (6 or 7)
DescriptionIn CentOS 6 and 7, we could duplicate a server function fairly quickly by creating a pkglist.txt file from the server to be duplicated and then installing it on the new server. Creating the pkglist.txt was done with: yum list installed | cut -d" " -f1 | egrep "\." > pkglist.txt
And it was then imported on the new server with:
yum install $(cat pkglist.txt|xargs)
Trying to install the pkglist.txt file on a fresh install of CentOS 8, shows the packages with no install candidate and the packages that are already installed and then displays the following error at the end: Error: Unable to find a match
Steps To Reproduce1.) create the pkglist.txt file on the server to be duplicated
2.) copy the pkglist.txt file to the fresh install of CentOS 8
3.) run "yum install $(cat pkglist.txt|xargs)
4.) get the error: Unable to find match
Additional InformationNote that if you strip the file down to just a few packages (5 or 6) with a couple that you know do not exist on the default install, you get the correct result:

stripped down pkglist.txt file contains the following:


Run "yum install $(cat pkglist.txt|xargs)"


usr/bin/yum -y install $(/bin/cat /root/pkglist.txt|xargs)
Last metadata expiration check: 0:06:09 ago on Thu 31 Oct 2019 09:18:39 AM CDT.
Package info-6.5-4.el8.x86_64 is already installed.
Package initscripts-10.00.1-1.el8_0.1.x86_64 is already installed.
Package iproute-4.18.0-11.el8.x86_64 is already installed.
Package iptables-1.8.2-9.el8_0.1.x86_64 is already installed.
Package iputils-20180629-1.el8.x86_64 is already installed.
Dependencies resolved.
 Package Arch Version Repository Size
 iptables-services x86_64 1.8.2-9.el8_0.1 BaseOS 58 k
 iptables-utils x86_64 1.8.2-9.el8_0.1 BaseOS 71 k

Transaction Summary
Install 2 Packages

Total download size: 129 k
Installed size: 78 k
Downloading Packages:
(1/2): iptables-services-1.8.2-9.el8_0.1.x86_64.rpm 294 kB/s | 58 kB 00:00
(2/2): iptables-utils-1.8.2-9.el8_0.1.x86_64.rpm 357 kB/s | 71 kB 00:00
Total 86 kB/s | 129 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing : 1/1
  Installing : iptables-utils-1.8.2-9.el8_0.1.x86_64 1/2
  Installing : iptables-services-1.8.2-9.el8_0.1.x86_64 2/2
  Running scriptlet: iptables-services-1.8.2-9.el8_0.1.x86_64 2/2
  Verifying : iptables-services-1.8.2-9.el8_0.1.x86_64 1/2
  Verifying : iptables-utils-1.8.2-9.el8_0.1.x86_64 2/2

  iptables-services-1.8.2-9.el8_0.1.x86_64 iptables-utils-1.8.2-9.el8_0.1.x86_64

Tagsdnf yum




2019-10-31 17:29

reporter   ~0035616

I typically just take my list of packages, load it into vi and replace the return with a space... and then put "dnf install " at the front of the line, save the file, make it executable and then run it.

If you are getting one or more match not found errors, one or more packages that are in your list aren't found in the repositories you have configured. For example. the CentOS PowerTools repo is off by default and it contains some packages people are used to being in base.

To see what's missing I recommend you pipe the std out and std error to grep for match ( whatever commands 2>&1 | grep match ). Once you can see what file(s) it isn't finding, you'll have have a better idea what to look for. I'm guessing that dnf is operating as it is supposed to. You haven't given the sample file so no way to check it. If indeed what it can't match is in a repository that is enabled, you'll need to prove that with specifics that are reproducible before anyone can make any progress on your report.


2019-10-31 19:43

reporter   ~0035618

Dowdle, I see what you are saying, and that /is/ exactly what is happening. There are indeed 1 or more (a lot more) packages that display "No match for argument", and "yes" this is exactly what is causing the file to bomb out from installing, as I can copy just one of those packages with "No match for argument" into the pkglist.txt file that I showed that did install, and it too will fail. My point is, that when installing this on CentOS 7, I would get the same sort of error, but yum would go ahead and install what it /could/ install anyway, which is what I was expecting here.

I've got a workaround using sed to modify the pkglist.txt into ta bash script and execute the install one by one, but what I was looking for was an answer that dealt with the change between 7 and 8.



2019-10-31 20:18

reporter   ~0035619

I've seen this behavior on Fedora for many releases. Considering DNF has been in Fedora for some time... I guess that is just the new expected behavior and there's no going back. Unless CentOS is acting differently than RHEL here, and to the best of my knowledge it isn't, nothing really CentOS can do.

Moving to dnf accomplished quite a few things... migration to python 3, migration to a different dependency resolver, fix quite a few bugs, add quite a bit of new functionality (which for Fedora meant being able to use it for upgrading from one release to the next and even leapfrog upgrades). If there is a flag / option to have it act like it does in EL7, I'm not aware of it.


2019-10-31 21:26

reporter   ~0035620

It appears that there /is/ a way to make dnf work like yum did. It requires adding a single line to the dnf.conf file (/etc/dnf/dnf.conf)


It fixes my problem at least. Thanks for your feedback.


2019-10-31 22:58

reporter   ~0035622

I'm glad you found a fix. I guess you can close this bug now.

I think I'll leave it at the default myself because I like to be made aware of when packages have changed names or have been removed or whatever the case may be... so that I can get my package list cleaned up. It isn't that big of a deal once... but when you use it from release to release over a few years (mainly with regards to Fedora that releases every 6 months), without cleaning it up periodically, it picks up a bunch of cruft.


2019-11-01 16:33

reporter   ~0035628

Yes. I'll close out the ticket. I actually decided not to put the strict=0 in the dnf.conf, as I just want it for the one-time event, not for future events. I'm using this at the command line instead to install the pkglist.txt file:

yum --setopt=strict=0 install $(cat /root/pkglist.txt|xargs)


dnf --setopt=strict=0 install $(cat /root/pkglist.txt|xargs)

Will close the bug now.


2019-11-01 16:36

reporter   ~0035629

Guess a dev or administrator will have to close. That's kind of weird, but whatever.

Issue History

Date Modified Username Field Change
2019-10-31 14:27 sspencerwire New Issue
2019-10-31 14:27 sspencerwire Tag Attached: dnf yum
2019-10-31 17:29 dowdle Note Added: 0035616
2019-10-31 19:43 sspencerwire Note Added: 0035618
2019-10-31 20:18 dowdle Note Added: 0035619
2019-10-31 21:26 sspencerwire Note Added: 0035620
2019-10-31 22:58 dowdle Note Added: 0035622
2019-11-01 16:33 sspencerwire Note Added: 0035628
2019-11-01 16:36 sspencerwire Note Added: 0035629