Questo contenuto non è disponibile nella lingua selezionata.

Chapter 3. Preparing for the upgrade


To prevent issues after the upgrade and to ensure that your system is ready to be upgraded to the next major version of RHEL, complete all necessary preparation steps before upgrading.

You must perform the preparation steps described in Preparing a RHEL 8 system for the upgrade on all systems. In addition, on systems that are registered to Satellite Server, you must also perform the preparation steps described in Preparing a Satellite-registered system for the upgrade.

3.1. Preparing a RHEL 8 system for the upgrade

This procedure describes the steps that are necessary before performing an in-place upgrade to RHEL 9 by using the Leapp utility.

If you do not plan to use Red Hat Subscription Manager (RHSM) during the upgrade process, follow instructions in Upgrading to RHEL 9 without Red Hat Subscription Manager.

Prerequisites

  • The system meets conditions listed in Planning an upgrade.
  • If the system has been previously upgraded from RHEL 7 to RHEL 8, ensure that all required post-upgrade steps have been completed. For more information, see Performing post-upgrade tasks in the Upgrading from RHEL 7 to RHEL 8 guide.

Procedure

  1. Optional: Review the best practices in The best practices and recommendations for performing RHEL Upgrade using Leapp Knowledgebase article.
  2. Ensure your system has been successfully registered to the Red Hat Content Delivery Network (CDN) or Red Hat Satellite by using the Red Hat Subscription Manager.
  3. If you have registered your system to Satellite Server, complete the steps in Preparing a Satellite-registered system for the upgrade to ensure that your system meets the requirements for the upgrade.

    Important

    If your system is registered to Satellite Server, you must complete the steps in Preparing a Satellite-registered system for the upgrade for the upgrade before proceeding with the steps in this procedure to prevent issues from occurring.

  4. Optional: Unmount non-system OS file systems that are not required for the upgrade, such as file systems containing only data files unrelated to the system itself, and comment them out from the /etc/fstab file. This can reduce the amount of time needed for the upgrade process and prevent potential issues related to third-party applications that are not migrated properly during the upgrade by custom or third-party actors.
  5. Verify that the system is subscribed using subscription-manager:

    1. If your system is registered by using an account with Simple Content Access (SCA) enabled, verify that the Content Access Mode is set to Simple Content Access message appears:

      # subscription-manager status
      +-------------------------------------------+
         System Status Details
      +-------------------------------------------+
      Overall Status: Disabled
      Content Access Mode is set to Simple Content Access. This host has access to content, regardless of subscription status.
      System Purpose Status: Disabled
    2. If your system is registered by using an account with SCA disabled, verify that the Red Hat Linux Server subscription is attached, the product name is Server, and the status is Subscribed. For example:

      # subscription-manager list --installed
      +-------------------------------------------+
          	  Installed Product Status
      +-------------------------------------------+
      Product Name:   Red Hat Enterprise Linux for x86_64
      Product ID:     479
      Version:        8.10
      Arch:           x86_64
      Status:         Subscribed
  6. Ensure you have appropriate repositories enabled. The following command enables the Base and AppStream repositories for the 64-bit Intel architecture; for other architectures, see RHEL 8 repositories.

    # subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms --enable rhel-8-for-x86_64-appstream-rpms
    Note

    Optionally, you can enable the CodeReady Linux Builder (also known as Optional) or Supplementary repositories. For more information about repository IDs, see RHEL 8 repositories. For more information about the content of these repositories, see the Package manifest.

  7. Set the system release version:

    1. For systems subscribed using RHSM, lock the system to the source OS version:

      # subscription-manager release --set 8.10
    2. If you are upgrading by using Red Hat Update Infrastructure (RHUI) on a public cloud, set the expected system release version manually:

      # rhui-set-release --set 8.10
      Important

      If the rhui-set-release command is not available on your system, you can set the expected system release version by updating the /etc/dnf/vars/release file:

      # echo "8.10" > /etc/dnf/vars/releasever
  8. Optional: To use custom repositories, see the Configuring custom repositories Knowledgebase article.
  9. If you use the dnf versionlock plugin to lock packages to a specific version, clear the lock by running:

    # dnf versionlock clear

    For more information, see the Red Hat Knowledgebase solution How to restrict dnf to install or upgrade a package to a fixed specific package version?.

  10. If you performed an in-place upgrade from RHEL 7 to RHEL 8, ensure that there are no leftover upgrade-related files before you begin installing leapp-upgrade packages:

    # rm -rf /usr/share/leapp-repository/repositories
  11. If you are upgrading by using Red Hat Update Infrastructure (RHUI) on a public cloud, enable required RHUI repositories and install required RHUI packages to ensure your system is ready for upgrade:

    1. For AWS Red Hat Enterprise Linux:

      # dnf config-manager --set-enabled rhui-client-config-server-8
      # dnf -y install leapp-rhui-aws
    2. For AWS Red Hat Enterprise Linux with High Availability:

      # dnf config-manager --set-enabled rhui-client-config-server-8-ha
      # dnf -y install leapp-rhui-aws-ha
    3. For Microsoft Azure:

      # dnf config-manager --set-enabled rhui-microsoft-azure-rhel8
      # dnf -y install rhui-azure-rhel8 leapp-rhui-azure
    4. For Google Cloud, follow the Leapp RHUI packages for Google Cloud Knowledgebase article.
  12. Install the Leapp utility:

    # dnf install leapp-upgrade

    Note that you need up-to-date leapp and leapp-repository packages, namely leapp version 0.19.0 of the leapp package and version 0.22.0 of the leapp-repository package.

    Note

    The leapp-repository package contains the leapp-upgrade-el8toel9 RPM package.

    Note

    If your system does not have internet access, download the following packages from the Red Hat Customer Portal:

    • leapp
    • leapp-deps
    • python3-leapp
    • leapp-upgrade-el8toel9
    • leapp-upgrade-el8toel9-deps
    • leapp-upgrade-el8toel9-fapolicyd

      • Include only if you installed the fapolicyd RPM package on your system.
  13. Update all packages to the latest RHEL 8 version and reboot:

    # dnf update
    # reboot
  14. The latest release of the leapp-upgrade-el8toel9 package contains all required data files. If you have replaced these data files with older versions, remove all JSON files in the /etc/leapp/files directory and reinstall the leapp-upgrade-el8toel9 package to ensure your data files are up-to-date.
  15. Optional: Review, remediate, and then remove the rpmnew and rpmsave files. For more information, see What are rpmnew & rpmsave files?
  16. Temporarily disable antivirus software to prevent the upgrade from failing.
  17. Ensure that any configuration management system does not interfere with the in-place upgrade process:

    • If you use a configuration management system with a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the leapp preupgrade command. Do not enable the configuration management system until after the upgrade is complete to prevent issues during the upgrade.
    • If you use a configuration management system with agentless architecture, such as Ansible, do not execute the configuration and deployment file, such as an Ansible playbook, during the in-place upgrade as described in Performing the upgrade.

      Automation of the pre-upgrade and upgrade process by using a configuration management system is not supported by Red Hat. For more information, see Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux.

  18. If your NSS database was created in RHEL 7 or earlier, verify that the database has been converted from the DBM database format to SQLite. For more information, see Updating NSS databases from DBM to SQLite.
  19. RHEL 9 does not support the legacy network-scripts package, which was deprecated in RHEL 8. Before upgrading, move your custom network scripts and write a NetworkManager dispatcher script that executes your existing custom scripts. For more information, see the Red Hat Knowledgebase solution Migrating custom network scripts to NetworkManager dispatcher scripts.
  20. If you are upgrading using an ISO image, verify that the ISO image contains the target OS version, for example, RHEL 9.6, and is saved to a persistent local mount point to ensure that the Leapp utility can access the image throughout the upgrade process.
  21. Ensure that you have a full system backup or a virtual machine snapshot. You should be able to get your system to the pre-upgrade state if you follow standard disaster recovery procedures within your environment. You can use the following backup options:

3.2. Preparing a Satellite-registered system for the upgrade

This procedure describes the steps that are necessary to prepare a system that is registered to Satellite for the upgrade to RHEL 9. There steps are performed on the Satellite Server.

Important

Users on Satellite systems must complete the preparatory steps described both in this procedure and in Preparing a RHEL 8 system for the upgrade.

Prerequisites

  • You have administrative privileges for the Satellite Server.

Procedure

  1. Verify that Satellite is on a version in full or maintenance support. For more information, see Red Hat Satellite Product Life Cycle.
  2. Import a subscription manifest with RHEL 9 repositories into Satellite Server. For more information, see the Managing Red Hat Subscriptions chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.17.
  3. Enable and synchronize all required RHEL 8 and RHEL 9 repositories on the Satellite Server with the latest updates for the source and target OS versions. Required repositories must be available in the Content View and enabled in the associated activation key.

    Note

    For RHEL 9 repositories, enable the target OS version, for example, RHEL 9.6, of each repository. If you enable only the RHEL 9 version of the repositories, the in-place upgrade is inhibited.

    For example, for the Intel architecture without an Extended Update Support (EUS) subscription, enable at minimum the following repositories:

    • Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

      rhel-8-for-x86_64-appstream-rpms

      x86_64 <source_os_version>

    • Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

      rhel-8-for-x86_64-baseos-rpms

      x86_64 <source_os_version>

    • Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)

      rhel-9-for-x86_64-appstream-rpms

      x86_64 <target_os_version>

    • Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)

      rhel-9-for-x86_64-baseos-rpms

      x86_64 <target_os_version>

      Replace <source_os_version> and <target_os_version> with the source OS version and target OS version respectively, for example, 8.10 and 9.6.

      For other architectures, see RHEL 8 repositories and RHEL 9 repositories.

      For more information, see the Importing Content chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.17.

  4. Attach the content host to a Content View containing the required RHEL 8 and RHEL 9 repositories.

    For more information, see the Managing Content Views chapter in the Managing Content Guide for the particular version of Red Hat Satellite, for example, for version 6.17.

Verification

  1. Verify that the correct RHEL 8 and RHEL 9 repositories have been added to the correct Content View on Satellite Server.

    1. In the Satellite web UI, navigate to Content > Lifecycle > Content Views and click the name of the Content View.
    2. Click the Repositories tab and verify that the repositories appear as expected.

      Note

      You can also verify that the repositories have been added to the Content View using the following commands:

      # hammer repository list --search 'content_label ~ rhel-8' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>
      # hammer repository list --search 'content_label ~ rhel-9' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>

      Replace <content_view_name> with the name of the Content View, <organization> with the organization, and <lifecycle_environement> with the name of the lifecycle environment..

  2. Verify that the correct RHEL 9 repositories are enabled in the activation key associated with the Content View:

    1. In Satellite web UI navigate to Content > Lifecycle > Activation Keys and click the name of the activation key.
    2. Click the Repository Sets tab and verify that the statuses of the required repositories are Enabled.
  3. . Verify that all expected RHEL 8 repositories are enabled in the host. For example:

    # subscription-manager repos --list-enabled | grep "^Repo ID"
    Repo ID:   rhel-8-for-x86_64-baseos-rpms
    Repo ID:   rhel-8-for-x86_64-appstream-rpms

3.3. Configuring the upgrade with LiveMode

LiveMode is an alternative method of preparing and booting to the upgrade environment when upgrading from RHEL 8 to RHEL 9 on the 64-bit Intel architecture. LiveMode uses the standard booting process. The standard booting process can prevent or help diagnose certain problems that occur during the upgrade, such as issues related to the storage initialization. Note that LiveMode requires approximately 700 MB of additional disk space to create and store the upgrade environment before the reboot.

Important

LiveMode is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

When using LiveMode, you can also configure the upgrade experience beyond the default specifications. This can be useful when troubleshooting during the upgrade process or if you want to view the upgrade’s progress by using an SSH connection.

If you are using LiveMode without any modifications to the default settings, you do not need to complete any preparation steps for LiveMode before the upgrade. If you want to change the default specifications, you must create and modify a YAML file.

Procedure

  1. If you want to modify LiveMode’s default specifications, create a YAML file in the /etc/leapp/actor_conf.d/ file, for example livemode.yaml.
  2. Enter the desired LiveMode configuration into the YAML file.

    Expand
    Table 3.1. LiveMode configuration
    Configuration fieldValue typeDefaultDescription

    additional_packages

    List[str]

    []

    Additional packages to be installed into the upgrade image.

    autostart_upgrade_after_reboot

    bool

    True

    If set to True, the upgrade starts automatically after the reboot. Otherwise, a manual trigger is required.

    capture_strace_info_into

    str

    ''

    If set to a non-empty string, leapp is executed under strace and results are stored within the provided file path.

    dracut_network

    str

    ''

    Dracut network arguments. Required if the `url_to_load_squashfs_`from option is set to a non-empty string.

    setup_network_manager

    bool

    False

    If set to False, the Leapp tool enables Network Manager in the upgrade image.

    setup_opensshd_using_auth_keys

    str

    ''

    If set to a non-empty string, openssh daemon is set up within the upgrade image using the provided authorized keys file.

    setup_passwordless_root

    bool

    False

    If set to True, the root account of the upgrade image has an empty password. Use with caution.

    squashfs_image_path

    str

    /var/lib/leapp/live-upgrade.img

    Desired location of the upgrade image of the minimal target system.

    url_to_load_squashfs_image_from

    str

    ''

    URL of the desired upgrade image.

    The following is an example of a /etc/leapp/actor_conf.d/livemode.yaml file:

    livemode:
      additional_packages : [ vim ]
      autostart_upgrade_after_reboot : false
      setup_network_manager : true
      setup_opensshd_using_auth_keys : /root/.ssh/authorized_keys

    The example file results in the following actions:

    • The Leapp utility installs the vim package into the upgrade environment.
    • The upgrade does not start automatically after reboot. You must manually restart it. This allows you to manually inspect the system and verify that the upgrade finished as expected and the system is ready for use before starting.
    • The Leapp utility attempts to enable NetworkManager inside the upgrade environment by using the source system’s network profiles.
    • The Leapp utility enables the opensshd service. If the system establishes network access successfully, you can use SSH to log in to the upgrade environment by using the root account and interact with the system.
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red Hat
Torna in cima