Elastic Compute Service:Red Hat Enterprise Linux

Before the upgrade, we recommend that you understand the upgrade risks and create a snapshot to back up data. This lets you quickly recover data if the upgrade fails.

Use the root user to remotely connect to the ECS instance that runs the RHEL system.

For more information, see Connect to a Linux instance using Workbench.

Check whether your RHEL instance uses an Alibaba Cloud RHEL subscription.

rpm -q client-rhel7

• If no response is returned, your system does not use an Alibaba Cloud RHEL subscription. You must first purchase a subscription before you perform the upgrade.

• If a response similar to client-rhel7-3.0-1.el7_9.noarch is returned, your system uses an Alibaba Cloud RHEL subscription. You can proceed with the upgrade.

  

Prepare the upgrade environment.

1. Upgrade the RHEL system to the latest version. The latest version usually contains fixes for known vulnerabilities, errors, and security issues. Then, restart the system for the changes to take effect.

   yum -y update
   reboot

2. Install the Leapp upgrade tool on the RHEL system.

   yum -y install leapp leapp-rhui-alibaba --enablerepo="*"

3. Check whether Leapp is installed.

   leapp --version

   If a response similar to leapp version xxx is returned, Leapp is installed.

Perform a pre-upgrade check.

Because system configurations can vary significantly, you must use the Leapp tool to perform a pre-upgrade check on the system before the upgrade. You can view the check results from the Leapp tool and resolve any reported issues based on the tool's suggestions to meet the upgrade requirements.

1. Perform a pre-upgrade check.

   • Pre-upgrade to the latest version of RHEL 8.

     leapp preupgrade  --no-rhsm

   • Pre-upgrade to a specific target version. For example, upgrade RHEL 7 to RHEL 8.8.

     leapp preupgrade --no-rhsm --target 8.8

     Note

     You can run the leapp preupgrade -h command to view the target versions that the current system supports for an upgrade.

2. View the pre-upgrade check results.

   The pre-upgrade check logs from the Leapp tool are saved in the following log files:

   • /var/log/leapp/leapp-preupgrade.log: Leapp tool logs

   • /var/log/leapp/leapp-report.txt: Pre-upgrade check report in text format

   • /var/log/leapp/leapp-report.json: Pre-upgrade check report in JSON format

   If the pre-upgrade check fails, the failed check items are displayed, as shown in the following figure.

   

3. (Conditional) Handle pre-upgrade errors.

   Check the log file /var/log/leapp/leapp-report.txt for pre-upgrade error messages and resolve the errors based on the suggestions from the Leapp tool. The following section lists common pre-upgrade check errors and their solutions by risk level.

   • high (inhibitor): High risk (inhibits upgrade). This type of issue directly blocks the upgrade process and must be resolved before you can proceed.

     • Case 1: Multiple kernel versions are installed on the system.

       Risk Factor: high (inhibitor)
       Title: Multiple devel kernels installed
       Summary: DNF cannot produce a valid upgrade transaction when multiple kernel-devel packages are installed.
       Remediation: [hint] Remove all but one kernel-devel packages before running Leapp again.
       [command] yum -y remove kernel-devel-3.10.0-1160.11.1.el7

       Solution: Multiple kernel versions are installed on the system. You need to uninstall the old kernel packages. Run the command suggested by the Leapp tool to uninstall the old kernel, for example, yum -y remove kernel-devel-3.10.0-1160.11.1.el7 in this case.

     • Case 2: Kernel modules that are not supported in RHEL 8 are loaded on the system.

       Risk Factor: high (inhibitor)                                                                                                                                                                                         
       Title: Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.                                                                                                                
       Summary: Support for the following RHEL 7 device drivers has been removed in RHEL 8:                                                                                                                                  
            - floppy

       Solution: Some modules, such as the `floppy` module in this example, are not supported in RHEL 8. You can run the following command to uninstall them.

       rmmod floppy

     • Case 3: Abnormal sshd_config configuration

       Risk Factor: high (inhibitor)
       Title: Possible problems with remote login using root account
       Summary: OpenSSH configuration file does not explicitly state the option PermitRootLogin in sshd_config file, which will default in RHEL8 to "prohibit-password".
       Remediation: [hint] If you depend on remote root logins using passwords, consider setting up a different user for remote administration or adding "PermitRootLogin yes" to sshd_config. 
       If this change is ok for you, add explicit "PermitRootLogin prohibit-password" to your sshd_config to ignore this inhibitor

       Solution:

       1. In the /etc/ssh/sshd_config configuration file, set PermitRootLogin to yes.

          Note

          The default value of PermitRootLogin is different in RHEL 7 and RHEL 8:

          • RHEL 7: The default value is yes, which indicates that the root user is allowed to log on using a password or key.

          • RHEL 8: The default value is prohibit-password, which indicates that password-based logon is prohibited.

       2. Restart the sshd service.

          systemctl restart sshd

     • Case 4: The acknowledgement file is not edited and confirmed.

       Risk Factor: high (inhibitor)
       Title: Missing required answers in the answer file
       Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
       For more information consult https://leapp.readthedocs.io/en/latest/dialogs.html
       Remediation: [hint] Please register user choices with leapp answer cli command or by manually editing the answerfile.
       [command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True

       Solution: In this case, you must delete the pam module that is not supported in RHEL 8. This action requires confirmation in the /var/log/leapp/answerfile file. Run the following command to set confirm to True.

       leapp answer --section remove_pam_pkcs11_module_check.confirm=True

       

   • high: High risk. This type of issue does not directly block the upgrade, but we recommend resolving it before or after the upgrade to prevent issues after the upgrade.

     • Case 1: Some packages cannot be installed.

       Risk Factor: high
       Title: Packages from unknown repositories may not be installed
       Summary: 3 packages may not be installed or upgraded due to repositories unknown to leapp:
       - python3-pyxattr (repoid: rhel8-CRB)
       - rpcgen (repoid: rhel8-CRB)
       - ustr (repoid: rhel8-CRB)
       Remediation: [hint] In case the listed repositories are mirrors of official repositories for RHEL (provided by Red Hat on CDN) and their repositories IDs has been customized, you can change the configuration to use the official IDs instead of fixing the problem. You can also review the projected DNF upgrade transaction result in the logs to see what is going to happen, as this does not necessarily mean that the listed packages will not be upgraded. You can also install any missing packages after the in-place upgrade manually.

       Solution: You can manually install the missing packages after the upgrade.

     • Case 2: Some RHEL 7 packages are not upgraded.

       Risk Factor: high
       Title: Some RHEL 7 packages have not been upgraded
       Summary: Following RHEL 7 packages have not been upgraded:
       leapp-upgrade-el7toel8-0.18.0-1.el7_9
       kernel-3.10.0-1160.92.1.el7
       leapp-rhui-alibaba-1.0.0-1.el7_9
       Please remove these packages to keep your system in supported state.

       Solution: Run the yum remove leapp-upgrade-el7toel8-0.18.0-1.el7_9 kernel-3.10.0-1160.92.1.el7 leapp-rhui-alibaba-1.0.0-1.el7_9 command to delete these packages.

   • medium: Medium risk. This type of issue does not directly block the upgrade, but we recommend that you resolve it before or after the upgrade to prevent potential issues after the upgrade.

     Case: The pam_pkcs11 module in the PAM configuration will be removed.

     Title: Module pam_pkcs11 will be removed from PAM configuration
     Summary: Module pam_pkcs11 was surpassed by SSSD and therefore it was removed from RHEL-8. Keeping it in PAM configuration may lock out the system thus it will be automatically removed from PAM configuration before upgrading to RHEL-8. Please switch to SSSD to recover the functionality of pam_pkcs11.
     Remediation: [hint] Configure SSSD to replace pam_pkcs11

     Solution: To ensure that the system's authentication feature functions correctly after the upgrade, you must configure SSSD to replace the functionality of pam_pkcs11.

   • low: Low risk. This type of issue has a minor impact on the upgrade process or system operation, but we recommend that you resolve it before or after the upgrade to ensure stable system operation.

     Case: SELinux will be set to permissive mode.

     Risk Factor: low 
     Title: SElinux will be set to permissive mode
     Summary: SElinux will be set to permissive mode. Current mode: enforcing. This action is required by the upgrade process to make sure the upgraded system can boot without beinig blocked by SElinux rules.
     Remediation: [hint] Make sure there are no SElinux related warnings after the upgrade and enable SElinux manually afterwards. Notice: You can ignore the "/root/tmp_leapp_py3" SElinux warnings.

     Solution: After the upgrade, make sure that there are no SELinux-related warnings, and then reset SELinux to enforcing mode to ensure system security and compliance.

   • info: Informational. This type of issue is usually an informational message and does not affect the upgrade process or system operation. You can view the specific messages in the report to understand the changes that will occur during the upgrade process.

     Case: The release version in /etc/dnf/vars/releasever will be set to the current target version.

     Risk Factor: info 
     Title: Release version in /etc/dnf/vars/releasever will be set to the current target release
     Summary: On this system, Leapp detected "releasever" variable is either configured through DNF/YUM configuration file and/or the system is using RHUI infrastructure. To avoid issues with repofile URLs (when --release option is not provided) in cases where there is the previous major.minor version value in the configuration, release version will be set to the target release version (8.8). This will also ensure the system stays on the expected target version after the upgrade

     Solution: No action is required.

Perform the upgrade.

• Upgrade to the latest version of RHEL 8.

  leapp upgrade  --no-rhsm

• Upgrade to a specific target version. For example, upgrade RHEL 7 to RHEL 8.8.

  leapp upgrade  --no-rhsm --target 8.8

The following figure indicates that the upgrade is successful.

Restart the instance and boot into the new system.

reboot

Verify the upgrade result.

• Run the cat /etc/redhat-release command to check whether the system version is updated.

• Check the upgrade execution logs or reports for any errors.

• Observe whether your business runs correctly on the RHEL 8 system.

(Conditional) Run the following commands to configure the RHEL source.

After you use the Leapp upgrade tool to complete the upgrade, the /etc/dnf/vars/releasever file is modified by default to lock the system to a specific minor version of RHEL. For example, for RHEL 8.8, the repository source points to https://xxxx/8.8/xxx, so you can only access packages for the RHEL 8.8 version. If you want to automatically access the packages of the latest RHEL 8 version to obtain the latest security patches and feature updates, you can delete the releasever configuration file and rebuild the DNF cache.

rm -f /etc/dnf/vars/releasever
dnf clean all && dnf makecache

After the command is run, the repository source for RHEL 8 is updated to https://xxxx/8/xxx. The system can then automatically obtain the latest security patches and feature updates for RHEL 8, which ensures that the system remains up to date.

Before the upgrade, we recommend that you understand the upgrade risks and create a snapshot to back up data. This lets you quickly recover data if the upgrade fails.

Use the root user to remotely connect to the ECS instance that runs the RHEL system.

For more information, see Connect to a Linux instance using Workbench.

Check whether your RHEL instance uses an Alibaba Cloud RHEL subscription.

rpm -qa |grep aliyun

• If no response is returned, your system does not use an Alibaba Cloud RHEL subscription. You must first purchase a subscription before you perform the upgrade.

• If you receive a response that contains a minor version, such as rhel8.6, you must first submit a ticket to obtain and install the latest RPM package before you execute the upgrade.

  

  Note

  When you run RHEL on Alibaba Cloud, the system accesses Red Hat software repositories through Alibaba Cloud's Red Hat Update Infrastructure (RHUI) service. If a package for a specific minor version, such as aliyun_rhel8.6-2.0-1.noarch, is installed, the system may fail to connect to RHUI. This failure prevents you from obtaining software updates or upgrading to a new version.

• If a response for a subscription package similar to aliyun_rhui_rhel8-2.0-3.x86_64 is returned, your system uses an Alibaba Cloud RHEL subscription. You can proceed with the upgrade.

  

Prepare the upgrade environment.

1. Upgrade the RHEL system to the latest version. The latest version usually contains fixes for known vulnerabilities, errors, and security issues. Then, restart the system for the changes to take effect.

   yum -y update
   reboot

2. Install the Leapp upgrade tool on the RHEL system.

   yum -y install leapp leapp-rhui-alibaba --enablerepo="*"

3. Check whether Leapp is installed.

   leapp --version

   If a response similar to leapp version xxx is returned, Leapp is installed.

Perform a pre-upgrade check.

Because system configurations can vary significantly, you must use the Leapp tool to perform a pre-upgrade check on the system before the upgrade. You can view the check results from the Leapp tool and resolve any reported issues based on the tool's suggestions to meet the upgrade requirements.

1. Perform a pre-upgrade check.

   • systemctl stop systemd-resolved
     systemctl disable  systemd-resolved

   • Pre-upgrade to the latest version of RHEL 9.

     leapp preupgrade  --no-rhsm

   • Pre-upgrade to a specific target version. For example, upgrade RHEL 8 to RHEL 9.4.

     leapp preupgrade --no-rhsm --target 9.4

     Note

     You can run the leapp preupgrade -h command to view the target versions that the current system supports for an upgrade.

2. View the pre-upgrade check results.

   The pre-upgrade check logs from the Leapp tool are saved in the following log files:

   • /var/log/leapp/leapp-preupgrade.log: Leapp tool logs

   • /var/log/leapp/leapp-report.txt: Pre-upgrade check report in text format

   • /var/log/leapp/leapp-report.json: Pre-upgrade check report in JSON format

   If the pre-upgrade check fails, the failed check items are displayed, as shown in the following figure.

   

3. (Conditional) Handle pre-upgrade errors.

   Check the log file /var/log/leapp/leapp-report.txt for pre-upgrade error messages and resolve the errors based on the suggestions from the Leapp tool. The following section lists common pre-upgrade check errors and their solutions by risk level.

   • high: High risk. This type of issue does not directly block the upgrade, but we recommend that you resolve it before or after the upgrade to prevent issues after the upgrade.

     • Case 1: Custom Leapp actors or files were detected.

       Risk Factor: high 
       Title: Detected custom leapp actors or files.
       Summary: We have detected installed custom actors or files on the system. These can be provided e.g. by third party vendors, Red Hat consultants, or can be created by users to customize the upgrade (e.g. to migrate custom applications). This is allowed and appreciated. However Red Hat is not responsible for any issues caused by these custom leapp actors. Note that upgrade tooling is under agile development which could require more frequent update of custom actors.
       The list of custom leapp actors and files:
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/content.crt
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/key.pem
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/leapp-alibaba.repo
       Related links:
           - Customizing your Red Hat Enterprise Linux in-place upgrade: https://red.ht/customize-rhel-upgrade
       Remediation: [hint] In case of any issues connected to custom or third party actors, contact vendor of such actors. Also we suggest to ensure the installed custom leapp actors are up to date, compatible with the installed packages.

       Solution: Ensure that the custom actors are up to date and compatible with the Leapp tool and the system environment. After the upgrade, verify that the system runs correctly and promptly resolve any issues caused by the custom actors. For more information about how to manage custom actors, see Customizing your Red Hat Enterprise Linux in-place upgrade.

     • Case 2: The GRUB2 configuration will be automatically updated during the upgrade.

       Risk Factor: high 
       Title: GRUB2 core will be automatically updated during the upgrade
       Summary: On legacy (BIOS) systems, GRUB2 core (located in the gap between the MBR and the first partition) cannot be updated during the rpm transaction and Leapp has to initiate the update running "grub2-install" after the transaction. No action is needed before the upgrade. After the upgrade, it is recommended to check the GRUB configuration.

       Solution: After the upgrade, check the GRUB configuration to ensure that the system starts correctly.

   • low: Low risk. This type of issue has a minor impact on the upgrade process or system operation, but we recommend that you resolve it before or after the upgrade to ensure stable system operation.

     Case: SELinux will be set to permissive mode.

     Risk Factor: low 
     Title: SElinux will be set to permissive mode
     Summary: SElinux will be set to permissive mode. Current mode: enforcing. This action is required by the upgrade process to make sure the upgraded system can boot without beinig blocked by SElinux rules.
     Remediation: [hint] Make sure there are no SElinux related warnings after the upgrade and enable SElinux manually afterwards. Notice: You can ignore the "/root/tmp_leapp_py3" SElinux warnings.

     Solution: After the upgrade, make sure that there are no SELinux-related warnings, and then reset SELinux to enforcing mode to ensure system security and compliance.

   • info: Informational. This type of issue is usually an informational message and does not affect the upgrade process or system operation. You can view the specific messages in the report to understand the changes that will occur during the upgrade process.

     Case: Some target system repositories are excluded.

     Risk Factor: info 
     Title: Excluded target system repositories
     Summary: The following repositories are not supported by Red Hat and are excluded from the list of repositories used during the upgrade.
     - rhui-codeready-builder-for-rhel-9-aarch64-rhui-rpms
     - codeready-builder-for-rhel-9-aarch64-rpms
     - codeready-builder-for-rhel-9-s390x-rpms
     - codeready-builder-beta-for-rhel-9-ppc64le-rpms
     - codeready-builder-for-rhel-9-x86_64-rpms
     Remediation: [hint] If some of excluded repositories are still required to be used during the upgrade, execute leapp with the --enablerepo option with the repoid of the repository required to be enabled as an argument (the option can be used multiple times).

     Solution: If some of the excluded repositories still need to be enabled during the upgrade process, you can use the --enablerepo option to enable them.

Perform the upgrade.

• Upgrade to the latest version of RHEL 9.

  leapp upgrade  --no-rhsm

• Upgrade to a specific target version. For example, upgrade RHEL 8 to RHEL 9.4.

  leapp upgrade  --no-rhsm --target 9.4

The following figure indicates that the upgrade is successful.

Restart the instance and boot into the new system.

reboot

Verify the upgrade result.

• Run the cat /etc/redhat-release command to check whether the system version is updated.

• Check the upgrade execution logs or reports for any errors.

• Observe whether your business runs correctly on the RHEL 9 system.

(Conditional) Run the following commands to configure the RHEL source.

After you use the Leapp upgrade tool to complete the upgrade, the /etc/dnf/vars/releasever file is modified by default to lock the system to a specific minor version of RHEL. For example, for RHEL 9.4, the repository source points to https://xxxx/9.4/xxx, so you can only access packages for the RHEL 9.4 version. If you want to automatically access the packages of the latest RHEL 9 version to obtain the latest security patches and feature updates, you can delete the releasever configuration file and rebuild the DNF cache.

rm -f /etc/dnf/vars/releasever
dnf clean all && dnf makecache

After the command is run, the repository source for RHEL 9 is updated to https://xxxx/9/xxx. The system can then automatically obtain the latest security patches and feature updates for RHEL 9, which ensures that the system remains up to date.