How to upgrade your Fedora Linux system to the latest release with DNF system-upgrade

Image by: David Both CC-by-SA 4.0

Upgrading any operating system to a new release version can be time-consuming and fraught with problems. Fedora 40 was released very recently and I used these easy steps to upgrade all twelve of my home systems. It was easy and all went well.

The first upgrade path I used with Fedora was integrated into the previous version of the Anaconda installer. It did seem to work in fairly simple installations 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 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.

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. After having upgraded from Fedora 22 to 23 and then from Fedora 23 to 40 on as many as twelve systems, I found the then new dnf system-upgrade programs and procedures to be far more usable and reliable than previous automated or semi-automated upgrade programs. I’ve been using this tool ever since with outstanding results.

In this article, I’ll first show you the individual steps you can take to perform a release upgrade on Fedora. Then I’ll show you how you can easily perform upgrades using a script I wrote that you can download.

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.

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.

1. 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.

With proper filesystem design, 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.

2. Backup

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.

3. 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 37 to Fedora 38 or 39, then from Fedora 38 to 40. Be sure to specify the correct releasever in the command.

# dnf system-upgrade download --refresh --releasever=40

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 LibreOffice files show up with this command if they were not installed from the Fedora repository but were installed using the downloads from the LibreOffice website.

It is possible to remove all packages that are duplicates, extras, or have broken dependencies using the following command. But I don’t recommend doing this as it requires a knowledgeable level of judgement!

# 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.

My Upgrade Script

Even though these steps are easy and take little time on my part, I would still need to enter the commands for each step. That meant constant attention to multiple hosts so I could enter the next command. I subscribe to the Linux Philosophy of “Automate Everything,” so I wrote a Bash script to do just that.

You can download my script, doUpdates.sh, and use it for your own upgrades. Install it on every system on which you want to use it. Here’s the Help from my script to give you an idea how it works.

# doUpdates.sh -h
################################################################################
#                                                                              #
# doUpdates - Performs all updates, builds new GRUB2, and reboots if a new     #
# kernel or glibc was installed. You can force a reboot if necessary.          #
#                                                                              #
# No options simply checks for updates.                                        #
#                                                                              #
# Syntax: doUpdates --[g|h|c|V|Rrsuv]                                          #
#                                                                              #
# options:                                                                     #
# g     Print the GPL license notification.                                    #
# c     Check to see if updates are available and whether reboot would be      #
#       needed. Does not actually do the update or reboot. Also checks for     #
#       running Virtual Machines.                                              #
# h     Print this Help.                                                       #
# r     Reboot if the kernel or glibc or both have been updated.               #
# R     Force reboot even when other conditions are not met.                   #
# s     Perform ACPI shutdown of running VMs. Doesn't require -r or -u options #
# u     Do updates.                                                            #
# v     Verbose mode. Dispays list of updates.                                 #
# V     Print software version and exit.                                       #
#                                                                              #
################################################################################

This script is distributed under the GNU General Public License version 3 or later so you can use it in compliance with that license.

Conclusions

I have performed many 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 feel quite 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 amount of human time I spend on each system is limited to entering the commands. I have reduced that even more by creating a 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.