Elastic Compute Service:RHEL lifecycle and RHEL 7 Extended Life phase solutions

Back up data by creating a snapshot to prevent data loss if the upgrade fails. See Create a snapshot.

Log on to the ECS instance as the root user.

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. Purchase a subscription first, then 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. Proceed with the upgrade.

  

Prepare the upgrade environment.

1. Upgrade the RHEL system to the latest version and restart the system.

   yum -y update
   reboot

2. Install the Leapp upgrade tool.

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

3. Verify that Leapp is installed.

   leapp --version

   A response similar to leapp version xxx confirms Leapp is installed.

Perform a pre-upgrade check.

System configurations vary. Use the Leapp tool to run a pre-upgrade check and resolve any reported issues before upgrading.

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

     Run leapp preupgrade -h to view supported target versions.

2. View the pre-upgrade check results.

   Leapp pre-upgrade check logs:

   • /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 items are displayed:

   

3. (Conditional) Handle pre-upgrade errors.

   Check /var/log/leapp/leapp-report.txt for error messages and resolve them based on the Leapp tool's suggestions. Common errors by risk level:

   • high (inhibitor): Blocks the upgrade. Must be resolved before proceeding.

     • 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: Uninstall old kernel packages using the command suggested by Leapp, for example, yum -y remove kernel-devel-3.10.0-1160.11.1.el7.

     • 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. Uninstall them:

       rmmod floppy

     • Case 3: Non-standard 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 /etc/ssh/sshd_config, set PermitRootLogin to yes.

          Note

          PermitRootLogin defaults differ between RHEL 7 and RHEL 8:

          • RHEL 7: yes — root login allowed via password or key.

          • RHEL 8: prohibit-password — password-based root login is disabled.

       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: Delete the unsupported pam module. Confirm deletion in the /var/log/leapp/answerfile file by setting confirm to True:

       leapp answer --section remove_pam_pkcs11_module_check.confirm=True

       

   • high: Does not block the upgrade but must be resolved before or 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: Install the missing packages manually 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: Remove these packages: 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

   • medium: Does not block the upgrade but should be resolved to prevent potential issues.

     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: Configure SSSD to replace the functionality of pam_pkcs11 to ensure authentication works correctly after the upgrade.

   • low: Minor impact. Should be resolved to ensure stable 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, verify no SELinux-related warnings exist, then reset SELinux to enforcing mode.

   • info: Informational. No action required. Review the report to understand changes during the upgrade.

     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

     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

A successful upgrade looks like this:

Restart the instance to 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 application runs correctly on the RHEL 8 system.

(Conditional) Configure the RHEL source.

After the Leapp upgrade, the /etc/dnf/vars/releasever file locks the system to a specific minor version. For example, RHEL 8.8 points to https://xxxx/8.8/xxx. To access the latest RHEL 8 packages, delete the releasever file and rebuild the metadata cache.

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

The repository source updates to https://xxxx/8/xxx, enabling automatic access to the latest RHEL 8 security patches and feature updates.

Back up data by creating a snapshot to prevent data loss if the upgrade fails. See Create a snapshot.

Log on to the ECS instance as the root user.

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. Purchase a subscription first, then perform the upgrade.

• If the response contains a minor version, such as rhel8.6, submit a ticket to obtain the latest RPM package, install it, then perform the upgrade.

  

  Note

  When running RHEL on Alibaba Cloud, the system accesses Red Hat software repositories through Alibaba Cloud's RHUI service. A minor-version-specific package, such as aliyun_rhel8.6-2.0-1.noarch, may prevent RHUI connections, blocking software updates and upgrades.

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

  

Prepare the upgrade environment.

1. Upgrade the RHEL system to the latest version and restart the system.

   yum -y update
   reboot

2. Install the Leapp upgrade tool.

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

3. Verify that Leapp is installed.

   leapp --version

   A response similar to leapp version xxx confirms Leapp is installed.

Perform a pre-upgrade check.

System configurations vary. Use the Leapp tool to run a pre-upgrade check and resolve any reported issues before upgrading.

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

     Run leapp preupgrade -h to view supported target versions.

2. View the pre-upgrade check results.

   Leapp pre-upgrade check logs:

   • /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 items are displayed:

   

3. (Conditional) Handle pre-upgrade errors.

   Check /var/log/leapp/leapp-report.txt for error messages and resolve them based on the Leapp tool's suggestions. Common errors by risk level:

   • high: Does not block the upgrade but must be resolved before or 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 custom actors are up to date and compatible with the Leapp tool. After the upgrade, verify system operation. 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 the system starts correctly.

   • low: Minor impact. Should be resolved to ensure stable operation.

     Case: SELinux is 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, verify no SELinux-related warnings exist, then reset SELinux to enforcing mode.

   • info: Informational. No action required. Review the report to understand changes during the upgrade.

     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: To enable excluded repositories during the upgrade, use the --enablerepo option.

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

A successful upgrade looks like this:

Restart the instance to 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 application runs correctly on the RHEL 9 system.

(Conditional) Configure the RHEL source.

After the Leapp upgrade, the /etc/dnf/vars/releasever file locks the system to a specific minor version. For example, RHEL 9.4 points to https://xxxx/9.4/xxx. To access the latest RHEL 9 packages, delete the releasever file and rebuild the metadata cache.

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

The repository source updates to https://xxxx/9/xxx, enabling automatic access to the latest RHEL 9 security patches and feature updates.