How to upgrade Fedora 24 using dnf system-upgrade

How to upgrade your Fedora Linux system with DNF

5 pengiuns floating on iceburg
Image by :

Subscribe now

Get the highlights in your inbox every week.

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.


About the author

David Both - David Both is a Linux and Open Source advocate who resides in Raleigh, North Carolina. He has been in the IT industry for over forty years and taught OS/2 for IBM where he worked for over 20 years. While at IBM, he wrote the first training course for the original IBM PC in 1981. He has taught RHCE classes for Red Hat and has worked at MCI Worldcom, Cisco, and the State of North Carolina. He has been working with Linux and Open Source Software for almost 20 years. David has written articles for...