Note: This article first appeared at Opensource.com on July 28, 2016.
I have recommended against doing upgrades from one release of Fedora to a newer one in the past. This was primarily due to the serious inconsistencies and outright failures of both the old Anaconda installer and the more recent fedup upgrade utility for Fedora.
I do not refer to installing updates – fixes and patches to a current version of Fedora – but rather to upgrading from one version of Fedora to another. For example upgrading from Fedora 22 to Fedora 23.
However I can now suggest a method for performing near-flawless upgrades of Fedora. The new replacement for yum is dnf and it provides a nice means for easily performing network upgrades from old releases of Fedora to newer ones. This works not only for single-version upgrades, such as from Fedora 22 to 23, but also for multi-version upgrades. I have used the dnf method successfully to upgrade from Fedora 19 to Fedora 23.
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.
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 is not without at least one problem. 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.
It is always a good idea to prepare for an upgrade no matter how it is performed, even if doing a complete new installation of the latest release and wiping out the previous release. Here are a few tips to help ensure that things go smoothly.
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.
Before you start productive work, however, you should perform a couple more steps to ensure that the system is left in a reasonable 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.
Check the local RPM database for problems.
You should also look in the repositories 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 web site.
It is possible to remove all packages that are duplicates, extras, or have broken dependencies using the following command.
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 ( and presumably RHEL) 7, but not for release 6. So upgrades from CentOS and RHEL 6 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.