Managing CentOS Migrations and RHEL Upgrades

In the pre-upgrade phase, the Leapp tool assesses the system state and collects package information to map the required configuration and package changes. After the analysis, the Leapp tool creates a report that describes potential issues, recommendations, and other information.

The pre-upgrade analysis might also require that the user acknowledge and confirm system tasks that the Leapp tool recommends. For example, a pre-upgrade check could reveal that the target release version might not support a specific kernel module. The Leapp tool would prompt the user to confirm removing the kernel by providing input in an answer file.

The Leapp answer file is a regular text file that contains information about the system tasks that require input and the variables that confirm the actions. The Leapp tool uses the /var/log/leapp/answerfile file as its answer file.

If the pre-upgrade analysis determines that the system cannot be upgraded, then the Leapp tool stops the upgrade process and provides resolution information in the /var/log/leapp/leapp-report.txt report file.

If the pre-upgrade analysis determines that the system can be upgraded, then the Leapp tool continues to the upgrade phase.

In the upgrade phase, the Leapp tool changes the system and downloads the necessary RPM packages. The Leapp tool also creates a RAM disk image based on the new version of the target operating system. When the Leapp tool finishes preparing the upgrade, it requests a system reboot. When the system restarts, it uses the new RAM disk image with the new kernel.

The Leapp tool continues to perform system changes after the reboot. This stage might take some time to complete depending on the characteristics of the system and its installed packages. When the Leapp tool finishes the upgrade, the tool displays a success message and other information about the upgrade.

As a final step, perform post-upgrade checks and tasks, such as manually installing packages that are excluded by the upgrade process, removing packages that are no longer needed, disabling repositories that are not used anymore, and so on.

If the system uses Red Hat Satellite, then you might need to enable and synchronize the repositories in Satellite Server. In that case, verify that the content view of the system contains the required repositories and that the repositories are synced.

For Red Hat Satellite, Red Hat recommends that you create an activation key that is associated with the required content view. Manually enabling and disabling repositories can be a time-consuming task. By creating an activation key for the upgrade process, you simplify the preparation process because you can include all required repositories for the upgrade without needing to revert to a previous repository configuration.

If your environment uses custom repositories, then make sure that the Leapp tool is aware of those repositories. You can manually enable a repository, or define a repository in the /etc/leapp/files/leapp_upgrade_repositories.repo file.

The repositories that the leapp_upgrade_repositories.repo file defines are automatically loaded by the Leapp tool. These repositories are not used by YUM or DNF in regular package transactions, so the repositories are used exclusively by the Leapp tool.

To enable the Leapp tool to use the repositories that the /etc/yum.repos.d/ directory defines, you must explicitly define the repositories as arguments in the command line.

Among other tasks, the in-place upgrade process installs new packages and changes the configuration of the package manager. To perform these changes, the Leapp tool requires that you remove all system configuration that prevents the system from using newer content.

Organizations might use different methods to lock the system and package versions. For example, the subscription-manager command provides the functionality to configure a specific release version. If this functionality is enabled, then the system cannot update to a minor release.

The following command removes the version lock configuration on the subscription-manager command:

[root@host ~]# subscription-manager release --unset
Release preference has been unset

YUM also provides a method to lock package versions. The yum-versionlock plug-in excludes package names and versions that are not part of a specific set.

The following command removes the YUM version lock configuration:

[root@host ~]# yum versionlock clear
Loaded plugins: product-id, search-disabled-repos, subscription-manager, versionlock
versionlock cleared

Before you install the Leapp tool, update the system.

[root@host ~]# yum update
...output omitted...
Is this ok [y/N]: y
...output omitted...
Complete!

In a RHEL 7 system, you can install the Leapp tool from the rhel-7-server-extras-rpms repository. If the system does not have this repository, then you can enable it by using the subscription-manager command. The following example shows that the system can access only the rhel-7-server-rpms repository.

[root@host ~]# yum repolist
Loaded plugins: product-id, search-disabled-repos, subscription-manager
repo id                                 repo name                                    status
rhel-7-server-rpms/7Server/x86_64       Red Hat Enterprise Linux 7 Server (RPMs)     34,267
repolist: 34,267

The Leapp package name is leapp-upgrade. Enable the required repository and install the tool.

[root@host ~]# subscription-manager repos --enable=rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.

[root@host ~]# yum install leapp-upgrade
Is this ok [y/N]: y
...output omitted...
Complete!

The process to install the Leapp tool in a RHEL 8 system is similar to the process for RHEL 7. The main difference is that for a RHEL 8 system, you install the Leapp tool from the rhel-8-for-x86_64-appstream-rpms repository.