How to upgrade your Fedora Linux system with DNF

6 readers like this.
How to upgrade your Fedora Linux system with DNF

Upgrading any operating system to a new release version can be time-consuming and fraught with problems.

In fact, the term "upgrade" may not even be applicable. Many times in the past it has been necessary for me to perform a complete reinstall because the alleged upgrade path would fail. Having to perform a reinstall is time-consuming when several systems are involved, and I usually have eight to ten at any given time.

The first upgrade path I used with Fedora was that integrated into the previous version of the Anaconda installer. It did seem to work in fairly simple installation but, over several upgrades through a period of years and multiple releases, it would leave a large amount of cruft in the form of orphaned, duplicated, and unneeded packages.

The new version of Anaconda that first appeared in Fedora 18 had no options whatsoever for performing upgrades. There was an attempt around that same time to provide an upgrade path using a program called fed-up that was available from third-party repository. Most people that I knew of who attempted to use it, including me, had very poor results. I had one system that simply refused to boot beyond the GRUB menu that started the second portion of the process. Sometimes the hosts were simply unusable after the upgrade.

I have recently upgraded from Fedora 22 to 23 and then from Fedora 23 to 24 on several systems and have found the new dnf system-upgrade programs and procedures to be far more usable and reliable than previous automated or semi-automated upgrade programs.

dnf system-upgrade

The new Fedora upgrade system is based on DNF, the replacement package manager for YUM. I have found that DNF is better than YUM for all of the package management tasks that I find myself performing. It also seems to work much better as the basis for the dnf system-upgrade method of performing upgrades.

First introduced with Fedora 23 as a means to upgrade from Fedora 22, I have had good and reliable success with system-upgrade. It is a multistep process but it can be very easily automated with a script or two.

The system-upgrade procedure was not without at least one problem, for me. After the upgrade on several hosts, the display manager did not start either during the startup sequence or by using the command line. It turned out that the display manager service link was missing so that systemd was unable to start the GUI login manager. Adding the following symlink solved that problem.

ln -s /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/sddm.service

The sddm display manager is the current default display manager for Fedora 23 and 24. You can substitute your favorite display manager such as kdm for KDE or gdm for GNOME if you have those installed.

dnf system-upgrade also has some tools available to ensure and verify that the upgraded system is reasonably free of cruft. I think this is a very important step in ensuring that future upgrades are also clean and trouble-free.

Upgrade preparation

It is always a good idea to prepare for an upgrade no matter how it is performed, even if doing a completely new installation of the latest release and wiping out the previous release. Here are a few tips to help ensure that things go smoothly.

Filesystem design

Good filesystem design goes all the way back to the initial installation of Linux on the host computer. The primary objective is to ensure that personal data does not get erased during an upgrade or re-installation. The best way to accomplish this is to create the /home directory as a separate filesystem during the initial operating system installation. If /home is a separate filesystem it can be preserved without being disturbed during an upgrade or a complete reinstall.

Both the dnf system-upgrade procedure and a re-installation allow you to keep your current home filesystem without reformatting it. It will then be mounted automatically on reboot.


Always perform a backup of /home as well as other directories, particularly /etc and /var. Both /etc and /var contain data that may be useful after a re-installation in particular. The /etc directory contains some local configuration files like DHCP and network interface configuration files that you may want to copy back to /etc after a re-installation. Some may also get overwritten during an otherwise successful upgrade. It can be very helpful to have those backups in order to copy over any overwritten configuration files.

The /var directory may contain data for programs like domain name services, various SQL databases, and web service such as Apache. You will want to preserve those as well.

Read the procedures

Be sure to read the upgrade procedures posted on the Fedora wiki upgrade page. This page usually contains not only the specific instructions required to perform the upgrade, it also has a list of questions that are typically asked about upgrades, tips for performing the upgrade, and a section on how to resolve post-upgrade problems that might occur.

Running the upgrade

This is probably the easiest part of the upgrade, because all you have to do is enter a very specific series of commands.

The commands in this section assume that you are logged in as root. The first step in performing the upgrade is to ensure that your system already has the most recent updates to the current release.

dnf -y update

You should reboot your system after performing the DNF update, especially if the update included a new kernel.

Next, install the dnf system upgrade plug-in package.

dnf install dnf-plugin-system-upgrade

Step three is to download the files required for the new release to which you are upgrading. This dnf system-upgrade procedure is designed to upgrade one or two release versions, so you could upgrade from Fedora 22 to Fedora 23 or 24, or from Fedora 23 to 24. Be sure to specify the correct releasever in the command.

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

The fourth step is to run the following command which reboots the computer and starts the upgrade process. At first, it will look like a regular reboot, but it will display a message that the upgrade is starting followed by various status messages as each package is upgraded.

dnf system-upgrade reboot

At the end of the upgrade, the system will reboot and take you to your normal login screen.

Cleaning up

Before you start productive work, however, you should perform a couple more steps to ensure that the system is left in a reasonably clean state. This ensures that regular updates will be performed without any problems and it gives a good, cruft-free starting point for the next upgrade.

Sometimes system-level packages install new configuration files in /etc and it is always a good idea to know which ones those are so you can use either the original configuration if you have modified it, or the new one. New configuration files may need to be modified to meet your specific requirements. This command identifies those new configuration files you might want to check.

rpmconf -a

You should also look for packages with broken dependencies with the following command.

dnf repoquery --unsatisfied

If there are any unsatisfied dependencies, you should probably remove the packages listed by the command as they are unlikely to work properly.

It is also possible that there may be duplicate packages with different version levels. The following command locates those.

dnf repoquery --duplicated

If duplicate packages are located, you should remove the older versions and keep only the newest ones.

There is a possibility that some packages may still exist on your system that are not listed in the Fedora repositories. The command below lists those packages.

dnf list extras

If any extra packages are found, you should probably delete them. Just be certain not to delete ones that may have been installed from other repositories such as RPMFusion or DropBox. As another example, you may also find that LibréOffice files show up with this command if they were not installed from the Fedora repository but were installed using the downloads from the LibréOffice website.

It is possible to remove all packages that are duplicates, extras, or have broken dependencies using the following command.

dnf autoremove

But before you do so, you should be certain that they really are no longer needed. I prefer to use the list provided by the previous commands and remove unneeded packages manually. I do not recommend using the dnf autoremove command.


I have now performed at least two upgrades on multiple systems using the dnf system-upgrade procedures. They have worked well and I have had only the one problem mentioned above with the missing symbolic link. I finally feel safe using this upgrade method.

Although it can take a couple hours to completely upgrade a typical desktop system with a GUI desktop, the actual time I spend on each system is limited to entering the commands. I have reduced that even more by creating a short script of the commands used for the actual upgrade. I have not scripted the post-upgrade commands as they require some judgment and decision making regarding which packages to leave and which can be deleted.

The DNF installer is available for CentOS 7, but not for release 6. So upgrades from CentOS cannot use the dnf system-upgrade programs. I hope that they can make that functionality available as I have several CentOS 6 hosts for which I would like an easy upgrade path to CentOS 7.

Everyone will have a different environment and will probably experience the dnf system-upgrade procedure differently. I would appreciate reading about your experiences in the comment section.

David Both
David Both is an Open Source Software and GNU/Linux advocate, trainer, writer, and speaker. He has been working with Linux and Open Source Software since 1996 and with computers since 1969. He is a strong proponent of and evangelist for the "Linux Philosophy for System Administrators."


I will try this.

I have successfully used the simple & successful ubuntu upgrade for at least 5 years - more times than I can count - with only one failure. Have always wondered why fedora has so much trouble with this - I have failed with every fedora method to date.

Hope this works tonight ;-)

For ages I have used the "unsupported" yum update method documented here:

With the exception of the systemd debacle around about Fedora 16 or 17, this method has worked like a charm and kept systems on-line as much as possible. You do have to pay attention to dependencies and may have to resolve issues and restore packages, but it worked. I've had a few (virtual) machines that where upgraded using this method from Fedora 1 in a continuous chain to Fedora 23 (although systemd require some serious recovery efforts). For me this has been the best approach for remote systems (as in hours of driving time remote) where you simply can NOT have them off-line during the upgrade process. Fed-up, which was vastly superior to "preupgrade: was worthless to me because it used anaconda and took the machine off-line during the upgrade and, if anything goes wrong, you could get screwed real fast with a remote machine.

In addition to the straight forward manual "dnf --releasver=" method documented in that URL, the URL above points out that they have created a (YES UNSUPPORTED) script to automate most of it. That's the fedora-upgrade package. Yes it's "unsupported" but it should be supported. The only failures I've run into it are dependency errors that should not be in the rpm repos to begin with. Things like circular dependencies and broken obsolete dependencies. If they actually supported the fedora-upgrade process, they would be force to fix those broken dependencies. Fortunately, the problems been easy to work around and get a clean upgrade with virutally no downtime or loss of control of my remote servers. Just backup a database of your installed packages and delete any offending package (often rpmfusion) and then reinstall after the upgrade.

If there is any problem I have seen in recent years, it's that there hasn't been enough testing on old hardware. I suppose like many, I have a collection of computers of varying age, that I keep running "just in case". Maybe it's a version of hoarding, but let me say this: my hoarding allowed me to be able to recover some files I had saved on some ZipDisks, using some old hardware that could still manage the connectors on my ZipDisk drive.
I ended up skipping over Fedora 22, and waited for 23, since as far as I could tell, there wasn't any recognition or fix for issues with my Intel graphics chip. Once you spend an entire weekend upgrading, only to have to downgrade to the prior version, you don't feel like going through that again any time soon, and this was with making backups (fortunately).
I've had some catastrophic failures with these "automatic" upgrades. It seems so cool, in that you don't have to load all the individual bits and pieces for your unique situation after upgrading, but when it doesn't work....ugh! And it is VERY time-consuming.
My preferred way to upgrade is a backup, then doing a netinstall.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.