Upgrading SAP environments from RHEL 7 to RHEL 8


Red Hat Enterprise Linux for SAP Solutions 8

Red Hat Customer Content Services

Abstract

This document provides instructions on how to perform an in-place upgrade of SAP environments from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 using the Leapp utility. During the in-place upgrade, the existing RHEL 7 operating system is replaced by a RHEL 8 version.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.

Providing feedback on Red Hat documentation

We appreciate your feedback on our documentation. Let us know how we can improve it.

Submitting feedback through Jira (account required)

  1. Make sure you are logged in to the Jira website.
  2. Click on this link to provide feedback.
  3. Enter a descriptive title in the Summary field.
  4. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
  5. Click Create at the bottom of the dialogue.

Chapter 1. Supported upgrade paths

Currently, you can perform an in-place upgrade from RHEL 7.9 to 8.10. This applies both for RHEL systems with SAP HANA and RHEL systems with SAP NetWeaver and other SAP applications.

SAP validates SAP HANA for RHEL minor versions, which are getting package updates for longer than six months. Therefore, for the SAP HANA hosts, the upgrade paths include only EUS/E4S releases plus the last minor release for a given major release.
Upgrading an SAP HANA system describes restrictions and detailed steps for upgrading a SAP HANA system.

SAP validates SAP NetWeaver for each major RHEL version. For cloud providers, an upgrade of systems with SAP NetWeaver and other SAP applications is supported for EUS/E4S releases and the last minor release for a given major release. For on-promise deployments with SAP NetWeaver and other SAP applications, you can upgrade to any minor release.
Upgrading an SAP NetWeaver system describes certain deviations from the default upgrade procedure.

For systems on which both SAP HANA and SAP NetWeaver are installed, the SAP HANA restrictions apply.

For more information about supported upgrade paths, see the Supported in-place upgrade paths for Red Hat Enterprise Linux Knowledgebase article.

Chapter 2. Planning an upgrade

An in-place upgrade is the recommended and supported way to upgrade your SAP HANA system to the next major version of RHEL.
Consider the following before upgrading to RHEL 8:

  • Operating system:

    • SAP HANA is installed with a version that is supported on both the source and target RHEL minor versions.
    • SAP HANA is installed using the default installation path of /hana/shared.
  • Public clouds:

    • The in-place upgrade is supported for on-demand Pay-As-You-Go (PAYG) instances on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform with Red Hat Update Infrastructure (RHUI). The in-place upgrade is also supported for Bring Your Own Subscription (BYOS) instances on all public clouds that use Red Hat Subscription Manager (RHSM) for a RHEL subscription.
  • SAP HANA and Netweaver requirements:

    • SAP HANA hosts must meet all of the following criteria:

      • Running on x86_64 architecture that is certified by the hardware partner or CCSP for SAP HANA on the source and target OS versions.
      • Running on physical infrastructure or in a virtual environment.
      • Using the Red Hat Enterprise Linux for SAP Solutions subscription.
      • Not using Red Hat HA Solutions for SAP HANA.
    • SAP NetWeaver hosts must meet the following criteria:

      • Using the Red Hat Enterprise Linux for SAP Solutions or Red Hat Enterprise Linux for SAP Applications subscription
  • High Availability: If you use the High Availability add-on, see the Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster Knowledgebase article.

Chapter 3. Upgrading an SAP HANA system

An SAP HANA system running on RHEL 7.7 or earlier must be updated to RHEL 7.9 first. For special instructions on how to upgrade from RHEL 7.7 or earlier to RHEL 7.9 on cloud providers, see the How to Perform Update of RHEL for SAP with HA from 7.* to 7.9 on Cloud Providers Knowledgebase article.

If the installed SAP HANA version is not on the minimum revision, which is supported on both the source and target RHEL minor versions, your SAP HANA software must be upgraded to this level first. SAP HANA must have been installed using /hana/shared as the installation path.

Never perform more than one update or upgrade (for example, HANA to 2.0 SPS05 rev 59.04 and RHEL from 7.7 to 7.9) without sufficient testing and verification after each step. Otherwise, solving any problem might get very complex and take a long time.

Prepare for the verification of your SAP HANA system so that you can quickly check and confirm if your SAP HANA system is fully operational again after the upgrade to RHEL 8.10. This should include functional as well as performance testing of your most important business transactions.

On production systems, perform all the following steps, including the preparation and pre-upgrade steps, on a test system first to verify that you can finish the upgrade successfully in your environment.

3.1. Step 1: Preparing for the upgrade

You must prepare the system before performing an in-place upgrade to RHEL 8.

Important

At any time before you perform the actual in-place upgrade, create a full system backup or virtual machine snapshot and perform a restore test to ensure that you can get back to a working system quickly.

The instructions in this chapter correspond to the Preparing for the upgrade section in the Upgrading from RHEL 7 to RHEL 8 document.

Prerequisites

  • Ensure that your system has access to the required repositories and completes a system-specific setup.

Procedure

  1. Complete system-specific setup.

    1. Preparing non-cloud or BYOS cloud systems

      1. Register and subscribe the system to a Red Hat repository source. If you use Red Hat Satellite, make sure that both RHEL 7 and RHEL 8 repositories are available and synchronized with the latest updates. Enable the following repos for the activation key:

        rhel-7-server-rpms
        rhel-sap-for-rhel-7-server-rpms
        rhel-sap-hana-for-rhel-7-server-rpms
        rhel-7-server-extras-rpms
        rhel-8-for-x86_64-baseos-rpms
        rhel-8-for-x86_64-appstream-rpms
        rhel-8-for-x86_64-sap-netweaver-rpms
        rhel-8-for-x86_64-sap-solutions-rpms
        Copy to Clipboard Toggle word wrap
      2. Check and confirm that your RHEL 7.9 system has the normal repositories enabled. Also, enable the rhel-7-server-extras-rpms repository, which contains the required upgrade tools:

        # subscription-manager repos --disable='*' \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-sap-hana-for-rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms"
        Copy to Clipboard Toggle word wrap

        If you are also using the SAP NetWeaver repository (rhel-sap-for-rhel-7-server-rpms), enable that one as well:

        # subscription-manager repos --disable='*' \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-sap-for-rhel-7-server-rpms" \
        --enable="rhel-sap-hana-for-rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms"
        Copy to Clipboard Toggle word wrap
        Note

        There are no e4s or eus repositories available for RHEL 7.9 and RHEL 8.10. Those are only required and available for RHEL minor versions prior to the final RHEL minor version. For more information, refer to this section in the Red Hat Enterprise Linux Life Cycle web page.

      3. Remove all files cached by yum/dnf:

        # rm -rf /var/cache/yum
        Copy to Clipboard Toggle word wrap
      4. Make sure no RHEL release lock is set:

        # subscription-manager release --unset
        Copy to Clipboard Toggle word wrap

        Release preference has been unset.

        Note

        A release lock instructs yum to access packages from e4s or eus repositories, which fails on RHEL 7.9 because there are no such repositories on RHEL 7.9.

    2. Preparing PAYG cloud instances on AWS

      1. Install the leapp-rhui-aws-sap-e4s package:

        # yum install leapp-rhui-aws-sap-e4s
        Copy to Clipboard Toggle word wrap
      2. Enable the rhel-7-server-rhui-extras-rpms repository:

        # yum-config-manager --enable rhel-7-server-rhui-extras-rpms
        Copy to Clipboard Toggle word wrap
    3. Preparing PAYG cloud instances on Google Cloud

      1. Download and install the leapp-rhui-google-v1-rhel7-sap package, as instructed in Leapp RHUI packages for Google Cloud Platform (GCP).
      2. Enable the rhui-rhel-7-server-rhui-extras-rpms repository:

        # yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
        Copy to Clipboard Toggle word wrap
    4. Preparing PAYG cloud instances on Microsoft Azure

      1. Install the leapp-rhui-azure-sap package:

        # yum install leapp-rhui-azure-sap
        Copy to Clipboard Toggle word wrap
      2. Enable the rhui-rhel-7-server-rhui-extras-rpms repository:

        # yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
        Copy to Clipboard Toggle word wrap
  2. Completing the non-system-specific setup

    After completing the above steps, perform the remaining steps on all systems, no matter if your system is a non-cloud, BYOS cloud, or PAYG cloud system on AWS, Google Cloud, or Microsoft Azure.

    1. Stop the SAP HANA system(s) and stop all SAP processes.

      Important

      Do not unmount the SAP HANA file systems, as these are required for detecting if SAP HANA is installed and the version of the installed system.

    2. If your system is configured to start SAP processes automatically at boot time, disable the automatic start of SAP processes.
    3. Configure RHEL settings for SAP HANA:

      1. The SAP HANA installer in SAP HANA 2.0 SPS05 configures kernel settings in file /etc/sysctl.conf. Leave these settings in place.
      2. Additional settings recommended for SAP HANA as per SAP notes 2382421 and 2292690 are configured using the sap.conf and sap_hana.conf files in the /etc/sysctl.d directory. Settings in sap_hana.conf are valid for both RHEL 7 and RHEL 8, whereas the value for kernel.sem in sap.conf on RHEL 7 is lower than the default value on RHEL 8. Because of this, remove the line that sets kernel.sem to 1250 256000 100 1024 from /etc/sysctl.d/sap.conf. The value for vm.max_map_count is again valid for both RHEL 7 and RHEL 8, so leave this setting in place.
    4. Update your RHEL 7.9 system to the latest RHEL 7 package levels:

      # yum update
      Copy to Clipboard Toggle word wrap
    5. Reboot the system:

      # reboot
      Copy to Clipboard Toggle word wrap
    6. After the system is up and running, check and confirm that no SAP HANA systems and no SAP processes are running on the system.
    7. Make sure the SAP HANA file systems are available.
    8. Install the leapp utility:

      # yum install leapp-upgrade
      Copy to Clipboard Toggle word wrap
    9. Ensure there is no configuration management system (such as Salt, Chef, Puppet, Ansible) enabled or configured to attempt to restore the original RHEL 7 system.
    10. Ensure your system does not use any Network Interface Card (NIC) with a name based on the prefix 'eth'.
    11. Make sure that you have a full backup or a virtual machine snapshot of your system.
    12. If not done already, perform a restore test of the backup to another system, to make sure that the backup can be used for a successful restore. A restore test is also useful for getting used to the required restore activities so that you can get a working system back as quickly as possible, if necessary.

3.2. Step 2: Reviewing the pre-upgrade report

The pre-upgrade process (the leapp preupgrade command) assesses your system for any potential problems you might encounter with the RHEL 7 to RHEL 8 upgrade before any changes to your system are made. This helps you determine your chances of successfully upgrading to RHEL 8.10 before the actual upgrade process begins.

Important

Run the leapp preupgrade command multiple times if necessary to address anything that could cause problems before running the actual upgrade. The leapp preupgrade command does not perform any changes to your installed system. However, once you perform an in-place upgrade on your system, the only way to get the previous system back is from a backup or snapshot that was performed before the upgrade.

The instructions in this chapter correspond to the Reviewing the pre-upgrade report chapter in the Upgrading from RHEL 7 to RHEL 8 document.

Procedure

  1. Perform the pre-upgrade assessment:

    • On a non-cloud or BYOS cloud system, run:

      # leapp preupgrade --target 8.10
      Copy to Clipboard Toggle word wrap
    • On a PAYG cloud instance on AWS, Google Cloud, or Microsoft Azure, run:

      # leapp preupgrade --no-rhsm --target 8.10
      Copy to Clipboard Toggle word wrap
Note

The --channel e4s option is not used if you upgrade to RHEL 8.10. RHEL 8.10 is the final minor release of RHEL 8, it is not E4S release, and its support cycle differs. For more information, see Red Hat Enterprise Linux Life Cycle Customer Portal article.

  1. In many cases, the following inhibitors are reported:

    • Inhibitor: Detected loaded kernel drivers that have been removed in RHEL 8. Upgrade cannot proceed.
    • Inhibitor: Possible problems with remote login using a root account.
    • Inhibitor: Missing required answers in the answer file.

      The report in file /var/log/leapp/leapp-report.txt contains all necessary information, including remediation steps, to resolve these inhibitors.

  2. In the case of non-cloud or BYOS cloud systems, if the message Unable to use yum successfully is reported in step target_userspace_creator and the preupgrade is aborted, this typically indicates that not all required RHEL 7 and RHEL 8 repositories are available with your activation key. To solve this problem, configure your activation key to enable all required repos as per step 1.1.a.i or re-register your system to use an activation key that has all required repositories enabled.
  3. Manually resolve all the reported problems before proceeding with the in-place upgrade. As mentioned before, you can repeat this step as often as necessary until no more inhibitors are reported.

3.3. Step 3: Performing the upgrade

With the pre-upgrade assessment completed and all issues addressed, the next step is to perform the actual system upgrade. Start the upgrade process by entering the leapp upgrade command.

The instructions in this chapter correspond to the Performing the upgrade from RHEL 7 to RHEL 8 chapter in the Upgrading from RHEL 7 to RHEL 8 document.

Procedure

  1. Before performing the upgrade, back up all of your data to avoid potential data loss if you have not already done so.
  2. Perform a restore test to verify that the last backup was successful.
  3. Check and confirm again that no SAP HANA system and no SAP processes are running on the system.
  4. Check and confirm that your SAP HANA system are not be started automatically at boot time. For more information, refer to SAP note 2315907 - Starting HANA automatically after Host has been started.
  5. Check and confirm that the SAP HANA file systems are mounted, as a certain file located below this path is used by Leapp to detect whether the upgraded system is running SAP HANA or not, to assert related inhibitors.
  6. Run the upgrade process:

    • On a non-cloud or BYOS cloud system, enter:

      # leapp upgrade --target 8.10
      Copy to Clipboard Toggle word wrap
    • On a PAYG cloud instance on AWS, Google Cloud, or Microsoft Azure, enter:

      # leapp upgrade --no-rhsm --target 8.10
      Copy to Clipboard Toggle word wrap
      Note

      Do not use the --channel e4s option if you upgrade to RHEL 8.10, as it is the final minor release of RHEL 8, it is not E4S release, and its support cycle differs. For more information, see the Red Hat Enterprise Linux Life Cycle Customer Portal article.

  7. After the system completes the previous command, it displays a message that asks you to reboot the system. Restart the system so that it can finish the upgrade:

    # reboot
    Copy to Clipboard Toggle word wrap
  8. The system boots into a RHEL 8-based initial RAM disk image (initramfs), upgrades all packages, and reboots again. This might take some time. Once all packages have been upgraded, the system automatically starts the RHEL 8 system.

3.4. Step 4: Verifying the post-upgrade state

Verify that the upgrade was successful.

The instructions in this chapter correspond to the Verifying the post-upgrade state of the RHEL 8 system chapter in the Upgrading from RHEL 7 to RHEL 8 document.

Procedure

  1. Verify that the current OS version is Red Hat Enterprise Linux 8:

    # cat /etc/redhat-release
    Red Hat Enterprise Linux release 8.10 (Ootpa)
    Copy to Clipboard Toggle word wrap
  2. Check the OS kernel version. Note that `.el8 is essential. For example, for RHEL 8.10, it is 4.18.0-553.34.1.el8 or later:

    # uname -r
    4.18.0-553.34.1.el8
    Copy to Clipboard Toggle word wrap

    The Red Hat Enterprise Linux Release Dates Knowledgebase article helps you match the kernel version with a particular RHEL release.

  3. Make sure no RHEL release lock is set.

    Note

    A release lock instructs yum to access packages from e4s or eus repositories, which fails on RHEL 8.10 because there are no such repositories on RHEL 8.10.

    • On a non-cloud or BYOS cloud system, run:

      # subscription-manager release --unset
      Copy to Clipboard Toggle word wrap

      Release preference has been unset.

    • On a PAYG cloud instance on AWS, Google Cloud, or Azure remove a file if it exists:

      # cat /etc/yum/vars/releasever
      <target_os_version>
      # rm /etc/yum/vars/releasever
      Copy to Clipboard Toggle word wrap
  4. Verify that the system has all necessary repositories enabled:

    # yum repolist
    Copy to Clipboard Toggle word wrap
    • On a non-cloud or BYOS cloud system, the output should contain:

      rhel-8-for-x86_64-appstream-rpms
      rhel-8-for-x86_64-baseos-rpms
      rhel-8-for-x86_64-sap-netweaver-rpms
      rhel-8-for-x86_64-sap-solutions-rpms
      Copy to Clipboard Toggle word wrap
    • On a PAYG cloud instance on AWS, the output should contain:

      rhel-8-for-x86_64-appstream-rhui-rpms
      rhel-8-for-x86_64-baseos-rhui-rpms
      rhel-8-for-x86_64-highavailability-rhui-rpms
      rhel-8-for-x86_64-sap-netweaver-rhui-rpms
      rhel-8-for-x86_64-sap-solutions-rhui-rpms
      Copy to Clipboard Toggle word wrap
    • On a PAYG cloud instance on Google Cloud, the output should contain:

      rhui-rhel-8-for-x86_64-appstream-rhui-rpms
      rhui-rhel-8-for-x86_64-baseos-rhui-rpms
      rhui-rhel-8-for-x86_64-highavailability-rhui-rpms
      rhui-rhel-8-for-x86_64-sap-netweaver-rhui-rpms
      rhui-rhel-8-for-x86_64-sap-solutions-rhui-rpms
      Copy to Clipboard Toggle word wrap
      Note

      Google Cloud RHEL 7 images have the EPEL repository included. RHEL 8 images do not. Therefore, after the upgrade, you can see an error message as follows:

      $ yum repolist
      Invalid configuration value: failovermethod=priority in /etc/yum.repos.d/epel.repo; Configuration: OptionBinding with id "failovermethod" does not exist
      Copy to Clipboard Toggle word wrap

      In this case, remove the EPEL repo(s):

      $ rm -f /etc/yum.repos.d/epel*.repo
      Copy to Clipboard Toggle word wrap
    • On a PAYG cloud instance on Microsoft Azure, the output should contain:

      rhel-8-for-x86_64-appstream-rhui-rpms
      rhel-8-for-x86_64-baseos-rhui-rpms
      rhel-8-for-x86_64-highavailability-rhui-rpms
      rhel-8-for-x86_64-sap-netweaver-rhui-rpms
      rhel-8-for-x86_64-sap-solutions-rhui-rpms
      Copy to Clipboard Toggle word wrap
      Note

      On Cloud Providers, the repolist may contain other non-Red Hat repositories, for example, custom repositories for RHUI configuration.

  5. Verify that network services are operational. For example, try to connect to the system by using the ssh command.

3.5. Step 5: Performing post-upgrade tasks

Perform additional steps after you have verified the upgrade. Follow the instructions in the Performing post-upgrade tasks chapter of the Upgrading from RHEL 7 to RHEL 8 document.

3.6. Step 6: Configuring the system for SAP HANA

Configure your upgraded system according to applicable SAP notes for SAP HANA on RHEL 8.

After you have verified that the upgrade was successful, you must configure the system for SAP HANA according to the applicable SAP notes for RHEL 8.

Procedure

  1. If you have configured your RHEL 7.9 system for SAP HANA using the RHEL System Roles for SAP (the rhel-system-roles-sap package, the sap_general_preconfigure and sap_hana_preconfigure roles) and if you have not made any additional modifications to your system configuration afterwards, you can configure your system with the RHEL System Roles for SAP again.

    Note

    To verify that your system is configured according to the applicable SAP notes, you can run RHEL system roles sap_general_preconfigure and sap_hana_preconfigure in assert mode.

  2. If you want to configure your system manually, the following steps are required:

    1. SAP note 2772999: Install package group server:

      # dnf group install server
      Copy to Clipboard Toggle word wrap
    2. SAP note 2772999: Install package libibverbs:

      # dnf install libibverbs
      Copy to Clipboard Toggle word wrap
    3. SAP note 2777782: Disable service abrt-ccpp:

      # systemctl disable abrt-ccpp --now
      Copy to Clipboard Toggle word wrap
      Note

      SAP note 2772999 version 17 and SAP note 2777782 version 23 recommend setting kernel.pid_max in the /etc/sysctl.d/sap.conf file to 4194304. As the default for this kernel parameter in RHEL 8.2 and later is already 4194304, there is no need to set this kernel parameter again.

      After modifying your system configuration as described, reboot your system.

3.7. Step 7: Applying security policies

If your RHEL 7.9 system had certain security policies configured, you should apply these or similar security policies again after the upgrade. A RHEL 7.9 system with SELinux set to disabled will remain on this status after the upgrade to RHEL 8.10. A RHEL 7.9 system with SELinux set to enforcing will be set to permissive during the upgrade, and you have to manually change it to enforcing after the upgrade.

For security-related topics, see the Applying security policies chapter in the Upgrading from RHEL 7 to RHEL 8 document.

3.8. Step 8: Verifying your SAP HANA system

Verify that your SAP HANA system is operational again.

After you have configured your RHEL 8.10 system for SAP HANA, you can start your SAP HANA software and run any necessary verification steps to ensure that your SAP HANA system is fully operational again. As mentioned before, this should include functional as well as performance testing of your most important business transactions.

Chapter 4. Upgrading an SAP NetWeaver system

Follow the Upgrading from RHEL 7 to RHEL 8 guide to upgrade your SAP NetWeaver non-cloud or BYOS cloud RHEL 7.9 system to RHEL 8.10, with the following additional steps:

  1. At the end of the Preparing a RHEL 7 system for the upgrade procedure, remove the line containing kernel.sem from the /etc/sysctl.d/sap.conf file.
  2. At the end of the 6. Verifying the post-upgrade state of the RHEL 8 system procedure, verify that the value of kernel.pid_max is 4194304 according to SAP note 2772999:

    # sysctl kernel.pid_max
    Copy to Clipboard Toggle word wrap

    If this is not the case, add the following line to file /etc/sysctl.d/sap.conf:

    kernel.pid_max = 4194304
    Copy to Clipboard Toggle word wrap

    Save the changes, and reload the file:

    # sysctl -p /etc/sysctl.d/sap.conf
    Copy to Clipboard Toggle word wrap

    You can run the sap_general_preconfigure and sap_netweaver_preconfigure roles in assert mode to verify if your system is compliant with the SAP notes requirements. These roles are part of the RHEL package RHEL System Roles for SAP or the Ansible collection redhat.sap_install.

The upgrade of SAP NetWeaver or other SAP application systems hosted on cloud provider PAYG instances is very similar to the upgrade of SAP HANA systems hosted on cloud provider PAYG instances. All non-HANA-specific steps listed in the SAP HANA systems upgrade on cloud provider PAYG instances procedure should be applied to complete the upgrade of SAP NetWeaver or other SAP application systems hosted on cloud provider PAYG instances.

After the upgrade, the system has the following Red Hat repositories:

$ yum repolist
rhel-8-for-x86_64-appstream-rhui-rpms
rhel-8-for-x86_64-baseos-rhui-rpms
rhel-8-for-x86_64-sap-netweaver-rhui-rpms
Copy to Clipboard Toggle word wrap

The list may contain other non-Red Hat repositories, namely, custom repositories of cloud providers for RHUI configuration.

Note

Do not use --channel option if you upgrade to RHEL 8.10, as it is the final minor release of RHEL 8, it is not E4S/EUS release, and its support cycle differs. For more information, see the Red Hat Enterprise Linux Life Cycle Customer Portal article.

The rhel-8-for-x86_64-sap-solutions-rhui-rpms repository should not be present on RHEL for SAP Applications instances, as per the Red Hat Enterprise Linux for SAP Offerings on Microsoft Azure FAQ Knowledgebase article. At some point, it will be removed by Microsoft Azure (RHUI client rpm automatic update) and does not require any action from users. If the automatic RHUI client rpm update has been disabled on your system, for example, by removing the corresponding cron job, you can update the RHUI client RPM package by yum update <package_name>.

The in-place upgrade of RHEL 7 with SAP NetWeaver or other SAP applications hosted on cloud providers and using the Red Hat Enterprise Linux for SAP Solutions or Red Hat Enterprise Linux for SAP Applications subscription can be performed only from RHEL 7.9 with normal (non-e4s/eus/…​) repositories. RHEL 7.7 or earlier must be updated to RHEL 7.9 first. For special instructions on how to upgrade from RHEL 7.7 or earlier to RHEL 7.9 on cloud providers, refer to How to Perform Update of RHEL for SAP with HA from 7.* to 7.9 on Cloud Providers Knowledgebase article.

Perform all the upgrade steps, including the preparation and pre-upgrade steps, on a test system first until you have verified that the upgrade can be performed successfully in your production environment.

Chapter 5. Known Issues

If you upgrade VMs on Azure cloud launched from the "RHEL for SAP" (a discontinued offer) image of "gen1", and see an error similar to the following, ensure that the /etc/hosts file does not contain a line X.X.X.X rhui*.microsoft.com. This is an artifact IP address of Azure RHUI Content Distribution Server (CDS) instance to fetch the content from.

Error:

Stderr: Host and machine ids are equal (hash): refusing to link journals
            Failed to synchronize cache for repo 'rhel-8-for-x86_64-appstream-eus-rhui-rpms', ignoring this repo.
            Failed to synchronize cache for repo 'microsoft-azure-rhel8-sapapps', ignoring this repo.
            Error: Unable to find a match: rhui-azure-rhel8-sapapps
Copy to Clipboard Toggle word wrap

or

Stderr: Host and machine ids are equal (hash): refusing to link journals
            Failed to synchronize cache for repo 'rhel-8-for-x86_64-appstream-e4s-rhui-rpms', ignoring this repo.
            Failed to synchronize cache for repo 'microsoft-azure-rhel8-sap-ha', ignoring this repo.
            Error: Unable to find a match: rhui-azure-rhel8-sap-ha
Copy to Clipboard Toggle word wrap

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top