DNF System Upgrade

Most configuration files are stored in the /etc folder. If you have changed the package’s configuration files, RPM creates new files with either .rpmnew (the new default config file), or .rpmsave (your old config file backed up). You can search for these files, or use the rpmconf tool that simplifies this process. To install rpmconf, enter:

Once the install is complete enter:

For more information you can refer to the man pages (man rpmconf).

You can see a list of packages with broken dependencies by typing:

The list should be empty, but if this is not the case consider removing them as they are not likely to work.

You can see duplicate packages (packages with multiple versions installed) with:

For packages from the official repositories, the latest version should be installed. However, some packages that are still on your system may no longer be in the repositories. To see a list of these packages do:

If you see a package you do not need, or use, you can remove it with:

You can safely remove packages no longer in use with:

If you see warnings when working with RPM/DNF tools, your database might be corrupt. It is possible to rebuild it to see if resolves your issues. Always back up /var/lib/rpm/ first. To rebuild the database, run:

The system upgrade tool uses dnf distro-sync by default. If your system is partly upgraded or you see some package dependency issues, try running another distro-sync manually to see if this fixes the problem. This will attempt to make your installed packages the same version in your currently enabled repositories, even if it must downgrade some packages:

You can also use the --allowerasing option will remove packages with dependencies that can not be satisfied. Always review which packages will be removed before confirming this:

If you encounter any warnings regarding policies with SELinux, some files may have incorrect SELinux permissions. This may happen if SELinux was disabled at some point in the past. To relabel the entire system run:

and reboot.

The boot process may take a long time as it is checking and fixing all SELinux permission labels on all the files in your system.

If you do not see a report that matches your symptoms, you can file a new report from the search page. Please follow the bug reporting instructions mentioned in the README from the github repo or in man dnf.plugin.system-upgrade.

If you encounter any issues after the upgrade with a specific package, file a bug against the package with which you are having issues.

Yes. The package signing keys for the newer Fedora release are sent to older Fedora releases to allow DNF to verify the integrity of the downloaded packages. You can disable this function if needed, but is not recommended as you will be open to attacks from malicious software.

Yes, if they are configured like regular DNF repositories and the version numbers are not hard-coded in the repository file (usually found in /etc/yum.repos.d/.) Commonly used third-party repositories like RPM Fusion should work. However, if attempting to upgrade prior to, or soon after, an official Fedora release, they may not have updated their repository paths, and DNF may be unable to find their packages. Usually, this should not prevent the upgrade from running successfully. Also, you can update packages from the third-party repository later.

It is strongly recommended to upgrade an EOL release on any production system, or any system connected to the public internet.

Any upgrade from Fedora 20 or earlier is done at your own risk as DNF was not the default package management tool. However, if you do have a release newer than Fedora 20 that is EOL, you can attempt to do an upgrade, but this method is not supported. You may try to upgrade through intermediate releases until you reach a currently-supported release, or try to upgrade to a currently-supported release in a single operation. Again this is un-supported and is at your own risk.

It is highly recommended to upgrade across just one release (e.g. 27 to 28). However, for the first month or so after a new release, upgrades from the last-but-one release are 'supported' (N-2, where N is the current release). The Fedora Release Life Cycle is specifically designed to provide this approximate one month "grace period" to allow users the choice to upgrade their systems on a yearly basis, or once every two releases.

Around a month after the new release comes out, the last-but-one release becomes End Of Life (EOL). The upgrade is likely to work successfully after the release goes end-of-life, but the time period after the new release may be uncertain.

Upgrades across more than two releases are not supported, and issues encountered with such upgrades may not be considered significant bugs.

When upgrading across multiple releases, you may need to import the GPG key for the release you want to update to. You can do this with:

(where N is the Fedora version.)

Refer to the getfedora.org FAQ on Keys for details.

Yes, but this is subject to temporary breakage as with any other aspect of a pre-release.