Fedora Package Management on the Command Line (DNF)

The goal of this is to provide a quick introduction to the fedora package manager dandified yum (dnf) and a few of its useful commands.

Pretty much the definitive guide to DNF can be found here which is an well put together comprehensive reference to have if you use dnf frequently.

Basic Package Management

Most commands in dnf are self explanatory. The follow an English language type syntax.

These are probably the most common day to day ones you would use:

dnf search <package>

dnf install <package>

dnf remove <package>

dnf upgrade

Each do what you would expect.

Dnf has some globing ability when searching and installing packages. Globbing essentially allows you to specify things like wildcards when searching for packages.

For example if you wanted to search for all non C++ linux-gnu cross compilers

dnf search gcc-[!c++]*-linux-gnu

Group Packages

Dnf has package groups like you’d expect in most package managers. Common groups are used to install
Desktop Enviroments or programming tool chains etc.

You can list groups via dnf group list. Install via dnf group install "Package Group Name"

You can get information about what a group is and what will be installed by using dnf group info "Package Group Name"

Some Useful Options

There’s a few common options that you may find use for on occasion, among them are the following.

--refresh Allows for you to re-download the latest package metadata. This can be useful on occasion if the meta data is slightly old and you are testing updates from updates-testing, or if you are trying to solve any issues and want to ensure the data is completely refreshed.

-y or --assumeyes will automatically accept any queries from dnf, for example to answer yes to proceed to install updates. Useful for scripts, etc.

Security Updates Options

There are some security related specific options, useful for when you want to upgrade packages with security patches, but don’t want to update the system for any other reason.

--security will include packages with security updates-testing

--sec-severity=<severity> where <severity> can be 'Critical', 'Important', 'Moderate', 'Low' will update packages that meet the specified security severity.

--cve=<cve> where <cve> corresponds to the CVE you want to patch (assuming there is a patch available)

The are used as such: dnf upgrade --sec-severity=Critical

Package History

DNF provide package install history information using dnf history, allowing you to check what actions you have taken and if necesary rollback actions you took.

For example: dnf histroy

[[email protected]]# dnf history
Last metadata expiration check: 1:20:50 ago on Fri May 19 01:44:32 2017 BST.
ID     | Command line             | Date and time    | Action(s)      | Altered
    71 | update                   | 2017-05-18 18:23 | Update         |    1 EE

You can get the specific information for a transaction by specifying the following command with the id number of the transaction

dnf history info 71
[[email protected]]# dnf history info 71
Last metadata expiration check: 1:24:47 ago on Fri May 19 01:44:32 2017 BST.
Transaction ID : 71
Begin time     : Thu May 18 18:23:42 2017
Begin rpmdb    : 5840:6a1bb0fa948a57d1374a54b5db89abc485484497
End time       :            18:23:50 2017 (8 seconds)
End rpmdb      : 5840:32a1749248a39c64cdac79b37d54a785711794ea **
User           : ---
Return-Code    : Success
Command Line   : update
Transaction performed with:
    Installed     dnf-2.4.1-1.fc26.noarch    @updates-testing
    Installed     rpm- @updates-testing
Packages Altered:
    Upgraded google-chrome-unstable-60.0.3095.5-1.x86_64 @google-chrome-unstable
    Upgrade                         60.0.3100.0-1.x86_64 @google-chrome-unstable
Scriptlet output:
   1 Redirecting to /bin/systemctl start atd.service

This will show you what was installed, how it’s installed, and any other actions taken post installation. This can be useful to identify post installation actions that failed to run properly.

History can also be used to undo changes made.

dnf history undo <transaction id>

Or to redo a transaction

dnf history redo <transaction id>

##Fedora Release Upgrades

You can upgrade to the next Fedora release from within DNF without new install media, reinstalling, etc. This has become pretty stable with the last few releases.

One caveat I would suggest for a smooth upgrade is the following

If you have third party repositories installed they should support the new release first. The upgrade should disable them, but you can have unintended consequences if you have a lot of unsupported exotic packages installed that don’t yet support a new release.

Generally rpmfusion is supported and will quickly support new releases.


You need to install the following package.

dnf install dnf-plugin-system-upgrade

Prepare the Upgrade

dnf system-upgrade download --refresh --releasever=26

--releasever=<ver> is used to specify the specific version you want to upgrade to, this can be for example a new release (if going from 24 -> 25 you would specify 25), to a beta release in this example 26 which is near release but currently in testing. Or for example ‘rawhide’ which is Fedora rolling branch.

You may find you need to also specify --allow-erasing in an upgrade if you are upgrading your system that includes packages that don’t have an upgrade path. You need to check this carefully.

Upgrade the system

To complete the upgrade:

dnf system-upgrade reboot

You forgot about DNFs amazing abilty to find out what package provides a file. This is the only thing keeping me on fedora atm because god damn is it beyond useful

so if a program complains about libfoo.so.1 missing then you can install whatever package provides that library with

dnf install /usr/lib/libfoo.so.1

Otherwise great guide though :smiley:


Nice read :slight_smile: But, what is the @ symbol about that wendell uses in the IOMMU tutorials? For example he installs that virtualization stuff via dnf install @virtualization, is that just an alternate notation for groups?

Also is there a difference between dnf update (which wendell used) and dnf upgrade? Most of the time "update" is related to non-breaking updates, "upgrade" to those that may or may not break compatibility.

1 Like

The @ way of doing group installs is I think either historical or just another way to do it. It will accomplish the same result. Though to get things like info on groups you still need to use the dnf group <arg> set of commands

update is depreciated and the upgrade option replaces it. It's likely now that update just invokes upgrade.

@Dje4321 yeah that one I actually probably should have put in. You can also use dnf provides <name/binary/file> to get what provides that thing.