RHEL 9 から RHEL 10 へのアップグレード

手順

1. オプション: アップグレードに必要のないシステム以外の OS ファイルシステムをアンマウントし、/etc/fstab ファイルからコメントアウトします。たとえば、システム自体とは関係のないデータファイルのみを含むファイルシステムは、アップグレードに不要です。これにより、アップグレードプロセスに必要な時間が短縮されます。また、アップグレード時にカスタムまたはサードパーティーのアクターによって適切に移行されないサードパーティーアプリケーションに関連する、潜在的な問題を防ぐことができます。

2. RHSM を使用してアップグレードする場合は、Simple Content Access (SCA) が有効なアカウントにシステムが登録されていることを確認します。

   # 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

3. 適切なリポジトリーが有効になっていることを確認します。次のコマンドは、64 ビット Intel および AMD アーキテクチャーの Base リポジトリーと AppStream リポジトリーを有効にします。他のアーキテクチャーは、RHEL 9 リポジトリー を参照してください。

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

   注記

   オプション: CodeReady Linux Builder (Optional とも呼ばれます) リポジトリーまたは Supplementary リポジトリーを有効にします。これらのリポジトリーの内容に関する詳細は、パッケージマニフェスト を参照してください。

4. システムリリースバージョンをアップグレード元の OS バージョンに設定します。以下に例を示します。

   # subscription-manager release --set <source_os_version>

   <source_os_version> は、アップグレード元の OS バージョン (例: 9.6) に置き換えます。

   1. パブリッククラウド上の Red Hat Update Infrastructure (RHUI) を使用してアップグレードする場合は、予想されるシステムリリースバージョンを手動で設定します。

      # rhui-set-release --set 9.7

      重要

      rhui-set-release コマンドがシステムで使用できない場合は、/etc/dnf/vars/release ファイルを更新することで、予想されるシステムリリースバージョンを設定できます。

      # echo "9.7" > /etc/dnf/vars/releasever

5. 指定したバージョンにパッケージをロックするために dnf versionlock プラグインを使用している場合は、次のコマンドを実行してロックを解除します。

   # dnf versionlock clear

6. パブリッククラウドで Red Hat Update Infrastructure(RHUI) を使用してアップグレードする場合は、必要な RHUI リポジトリーを有効にして、必要な RHUI パッケージをインストールし、システムをアップグレードする準備ができていることを確認します。

   1. AWS の場合:

      # dnf config-manager --set-enabled rhui-client-config-server-9
      # dnf -y install leapp-rhui-aws

   2. For Microsoft Azure:

      # dnf config-manager --set-enabled rhui-microsoft-azure-rhel9
      # dnf -y install rhui-azure-rhel8 leapp-rhui-azure

   3. Google Cloud の場合は、ナレッジベース記事 Leapp RHUI packages for Google Cloud に従います。

7. leapp および leapp-repository パッケージが最新であることを確認します。

   1. RHEL 9.6: バージョン 0.19.0 の leapp パッケージとバージョン 0.22.0 の leapp-repository パッケージ。

   2. RHEL 9.6: バージョン 0.20.0 の leapp パッケージとバージョン 0.23.0 の leapp-repository パッケージ。

      leapp-repository パッケージには、leapp-upgrade-el9toel10 RPM パッケージが含まれています。

      注記

      インターネット非接続のシステムのみ: Red Hat カスタマーポータル から次のパッケージをダウンロードします。

      • leapp
      • leapp-deps
      • python3-leapp
      • leapp-upgrade-el9toel10
      • leapp-upgrade-el9toel10-deps

      • leapp-upgrade-el9toel10-fapolicyd

        • システムに fapolicyd RPM パッケージをインストールした場合にのみ含めてください。

8. Leapp ユーティリティーをインストールします。

   # dnf install leapp-upgrade

9. すべてのパッケージを最新の RHEL 9 バージョンに更新して再起動します。

   # dnf update
   # reboot

10. オプション: rpmnew ファイルと rpmsave ファイルを確認し、修正してから削除します。

11. 設定管理システムを使用する場合は、そのシステムがインプレースアップグレードプロセスに干渉しないことを確認します。

    • 設定管理システムに Puppet、Salt、Chef などのクライアント/サーバーアーキテクチャーがある場合は、leapp preupgrade コマンドを実行する前にシステムを無効にしてください。アップグレード時に問題が発生するのを防ぐために、アップグレードが完了するまで設定管理システムを有効にしないでください。

    • 設定管理システムにエージェントレスアーキテクチャーがある場合は、設定およびデプロイメントファイルを実行しないでください。たとえば、システムに Ansible がある場合は、アップグレード中に Ansible Playbook を実行しないでください。

      警告

      設定管理システムを使用したアップグレード前およびアップグレードプロセスの自動化は、Red Hat ではサポートされていません。詳細は、Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux を参照してください。

12. ISO イメージを使用してアップグレードする場合は、ISO イメージにアップグレード先の OS バージョン (RHEL 10.0 など) が含まれていることを確認します。また、アップグレードプロセス全体を通じて Leapp ユーティリティーがイメージにアクセスできるように、イメージが永続的なローカルマウントポイントに保存されていることを確認します。

手順

1. RHEL 9 リポジトリーが含まれるサブスクリプションマニフェストを Satellite Server にインポートします。詳細は、該当するバージョンの Red Hat Satellite の「コンテンツの管理」ガイドで「Red Hat サブスクリプションの管理」の章を参照してください。

2. Satellite Server で必要なすべての RHEL 9 および RHEL 10 リポジトリーを有効にし、アップグレード元およびアップグレード先 OS バージョンの最新の更新と同期します。必要なリポジトリーがコンテンツビューで利用可能であり、関連付けられたアクティベーションキーで有効になっている必要があります。

   注記

   RHEL 10 リポジトリーの場合は、各リポジトリーのアップグレード先の OS バージョン (例: RHEL 10.0) を有効にしてください。RHEL 10 バージョンのリポジトリーのみを有効にした場合、インプレースアップグレードが拒否されます。

   たとえば、Extended Update Support (EUS) サブスクリプションのない Intel アーキテクチャーの場合は、少なくとも次のリポジトリーを有効にします。

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

     rhel-9-for-x86_64-appstream-rpms

     x86_64 <source_os_version>

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

     rhel-9-for-x86_64-baseos-rpms

     x86_64 <source_os_version>

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

     rhel-10-for-x86_64-appstream-rpms

     x86_64 <target_os_version>

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

     rhel-10-for-x86_64-baseos-rpms

     x86_64 <target_os_version>

     <source_os_version> と <target_os_version> は、それぞれアップグレード元の OS バージョンとアップグレード先の OS バージョンに置き換えます (例: 9.6 と 10.0)。

     他のアーキテクチャーは、RHEL 9 リポジトリー および RHEL 10 リポジトリー を参照してください。

     詳細は、該当するバージョンの Red Hat Satellite の コンテンツの管理 ガイドで コンテンツのインポート の章を参照してください。

3. 必要な RHEL 9 リポジトリーおよび RHEL 10 リポジトリーを含むコンテンツビューにコンテンツホストを割り当てます。

   詳細は、該当するバージョンの Red Hat Satellite の コンテンツの管理 ガイドで コンテンツビューの管理 の章を参照してください。

検証

1. 正しい RHEL 9 リポジトリーおよび RHEL 10 リポジトリーが Satellite Server の正しいコンテンツビューに追加されていることを確認します。

   1. Satellite Web UI で、Content > Lifecycle > Content Views に移動して、コンテンツビューの名前をクリックします。

   2. Repositories タブをクリックし、リポジトリーが期待どおりに表示されることを確認します。

      注記

      次のコマンドを使用して、リポジトリーがコンテンツビューに追加されたことを確認することもできます。

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

      <content_view_name> をコンテンツビューの名前に、<organization> を組織に、<lifecycle_environement> をライフサイクル環境の名前に置き換えます。

2. コンテンツビューに関連付けられたアクティベーションキーで、正しい RHEL 10 リポジトリーが有効になっていることを確認します。

   1. Satellite Web UI で、Content > Lifecycle > Activation Keys に移動し、アクティベーションキーの名前をクリックします。
   2. Repository Sets タブをクリックし、必要なリポジトリーのステータスが Enabled であることを確認します。

3. 予想されるすべての RHEL 9 リポジトリーがホストで有効になっていることを確認します。以下に例を示します。

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

手順

1. LiveMode のデフォルトの仕様を変更する場合は、/etc/leapp/actor_conf.d/ に YAML ファイル (例: livemode.yaml) を作成します。

2. 必要な LiveMode 設定を YAML ファイルに入力します。

   Expand

   表3.1 LiveMode の設定

   設定フィールド	値の型	デフォルト	説明
   additional_packages	List[str]	[]	アップグレードイメージにインストールする追加パッケージ。
   autostart_upgrade_after_reboot	bool	True	True に設定すると、再起動後にアップグレードが自動的に開始します。設定しない場合は、手動でのトリガーが必要です。
   capture_strace_info_into	str	''	空でない文字列に設定すると、leapp が strace 配下で実行され、結果が指定したファイルパス内に保存されます。
   dracut_network	str	''	Dracut のネットワーク引数。`url_to_load_squashfs_from` オプションが空でない文字列に設定されている場合は必須です。
   setup_network_manager	bool	False	False に設定すると、Leapp ツールがアップグレードイメージ内で Network Manager を有効にします。
   setup_opensshd_using_auth_keys	str	''	空でない文字列に設定すると、指定された authorized keys ファイルを使用して、アップグレードイメージ内で openssh デーモンが設定されます。
   setup_passwordless_root	bool	False	True に設定すると、アップグレードイメージの root アカウントのパスワードが空になります。注意して使用してください。
   squashfs_image_path	str	/var/lib/leapp/live-upgrade.img	最小ターゲットシステムのアップグレードイメージを配置する目的の場所。
   url_to_load_squashfs_image_from	str	''	目的のアップグレードイメージの URL。

   Show more

   以下は /etc/leapp/actor_conf.d/livemode.yaml ファイルの例です。

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

   このサンプルファイルを使用すると、次のアクションが実行されます。

   • Leapp ユーティリティーにより、vim パッケージがアップグレード用環境にインストールされます。
   • 再起動後、アップグレードが自動的に開始しません。手動で再起動する必要があります。これにより、起動前にシステムを手動で検査し、アップグレードが期待どおりに完了したこと、およびシステムが使用できる状態であることを確認できます。
   • Leapp ユーティリティーが、アップグレード元システムのネットワークプロファイルを使用して、アップグレード用環境内で NetworkManager を有効にすることを試みます。
   • Leapp ユーティリティーにより、opensshd サービスが有効になります。システムが正常にネットワークアクセスを確立した場合は、SSH を使用して root アカウントでアップグレード用環境にログインし、システムを操作できます。

手順

1. RHEL 9 システムで、アップグレード前のフェーズを実行します。

   # leapp preupgrade --target <_target_os_version_>

   target_os_version は、アップグレード先の OS バージョン (例: 10.0) に置き換えます。アップグレード先の OS バージョンが定義されていない場合、Leapp は サポート対象のアップグレードパス の表 1.1 に指定されているデフォルトのアップグレード先の OS バージョンを使用します。

   • アップグレードに /etc/yum.repos.d/ ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。

     # leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

     repository_id はリポジトリー ID に置き換えます。

   • RHSM を使用せずにアップグレード する場合、または RHUI を使用してアップグレードする場合は、--no-rhsm オプションを追加します。
   • Extended Upgrade Support (EUS) または Advanced Update Support (AUS) サブスクリプションをお持ちの場合は、--channel <channel> オプションを追加します。<channel> はチャネル名 (例: eus または aus) に置き換えます。

   • Red Hat OpenStack Platform で RHEL for Real Time または Real Time for Network Functions Virtualization (NFV) を使用している場合は、--enablerepo オプションを使用してデプロイメントを有効にします。以下に例を示します。

     # leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpms

     詳細は、Real-Time Compute の設定 を参照してください。

2. /var/log/leapp/leapp-report.txt ファイル内のレポートを調べて、報告されたすべての問題を手動で解決します。報告された問題の中には、修正の提案が含まれているものもあります。阻害 要因の問題があると、それを解決するまでアップグレードできません。

   レポートには次のリスク因子レベルが含まれます。

   • 高 - システム状態が悪化する可能性が非常に高い
   • 中 - システムとアプリケーションの両方に影響を与える可能性がある
   • 低 - システムに影響はないが、アプリケーションに影響を与える可能性がある
   • Info - システムまたはアプリケーションへの影響がないと考えられる情報です。

3. 特定のシステム設定では、Leapp ユーティリティーは手動で回答する必要がある True/False の質問表を生成します。アップグレード前のレポートに Missing required answers in the answer file のメッセージが含まれる場合は、次の手順を実行します。

   1. /var/log/leapp/answerfile ファイルを開き、true または false の質問を確認します。

   2. /var/log/leapp/answerfile ファイルを手動で編集し、# 記号を削除してファイルの確認行のコメントを解除し、True または False として回答を確定します。詳細は、トラブルシューティングのヒント を参照してください。

      注記

      または、以下のコマンドを実行して、True/False の質問に回答できます。

      # leapp answer --section <question_section>.<field_name>=<answer>

4. 前の手順を繰り返してアップグレード前レポートを再実行し、すべての重要な問題が解決されたことを確認します。

手順

1. cockpit-leapp プラグインをインストールします。

   # dnf install cockpit-leapp

2. root として、または sudo で管理コマンドを入力するパーミッションがあるユーザーとして Web コンソールにログインします。

3. RHEL 9 システムで、コマンドラインまたは Web コンソールのターミナルからアップグレード前のフェーズを実行します。

   # leapp preupgrade --target <target_os_version>

   target_os_version は、アップグレード先の OS バージョン (例: 10.0) に置き換えます。アップグレード先の OS バージョンが定義されていない場合、Leapp は サポート対象のアップグレードパス の表 1.1 に指定されているデフォルトのアップグレード先の OS バージョンを使用します。

   • アップグレードに /etc/yum.repos.d/ ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。

     # leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

   • RHSM を使用せずにアップグレード する場合、または RHUI を使用してアップグレードする場合は、--no-rhsm オプションを追加します。
   • Extended Upgrade Support (EUS) または Advanced Update Support (AUS) サブスクリプションをお持ちの場合は、--channel <channel> オプションを追加します。<channel> はチャネル名 (eus または `aus` など) に置き換えます。

   • Red Hat OpenStack Platform で RHEL for Real Time または Real Time for Network Functions Virtualization (NFV) を使用している場合は、--enablerepo オプションを使用してデプロイメントを有効にします。以下に例を示します。

     # leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpms

     詳細は、Real-Time Compute の設定 を参照してください。

4. Web コンソールで、ナビゲーションメニューから Upgrade Report を選択し、報告されたすべての問題を確認します。阻害 要因の問題があると、それを解決するまでアップグレードできません。問題を詳細に表示するには、行を選択して詳細ペインを開きます。

   図4.1 Web コンソールのインプレースアップグレードレポート

   

   レポートには次のリスク因子レベルが含まれます。

   • 高 - システム状態が悪化する可能性が非常に高い
   • 中 - システムとアプリケーションの両方に影響を与える可能性がある
   • 低 - システムに影響はないが、アプリケーションに影響を与える可能性がある
   • Info - システムまたはアプリケーションへの影響がないと考えられる情報です。

5. 特定の設定では、Leapp ユーティリティーは手動で回答する必要がある True/False の質問表を生成します。アップグレードレポートに Missing required answers in the answer file という行が含まれている場合は、次の手順を実行します。

   1. Missing required answers in the answer file 行を選択し、Detail ペインを開きます。デフォルトの回答は修復コマンドの最後に記載されています。
   2. デフォルトの回答で確定する場合は、Add to Remediation Plan を選択して後で修復を開始するか、Run Remediation を選択してすぐに修復を開始します。

   3. 代わりにデフォルト以外の回答を選択する場合は、ターミナルで、回答する質問と確定する回答を指定した leapp answer コマンドを実行します。

      # leapp answer --section <question_section>.<field_name>=<answer>

      注記

      /var/log/leapp/answerfile ファイルを手動で編集し、# 記号を削除してファイルの confirm 行のコメントを解除し、True または False として回答を確定します。詳細は、トラブルシューティングのヒント を参照してください。

6. 一部の問題には、問題を自動的に解決するために実行できる修復コマンドがあります。修復コマンドは個別に実行することも、修復コマンドでまとめて実行することもできます。

   1. 単一の修復コマンドを実行するには、問題の Detail ペインを開き、Run Remediation をクリックします。

   2. 修復コマンドを修復計画に追加するには、問題の Detail ペインを開き、Add to Remediation Plan をクリックします。

      図4.2 詳細ペイン

      
   3. 追加されたすべての修復コマンドを含む修復計画を実行するには、レポートの右上隅にある Remediation plan リンクをクリックします。リスト表示されているすべてのコマンドを実行するには、Execute Remediation Plan をクリックします。
7. レポートを確認し、報告された問題をすべて解決したら、ステップ 3 - 7 を繰り返してレポートを再実行し、すべての重大な問題が解決されたことを確認します。

手順

1. システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。次のバックアップオプションを使用できます。

   • Relax-and-Recover (ReaR) ユーティリティーを使用して、システムの完全バックアップを作成します。詳細は、ReaR のドキュメント および What is Relax and Recover (ReaR) and how can I use it for disaster recovery? を参照してください。

   • LVM スナップショット または RAID 分割 を使用して、システムのスナップショットを作成します。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。Boom ユーティリティーを使用して、スナップショットとロールバックのブートエントリーを管理することもできます。詳細は、What is BOOM and how to install it? および スナップショットを使用したシステムアップグレードの管理 を参照してください。

     注記

     LVM スナップショットではシステムの完全バックアップが作成されないため、特定のアップグレードの失敗後にシステムを復元できない可能性があります。したがって、ReaR ユーティリティーを使用して完全バックアップを作成する方が安全です。

2. RHEL 9 システムで、アップグレードプロセスを開始します。

   # leapp upgrade --target <_target_os_version_>

   target_os_version は、アップグレード先の OS バージョン (例: 10.0) に置き換えます。アップグレード先の OS バージョンが定義されていない場合、Leapp は サポート対象のアップグレードパス の表 1.1 に指定されているデフォルトのアップグレード先の OS バージョンを使用します。

   • アップグレードに /etc/yum.repos.d/ ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。

     # leapp upgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

   • RHSM を使用せずにアップグレード する場合、または RHUI を使用してアップグレードする場合は、--no-rhsm オプションを追加します。
   • ISO イメージを使用してアップグレードする場合は、--no-rhsm および --iso <file_path> オプションを追加します。<file_path> は、保存された ISO イメージへのファイルパス (/home/rhel9.iso など) に置き換えます。
   • Extended Upgrade Support (EUS) または Advanced Update Support (AUS) サブスクリプションをお持ちの場合は、--channel channel オプションを追加します。channel は leapp preupgrade コマンドで使用した値 (例: eus または aus) に置き換えます。leapp preupgrade および leapp upgrade コマンドの両方で、--channel オプションで同じ値を使用する必要があります。

   • Red Hat OpenStack Platform で RHEL for Real Time または Real Time for Network Functions Virtualization (NFV) を使用している場合は、--enablerepo オプションを使用してデプロイメントを有効にします。以下に例を示します。

     # leapp upgrade --enablerepo rhel-10-for-x86_64-rt-rpms

     詳細は、Real-Time Compute の設定 を参照してください。

   • LiveMode を使用してアップグレードする場合は、環境変数 LEAPP_UNSUPPORTED=1 を設定し、livemode 値とともに --enable-experimental-feature オプションを使用します。以下に例を示します。

     # LEAPP_UNSUPPORTED=1 leapp upgrade --enable-experimental-feature livemode

     詳細は、LiveMode を使用した RHEL 9.7 から RHEL 10.1 へのアップグレードの設定 を参照してください。

     重要

     LiveMode はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat では、実稼働環境での使用を推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

     Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3. アップグレードプロセスの開始時に、Leapp は、アップグレード前のレポートの確認 で説明されているアップグレード前のフェーズを再度実行します。

   • システムがアップグレード可能な場合、Leapp は必要なデータをダウンロードし、アップグレード用の RPM トランザクションを準備します。
   • システムが信頼性の高いアップグレードの条件を満たしていない場合、Leapp はアップグレードプロセスを終了し、問題の記録と推奨される解決策を /var/log/leapp/leapp-report.txt ファイルに出力します。詳細は、トラブルシューティング を参照してください。

4. システムを手動で再起動します。

   # reboot

   システムが RHEL 10 ベースの初期 RAM ディスクイメージ (initramfs) で起動します。Leapp はすべてのパッケージをアップグレードし、自動的に RHEL 10 システムを再起動します。

   または、--reboot オプションを指定して leapp upgrade コマンドを実行し、この手動の手順を省略することもできます。

   障害が発生した場合は、トラブルシューティング の説明に従ってログと既知の問題を調査してください。

5. RHEL 10 システムにログインし、アップグレード後の状態の確認 の説明に従ってその状態を確認します。
6. アップグレードレポートおよび アップグレード後のタスクの実行 で説明されているすべてのアップグレード後のタスクを実行します。

手順

1. システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。次のバックアップオプションを使用できます。

   • Relax-and-Recover (ReaR) ユーティリティーを使用して、システムの完全バックアップを作成します。詳細は、ReaR のドキュメント および What is Relax and Recover (ReaR) and how can I use it for disaster recovery? を参照してください。

   • LVM スナップショット または RAID 分割 を使用して、システムのスナップショットを作成します。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。Boom ユーティリティーを使用して、スナップショットとロールバックのブートエントリーを管理することもできます。詳細は、What is BOOM and how to install it? および スナップショットを使用したシステムアップグレードの管理 を参照してください。

     注記

     LVM スナップショットではシステムの完全バックアップが作成されないため、特定のアップグレードの失敗後にシステムを復元できない可能性があります。したがって、ReaR ユーティリティーを使用して完全バックアップを作成する方が安全です。

2. RHEL 9 システムで、アップグレードプロセスを開始します。

   # leapp upgrade --target <_target_os_version_>

   target_os_version は、アップグレード先の OS バージョン (例: 10.0) に置き換えます。アップグレード先の OS バージョンが定義されていない場合、Leapp は サポート対象のアップグレードパス の表 1.1 に指定されているデフォルトのアップグレード先の OS バージョンを使用します。

   • アップグレードに /etc/yum.repos.d/ ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。

     # leapp upgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...

   • RHSM を使用せずにアップグレード する場合は、--no-rhsm オプションを追加します。
   • ISO イメージを使用してアップグレードする場合は、--no-rhsm および --iso <file_path> オプションを追加します。<file_path> は、保存された ISO イメージへのファイルパス (/home/rhel9.iso など) に置き換えます。
   • Extended Upgrade Support (EUS) または Advanced Update Support (AUS) サブスクリプションをお持ちの場合は、--channel channel オプションを追加します。channel は leapp preupgrade コマンドで使用した値 (例: eus または aus) に置き換えます。leapp preupgrade および leapp upgrade コマンドの両方で、--channel オプションで同じ値を使用する必要があります。

   • Red Hat OpenStack Platform で RHEL for Real Time または Real Time for Network Functions Virtualization (NFV) を使用している場合は、--enablerepo オプションを使用してデプロイメントを有効にします。以下に例を示します。

     # leapp upgrade --enablerepo rhel-10-for-x86_64-rt-rpms

     詳細は、Real-Time Compute の設定 を参照してください。

3. アップグレードプロセスの開始時に、Leapp は、アップグレード前のレポートの確認 で説明されているアップグレード前のフェーズを再度実行します。

   • システムがアップグレード可能な場合、Leapp は必要なデータをダウンロードし、アップグレード用の RPM トランザクションを準備します。
   • システムが信頼性の高いアップグレードの条件を満たしていない場合、Leapp はアップグレードプロセスを終了し、問題の記録と推奨される解決策を /var/log/leapp/leapp-report.txt ファイルに出力します。詳細は、トラブルシューティング を参照してください。

4. システムを手動で再起動します。

   # reboot

   この段階で、システムが RHEL 10 ベースの初期 RAM ディスクイメージ (initramfs) で起動します。Leapp はすべてのパッケージをアップグレードし、自動的に RHEL 10 システムを再起動します。

   または、--reboot オプションを指定して leapp upgrade コマンドを実行し、この手動の手順を省略することもできます。

   障害が発生した場合は、トラブルシューティング の説明に従ってログと既知の問題を調査してください。

5. RHEL 10 システムにログインし、アップグレード後の状態の確認 の説明に従ってその状態を確認します。
6. アップグレードレポートおよび アップグレード後のタスクの実行 で説明されているすべてのアップグレード後のタスクを実行します。

手順

1. /etc/dnf/dnf.conf 設定ファイルの除外リストから残りの Leapp パッケージを削除します。これには、アップグレードエクステンション開発用のツールである snactor パッケージが含まれます。インプレースアップグレード中に、Leapp ユーティリティーでインストールされた Leapp パッケージが exclude リストに自動的に追加され、重要なファイルが削除または更新されないようにします。インプレースアップグレード後、システムから削除する前に、これらの Leapp パッケージを exclude リストから削除する必要があります。

   • exclude リストからパッケージを手動で削除するには、/etc/dnf/dnf.conf 設定ファイルを編集し、除外リストから必要な Leapp パッケージを削除します。

   • exclude リストからすべてのパッケージを削除するには、次のコマンドを実行します。

     # dnf config-manager --save --setopt exclude=''

2. Leapp パッケージを含め、残っている RHEL 9 パッケージを削除します。

   1. 残っている RHEL 9 パッケージを見つけます。

      # rpm -qa | grep -e '\.el[789]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort

   2. 残っている RHEL 9 パッケージを RHEL 10 システムから削除します。RPM の依存関係を確実に維持するために、dnf remove コマンドを使用します。

      以下に例を示します。

      # dnf remove $(rpm -qa | grep \.el[789] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')

      重要

      このステップにより、サードパーティーのパッケージも削除される可能性があります。受け入れる前にトランザクションを確認して、パッケージが誤って削除されないようにしてください。

   3. 残りの Leapp 依存関係パッケージを削除します。

      # dnf remove leapp-deps-el10 leapp-repository-deps-el10

3. オプション: 残っているすべてのアップグレード関連データをシステムから削除します。

   # rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp

   重要

   このデータを削除すると、Red Hat サポートによるアップグレード後の問題の調査とトラブルシューティングが制限される可能性があります。

4. RHEL 10 と互換性のないパッケージを含む DNF リポジトリーを無効にします。RHSM によって管理されるリポジトリーは自動的に処理されます。これらのリポジトリーを無効にするには、以下を実行します。

   # dnf config-manager --set-disabled <repository_id>

   repository_id はリポジトリー ID に置き換えます。

5. 古いレスキューカーネルと初期 RAM ディスクを現在のカーネルとディスクに置き換えます。

   1. 既存のレスキューカーネルと初期 RAM ディスクを削除します。

      # rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* 

   2. レスキューカーネルと関連する初期 RAM ディスクを再インストールします。

      # /usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"

   3. システムが IBM Z アーキテクチャーを使用している場合は、zipl ブートローダーを更新します。

      # zipl

6. 既存の設定ファイルを確認します。

   • rpmnew、rpmsave、leappsave ファイルを確認し、修正してから削除します。rpmsave と leappsave は同等であり、同様に処理できることに注意してください。詳細は、What are rpmnew & rpmsave files? を参照してください。
   • 有効ではなくなった RHEL 9 DNF モジュールの設定ファイルを /etc/dnf/modules.d/ ディレクトリーから削除します。関連する DNF モジュールが存在しない場合、このファイルはシステムに影響を与えないことに注意してください。
7. セキュリティーポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は、セキュリティーポリシーの適用 を参照してください。

検証

1. 以前に削除したレスキューカーネルとレスキュー初期 RAM ディスクファイルが現在のカーネル用に作成されていることを確認します。

   # ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* 
   # lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"

2. レスキューブートエントリーが既存のレスキューファイルを参照していることを確認します。grubby の出力を確認します。

   # grubby --info /boot/vmlinuz-*rescue*

3. grubby の出力を確認し、RHEL 9 のブートエントリーが設定されていないことを確認します。

   # grubby --info ALL

4. /boot/loader/entries ファイルに以前の RHEL に関連するファイルが存在しないことを確認します。

   # grep -r ".el9" "/boot/loader/entries/" || echo "Everything seems ok."

手順

1. ausearch ユーティリティーなどを使用して、SELinux 拒否がないことを確認します。

   # ausearch -m AVC,USER_AVC -ts boot

   前述のステップは、最も一般的な環境だけを対象としたものです。考えられるすべての SELinux 拒否を確認するには、「SELinux の使用」の SELinux 拒否の特定 セクションを参照してください。このセクションでは、すべての手順が説明されています。

2. 任意のテキストエディターで /etc/selinux/config ファイルを開きます。以下に例を示します。

   # vi /etc/selinux/config

3. SELINUX=enforcing オプションを設定します。

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=enforcing
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

4. 変更を保存して、システムを再起動します。

   # reboot

検証

1. システムの再起動後に、getenforce コマンドが Enforcing を返すことを確認します。

   $ getenforce
   Enforcing

手順

1. 適切なセキュリティーコンプライアンスデータストリームの .xml ファイルを見つけます。

   $ ls /usr/share/xml/scap/ssg/content/
   …
   ssg-rhel10-ds.xml
   …

   詳細は、設定コンプライアンスのプロファイルの表示 セクションを参照してください。

2. 適切なデータストリームから選択したプロファイルに従って、システムを修正します。

   # oscap xccdf eval --profile <profile_ID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

   <profile_ID> は、システムをハードニングする際に準拠する必要があるプロファイルの ID に置き換えます。RHEL 10 でサポートされているプロファイルの完全なリストは、RHEL 10 でサポートされている SCAP Security Guide プロファイル を参照してください。

   警告

   --remediate オプションを有効にしてシステム評価を実行した場合、慎重に行わないと、システムが機能不全に陥る場合があります。Red Hat は、セキュリティーハードニング関連の修復によって行われた変更を自動的に元に戻す方法は提供していません。修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

3. システムを再起動します。

   # reboot

検証

1. システムがプロファイルに準拠していることを確認し、結果を HTML ファイルに保存します。

   $ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml