RHEL 7 から RHEL 8 へのアップグレード
Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのインプレースアップグレードの手順
概要
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 アップグレードの実行
RHEL8 にアップグレードするには、RHEL7 システムの準備、Web コンソールでコマンドラインを使用してアップグレードし、アップグレード後の状態を確認する必要があります。
1.1. アップグレードの計画
インプレースアップグレードは、システムを RHEL の次のメジャーバージョンに移行する方法です。この方法は、推奨され、サポートされています。
RHEL 8 にアップグレードする前に、以下の点を検討する必要があります。
オペレーティングシステム - オペレーティングシステムは、以下の条件下で、
Leapp
ユーティリティーによりアップグレードされます。利用可能な最新の RHEL 7 バージョン の Server バリアントがインストールされている。現在は以下のとおりです。
- 64 ビット Intel、IBM POWER 8 (リトルエンディアン)、および IBM Z アーキテクチャーでの RHEL 7.9
カーネルバージョン 4.14 を必要とする アーキテクチャー (64-bit ARM、IBM POWER 9(リトルエンディアン)、および IBM Z (Structure A)) での RHEL 7.6
詳細は「Supported in-place upgrade paths for Red Hat Enterprise Linux」を参照してください。
- RHEL 8 の最小 ハードウェア要件 が満たされている。
- 提供されている最新の RHEL 7.9 および RHEL 8.2 コンテンツへのアクセス。詳細は、「アップグレードに向けて RHEL 7 システムの準備」 の手順 1 を参照してください。
-
アプリケーション -
Leapp
を使用して、システムにインストールされているアプリケーションを移行できます。ただし、特定のケースでは、アップグレード時にLeapp
が実行するアクションを指定するカスタムアクターを作成する必要があります。たとえば、アプリケーションの再設定や特定のハードウェアドライバーのインストールなどです。詳細は、「Handling the migration of your custom and third-party applications」を参照してください。Red Hat は、カスタムアクターに対応していません。 Security - アップグレード前にこの要素を評価し、アップグレードプロセスの完了時に追加の手順を実行する必要があります。特に以下の点を考慮してください。
- アップグレードの前に、システムが準拠する必要のあるセキュリティー標準を定義し、「RHEL 8 のセキュリティー変更」を理解します。
-
Leapp
ユーティリティーは、アップグレードプロセス時に SELinux モードを Permissive に設定します。 - FIPS モードでのシステムのインプレースアップグレードはサポートされていません。
- アップグレードが完了したら、セキュリティーポリシーを再評価し、再適用します。アップグレード中に無効になった、または RHEL 8 で新たに導入されたセキュリティーポリシーを適用する方法は、2章セキュリティーポリシーの適用を参照してください。
- ストレージおよびファイルシステム - アップグレードする前に、必ずシステムのバックアップを作成してください。たとえば、ReaR (Relax-and-Recover) ユーティリティー、LVM スナップショット、RAID 分割、または仮想マシンのスナップショットを使用できます。
- ダウンタイム - アップグレードプロセスには数分から数時間かかる場合があります。
既知の制限 - 現在、
Leapp
の注目すべき既知の制限には以下が含まれます。- 現在、ディスク全体またはパーティションの暗号化、またはファイルシステムの暗号化は、インプレースアップグレードの対象となるシステムでは使用できません。
- ネットワークベースのマルチパスやネットワークストレージマウントは、システムパーティション (iSCSI、NFS など) として使用できません。
- 現在、インプレースアップグレードは、RHEL サブスクリプションに Red Hat Update Infrastructure を使用して Red Hat Subscription Manager を使用しないパブリッククラウド (Amazon EC2、Azure、Huawei Cloud、Alibaba Cloud、Google Cloud) のオンデマンドインスタンスではサポートされません。
「既知の問題」も併せて参照してください。
Red Hat Insights を使用して、Insights に登録したどのシステムを RHEL 8 にアップグレードできるかを確認できます。これを行うには、該当する Insights ルール に移動し、見出しの Affected systems の下にある一覧を確認します。Insights ルールは RHEL 7 マイナーバージョンのみを考慮し、システムのアップグレード前の評価は行わないことに注意してください。
1.2. アップグレードに向けて RHEL 7 システムの準備
この手順では、Leapp
ユーティリティーを使用して RHEL 8 へのインプレースアップグレードを実行する前に必要な手順を説明します。
アップグレードプロセス中に Red Hat Subscription Manager を使用する予定がない場合は、「Upgrading to RHEL 8 without Red Hat Subscription Manager」を参照してください。
前提条件
- システムが、「アップグレードの計画」に記載されている条件を満たしている。
手順
Red Hat Subscription Manager を使用して、システムが Red Hat Content Delivery Network (CDN) または Red Hat Satellite 6.5 以降に適切に登録されていることを確認します。
重要システムが Satellite Server に登録されている場合は、Satellite が以下の条件を満たしていることを確認してください。
- Satellite には、RHEL 8 リポジトリーをインポートしたサブスクリプションマニフェストがあります。詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.7 など) の『コンテンツ管理ガイド』の「サブスクリプションの管理」を参照してください。
以下のリポジトリーが有効になり、最新の更新と同期され、Satellite で公開されます。
- Red Hat Enterprise Linux 7 Server RPMs x86_64 7 または Red Hat Enterprise Linux 7 Server RPMs x86_64 7.9
- Red Hat Enterprise Linux 7 Server - Extras (RPM)
- Red Hat Enterprise Linux 8 for x86_64 - AppStream RPMs x86_64 8.2
Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs x86_64 8.2
詳細は、Red Hat Satellite の特定バージョン (バージョン 6.7 など) の『コンテンツ管理ガイド』の「Red Hat コンテンツのインポート」の章を参照してください。
Red Hat Enterprise Linux Server サーバーのサブスクリプション が割り当てられていることを確認します。
# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 7.9 Arch: x86_64 Status: Subscribed
製品名に Server が表示され、ステータスとして サブスクライブされ ているはずです。
適切なリポジトリーが有効になっていることを確認します。次のコマンドは、64 ビット Intel アーキテクチャーのリポジトリーの一覧を示します。他のアーキテクチャーについては、付録A RHEL 7 リポジトリーを参照してください。
Base リポジトリーを有効にします。
# subscription-manager repos --enable rhel-7-server-rpms
Leapp
およびその依存関係が利用可能な Extras リポジトリーを有効にします。# subscription-manager repos --enable rhel-7-server-extras-rpms
注記Optional リポジトリーまたは Supplementary リポジトリーも有効にすることができます。付録A RHEL 7 リポジトリーの一覧をご覧ください。この場合、
Leapp
は、RHEL 8 CodeReady Linux Builder リポジトリーまたは RHEL 8 Supplementary リポジトリーをそれぞれ有効にします。
最新の RHEL 7 コンテンツを利用するように Red Hat Subscription Manager を設定します。
# subscription-manager release --unset
- 必要に応じて、カスタムリポジトリーを使用する場合は、「Customizing your Red Hat Enterprise Linux in-place upgrade」の指示に従って設定します。
yum-plugin-versionlock
プラグインを使用して、パッケージを特定バージョンにロックする場合は、次のコマンドを実行してロックを解除します。# yum versionlock clear
詳細は「指定したバージョンのパッケージ (または指定したバージョン以前のパッケージ) だけをインストールまたはアップグレードできるように yum の使用を制限する方法」を参照してください。
システムロケールが
en_US.UTF-8
に設定されていることを確認します。$ cat /etc/locale.conf
ロケールが異なる場合は、「RHEL7 のシステムロケールを変更する」を参照してください。
すべてのパッケージを最新の RHEL 7 バージョンに更新します。
# yum update
システムを再起動します。
# reboot
Leapp
ユーティリティーをインストールします。# yum install leapp leapp-repository
現在、
leapp
パッケージおよびleapp-repository
パッケージの両方に、バージョン0.11.0 以降が必要になります。-
ナレッジベースの記事「RHEL 7 から RHEL 8 へのインプレースアップグレード時に Leapp ユーティリティーで必要なデータ」に添付されている追加の必須データファイル (RPM パッケージの変更および RPM リポジトリーマッピング) をダウンロードして、
/etc/leapp/files/
ディレクトリーに保存します。これは、アップグレードを成功させるために必要です。現在、leapp-data11.tar.gz
以降のアーカイブからのデータファイルが必要になることに注意してください。 GRUB がデフォルトの場所 (
/boot
) 以外にインストールされている場合は、以下のように各環境変数をエクスポートします。# export LEAPP_GRUB_DEVICE="/path_to_device"
- (Salt、Chef、Puppet、Ansible などの) 設定管理を無効にしているか、元の RHEL7 システムを復元しないように適切に再設定していることを確認します。
-
システムで、カーネル (
eth
) が使用する接頭辞に基づいた名前で、複数の Network Interface Card (NIC) が使用されていないことを確認します。RHEL 8 へのインプレースアップグレードの前に別の命名スキームに移行する方法は「RHEL 7 でカーネルの NIC 名を使用している場合に RHEL 8 へのインプレースアップグレードを実行する方法 」を参照してください。 - システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。これにより、ご利用の環境で、以下の標準の災害復旧手順に従って、システムをアップグレード前と同じ状態に戻せるようになります。たとえば、ReaR (Relax-and-Recover) ユーティリティーを使用できます。詳細は、ReaR のドキュメント および「Relax and Recover(ReaR) の概要」を参照してください。または、LVM スナップショット または RAID 分割 を使用することもできます。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。
1.3. アップグレード前のレポートの確認
システムのアップグレード可能性を評価するには、leapp preupgrade
コマンドでアップグレード前のプロセスを開始します。このフェーズでは、Leapp
ユーティリティーがシステムに関するデータを収集し、アップグレードの可能性を評価し、アップグレード前のレポートを生成します。
アップグレード前のレポートは、/var/log/leapp/leapp-report.txt
ファイルと Web コンソールの両方で利用できます。レポートは潜在的な問題を要約し、推奨される解決策を提案します。このレポートは、アップグレードを進めることが可能かどうかの判断にも役立ちます。
アップグレード前のフェーズでアップグレード可能性を評価するには、以下のオプションがあります。
-
生成された
leapp-report.txt
ファイルのアップグレード前レポートを確認し、コマンドラインインターフェースを使用して、報告された問題を手動で解決します。 - Web コンソールを使用してレポートを確認し、利用可能な場合は自動修復を適用し、推奨される修復ヒントを使用して残りの問題を修正します。
アップグレード前のフェーズでは、Leapp
がインプレースアップグレードプロセス全体をシミュレートしたり、すべての RPM パッケージをダウンロードしません。
アップグレード前のレポートを確認すると、インプレースアップグレードプロセスなしで RHEL 8 システムを再デプロイする必要がある場合にも役立ちます。
1.4. コマンドラインからのアップグレード可能性の評価
コマンドラインインターフェースを使用して、アップグレード前のフェーズで潜在的なアップグレードの問題を特定します。
前提条件
- 「アップグレードに向けて RHEL 7 システムの準備」に記載されている手順を完了している。
手順
RHEL 7 システムで、アップグレード前のフェーズを別途実行します。
# leapp preupgrade
注記アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合は、
--no-rhsm
オプションを追加します。-
/var/log/leapp/leapp-report.txt
ファイルのレポートを調べて、インプレースアップグレードに進む前に、報告されたすべての問題を手動で解決します。
1.5. Web コンソールでアップグレードの可能性の評価および自動修復の適用
アップグレード前のフェーズで潜在的な問題と、Web コンソールを使用して自動修復を適用する方法を特定します。
前提条件
- 「アップグレードに向けて RHEL 7 システムの準備」に記載されている手順を完了している。
手順
cockpit-leapp
プラグインをインストールします。# yum install cockpit-leapp
-
ブラウザーで Web コンソールに移動し、
root
または十分な権限を持つユーザーでログインします。Web コンソールの詳細は、「RHEL 7 Web コンソールを使用したシステムの管理」を参照してください。 RHEL 7 システムで、コマンドラインインターフェースまたは Web コンソールの端末からアップグレード前のフェーズを実行します。
# leapp preupgrade
注記アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合は、
--no-rhsm
オプションを追加します。Web コンソールで、左側のメニューから
を選択します。図1.1 Web コンソールのインプレースアップグレードレポート
レポートの表には、見つかった問題の概要、リスク評価、および修復 (利用可能な場合) が記載されています。
リスク要因:
- 高 - システム状態が悪化する可能性が非常に高い
- 中 - システムとアプリケーションの両方に影響を与える可能性がある
- 低 - システムに影響はないが、アプリケーションに影響を与える可能性がある
- インヒビター - アップグレードプロセスを抑制 (ハードストップ) する。抑制しないと、システムが起動できず、アクセスできず、または機能しなくなる可能性があります。
修復 - 報告された問題に対する実行可能な解決策
- 修復コマンド - Web コンソールから直接実行可能
- 修復のヒント - 問題を手動で解決する方法の手順
レポートの内容を調べます。ヘッダーをクリックして、テーブルを並べ替えることができます。詳細ペインを開くには、選択した行をクリックします。
図1.2 詳細ペイン
詳細ペインには、次の追加情報が表示されます。
- 問題の概要と、問題を詳細に説明するナレッジベース記事へのリンク
- 修復 - 自動修復 (利用可能な場合) を実行またはスケジュールし、適用時にその結果を確認できます。
- 影響を受けるシステムリソース: パッケージ、リポジトリー、ファイル (構成、データ)、ディスク、ボリューム
必要に応じて、結果をフィルタリングします。レポートの左上隅にある
ボタンをクリックし、設定に基づいてフィルターを適用します。フィルターカテゴリーは、相互に関連して適用されます。図1.3 フィルター
自動修復を適用する問題を選択します。2 つのオプションがあります。
- 詳細ペインの ボタンをクリックして、個々の項目を選択します。また、詳細ペインで をクリックして、個々の修正を直接実行できます。
- レポートの右上隅にある ボタンをクリックして、修復が利用可能なすべての項目を選択します。
レポートの右上隅にある
リンクをクリックして、修復計画を開きます。修復計画には、実行した修復、または予定されている修復の一覧が示されます。図1.4 修復計画
- 修復の一意の ID
- コマンドの終了ステータス
- 実行された修復の経過時間
- 標準出力
- 標準エラー
-
選択した修復を実行した後に、
leapp preupgrade
コマンドを使用してアップグレード前のレポートを再生成し、新しいレポートを調べてから、必要に応じて追加の修復手順を実行します。
1.6. RHEL 7 から RHEL 8 へのアップグレードの実行
Leapp
ユーティリティーを使用して RHEL 8 にアップグレードします。
前提条件
- 「アップグレードに向けて RHEL 7 システムの準備」の手順 (システム全体のバックアップも含む) が完了している。
- 「アップグレード前のレポートの確認」に記載されている手順を完了し、報告されたすべての問題が解決されている。
手順
RHEL 7 システムで、アップグレードプロセスを開始します。
# leapp upgrade
注記アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp upgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合は、
--no-rhsm
オプションを追加します。アップグレードプロセスの開始時、
Leapp
は、「アップグレード前のレポートの確認」で説明されているアップグレード前のフェーズを実行します。システムをアップグレードできる場合は、
Leapp
が必要なデータをダウンロードし、アップグレード用の RPM トランザクションを作成します。システムで、信頼できるアップグレードの設定要因が満たされていない場合は、
Leapp
がアップグレードプロセスを中止し、問題を説明する記録と、推奨される解決策を/var/log/leapp/leapp-report.txt
ファイルに出力します。詳細は 3章トラブルシューティング を参照してください。システムを手動で再起動します。
# reboot
このフェーズでは、システムが RHEL 8 ベースの初期 RAM ディスクイメージ initramfs で起動します。
Leapp
は、すべてのパッケージをアップグレードして、自動的に RHEL 8 システムを再起動します。または、
--reboot
オプションを指定してleapp upgrade
コマンドを実行し、この手動の手順を省略することもできます。失敗した場合は、3章トラブルシューティング の説明に従ってログを調べてください。
- RHEL 8 システムにログインし、「RHEL 8 システムのアップグレード後の状態の確認」の説明に従ってその状態を確認します。
- セキュリティポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は2章セキュリティーポリシーの適用を参照してください。
1.7. RHEL 8 システムのアップグレード後の状態の確認
この手順は、RHEL 8 へのインプレースアップグレード後に実行が推奨される手順を紹介します。
前提条件
- 「RHEL 7 から RHEL 8 へのアップグレードの実行」の手順に従ってシステムをアップグレードし、RHEL 8 にログインできる。
手順
アップグレードが完了したら、システムが必要な状態になっていることを確認します。少なくとも以下の確認を行います。
現在のオペレーティングシステムのバージョンが Red Hat Enterprise Linux 8 であることを確認します。
# cat /etc/redhat-release Red Hat Enterprise Linux release 8.2 (Ootpa)
オペレーティングシステムのカーネルバージョンを確認します。
# uname -r 4.18.0-193.el8.x86_64
.el8
が重要です。Red Hat Subscription Manager を使用している場合:
正しい製品がインストールされていることを確認します。
# subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: 8.2 Arch: x86_64 Status: Subscribed
リリースバージョンが 8.2 に正しく設定されていることを確認します。
# subscription-manager release Release: 8.2
リリースのバージョンが 8.2 に設定されている場合は、この特定のバージョンの RHEL に対してのみ yum 更新を受け取ります。RHEL 8 の最新のマイナーバージョンからの更新を利用できるように、リリースバージョンの設定を解除する場合は、次のコマンドを使用します。
# subscription-manager release --unset
- ネットワークサービスが機能していることを確認します。たとえば、SSH を使用してサーバーに接続します。
- アプリケーションのアップグレード後のステータスを確認します。場合によっては、移行や設定を手動で変更しないといけない場合があります。たとえば、データベースを移行するには、RHEL 8 データベースサーバーのドキュメント の説明に従ってください。
第2章 セキュリティーポリシーの適用
インプレースアップグレードプロセスでは、特定のセキュリティーポリシーを無効にしたままにする必要があります。さらに、RHEL 8 ではシステム全体の暗号化ポリシーという概念が新たに導入され、セキュリティープロファイルにはメジャーリリース間の変更が含まれる可能性があります。本セクションでは、アップグレードした RHEL システムのセキュリティーを保護する方法を説明します。
2.1. SELinux モードの Enforcing への変更
Leapp
ユーティリティーは、インプレースアップグレードプロセス時に SELinux モードを Permissive に設定します。システムが正常にアップグレードされたら、手動で SELinux モードを Enforcing に変更する必要があります。
前提条件
- システムがアップグレードされ、「RHEL 8 システムのアップグレード後の状態の確認」で説明されている検証手順を実行している。
手順
ausearch
ユーティリティーなどを使用して、SELinux 拒否がないことを確認します。# ausearch -m AVC,USER_AVC -ts boot
前述の手順では、最も一般的なシナリオのみが扱われることに注意してください。可能な SELinux 拒否をすべて確認するには、完全な手順を説明する『SELinux の使用』の「SELinux 拒否の特定」セクションを参照してください。
任意のテキストエディターで
/etc/selinux/config
ファイルを開きます。以下に例を示します。# vi /etc/selinux/config
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
変更を保存して、システムを再起動します。
# reboot
検証手順
システムの再起動後に、
getenforce
コマンドがEnforcing
を返すことを確認します。$ getenforce Enforcing
2.2. システム全体の暗号化ポリシーの設定
暗号ポリシーは、コア暗号化サブシステムを構成するシステムコンポーネントで、TLS、IPSec、SSH、DNSSec、および Kerberos の各プロトコルに対応します。
インストールまたはインプレースアップグレードプロセスに成功すると、システム全体の暗号化ポリシーは自動的に DEFAULT
に設定されます。DEFAULT
のシステム全体の暗号化ポリシーレベルで、現在の脅威モデルに対して安全なものです。
現在のシステム全体の暗号化ポリシーを表示または変更するには、update-crypto-policies tool ツールを使用します。
$ update-crypto-policies --show
DEFAULT
たとえば、以下のコマンドは、システム全体の暗号化ポリシーレベルを FUTURE
に切り替えます。これで、近い将来の攻撃に耐えられるはずです。
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
RHEL 8.2 では、システム全体の暗号化ポリシーのカスタマイズが利用できます。詳細は「ポリシー修飾子を使用したシステム全体の暗号化ポリシーのカスタマイズ」および「システム全体のカスタム暗号化ポリシーの作成および設定」を参照してください。
関連情報
- システム全体の暗号化ポリシーの使用
-
update-crypto-policies(8)
の man ページ。
2.3. セキュリティーベースラインへのシステムの修復
OpenSCAP スイートは、システムが PCI-DSS、OSPP、ACSC E8 などのセキュリティーベースラインに準拠する修正を提供します。以下の手順に従って、PCI-DSS プロファイルに準拠するようにシステム設定を変更します。
Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修正は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。
前提条件
-
RHEL 8 システムに、
scap-security-guide
パッケージがインストールされている。
手順
oscap
コマンドに--remediate
オプションを指定して使用します。# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
前述の例の pci-dss は、シナリオに必要なプロファイルに置き換えることができます。
システムを再起動します。
# reboot
検証手順
そのシステムが PCI-DSS プロファイルにどのように準拠しているかを評価し、結果を pcidss_report.html ファイルに保存します。
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
関連情報
-
詳細は「セキュリティーコンプライアンスおよび脆弱性スキャンの開始」 と、man ページの
scap-security-guide(8)
およびoscap(8)
を参照してください。
第3章 トラブルシューティング
本章では、トラブルシューティングに使用するリソースおよびヒントを紹介します。
3.1. トラブルシューティングのリソース
以下のトラブルシューティングリソースを参照してください。
コンソールの出力
デフォルトでは、Leapp
ユーティリティーにより、エラーおよび重要なログレベルメッセージのみがコンソールに出力されます。ログレベルを変更するには、leapp upgrade
コマンドで --verbose
オプションまたは --debug
オプションを使用します。
-
verbose モードでは、
Leapp
により情報、警告、エラー、および重要なメッセージが出力されます。 -
debug モードでは、
Leapp
によりデバッグ、情報、警告、エラー、および重要なメッセージを出力します。
ログ
-
/var/log/leapp/leapp-upgrade.log
ファイルには、initramfs フェーズで見つかった問題が記載されます。 -
/var/log/leapp/dnf-debugdata/
ディレクトリーには、トランザクションのデバッグデータが含まれます。このディレクトリーは、leapp upgrade
コマンドに--debug
オプションを使用して実行した場合に限り表示されます。 -
journalctl
ユーティリティーでは、すべてのログが出力されます。
レポート
-
/var/log/leapp/leapp-report.txt
ファイルには、アップグレード前のフェーズで見つかった問題が記載されます。レポートは、Web コンソールでも利用できます (「Web コンソールでアップグレードの可能性の評価および自動修復の適用」を参照)。
3.2. トラブルシューティングのヒント
以下のトラブルシューティングのヒントを参照してください。
アップグレード前のフェーズ
- システムが、「アップグレードの計画」に記載される条件をすべて満たしていることを確認します。
-
「アップグレードに向けて RHEL 7 システムの準備」に記載されているすべての手順を行ってください。たとえば、システムで、カーネル (
eth
) が使用する接頭辞に基づいた名前を持つ NIC (Network Interface Card) を複数使用しないようにします。 -
アップグレード前のレポートで特定されたすべての問題は、
/var/log/leapp/leapp-report.txt
にあることを確認してください。これを行うには、「Web コンソールでアップグレードの可能性の評価および自動修復の適用」の説明に従って Web コンソールを使用することもでき ます。
ダウンロードフェーズ
-
RPM パッケージのダウンロード中に問題が発生した場合は、
/var/log/leapp/dnf-debugdata/
ディレクトリーにあるトランザクションデバッグデータを調べてください。
initramfs フェーズ
このフェーズでは、潜在的な失敗により Dracut シェルにリダイレクトされます。ジャーナルを確認してください。
# journalctl
あるいは、
reboot
コマンドを実行して、Dracut シェルからシステムを再起動し、/var/log/leapp/leapp-upgrade.log
ファイルを確認します。
アップグレード後のフェーズ
- 一見、システムが正常にアップグレードしていても、古い RHEL 7 カーネルでシステムが起動する場合は、システムを再起動して、GRUB でデフォルトエントリーのカーネルバージョンを確認します。
- 「RHEL 8 システムのアップグレード後の状態の確認」で推奨される手順を行います。
SELinux を Enforcing モードに切り替えてから、アプリケーションやサービスが停止したり、適切に動作しなかったりした場合は、ausearch、journalctl、dmesg のいずれかのユーティリティーで、サービスの拒否を検索します。
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
最も一般的な問題は、ラベルが間違っていることにより発生します。詳細は「Troubleshooting problems related to SELinux」を参照してください。
3.3. 既知の問題
- 現在、ネットワークチーミングは、Network Manager を無効にするかインストールしていない場合にインプレースアップグレードを実行すると動作しません。
-
HTTP プロキシーを使用する場合は、Red Hat Subscription Manager がこのようなプロキシーを使用するように設定するか、
--proxy <hostname>
オプションでsubscription-manager
コマンドを実行する必要があります。そうでない場合は、subscription-manager
コマンドの実行に失敗します。設定変更の代わりに--proxy
オプションを使用する場合は、Leapp
がプロキシーを検出できないため、アップグレードプロセスが失敗します。この問題が発生しないようにするには、「Red Hat Subscription Management に HTTP プロキシを設定する」の説明に従ってrhsm.conf
ファイルを手動で編集します。(BZ#1689294) -
RHEL 7 システムが FCoE 論理ユニット番号 (LUN) にインストールされ、
bnx2fc
ドライバーを使用するネットワークカードに接続している場合、その LUN はアップグレード後に RHEL 8 で検出されません。したがって、アップグレードしたシステムは起動できません。(BZ#1718147) -
RHEL 7 システムで、Red Hat が提供しているにもかかわらず RHEL 8 で利用できないデバイスドライバーを使用している場合は、
Leapp
でアップグレードが行われません。ただし、RHEL 7 システムが、削除されたドライバーのリスト (/etc/leapp/repos.d/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt
) に含まれていないサードパーティーのデバイスドライバーを使用している場合、Leapp
はそのようなドライバーを検出しないため、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。
この時点では、Samba モジュールの
winbind
およびwins
が/etc/nsswitch.conf
ファイルで使用されていると、インプレースアップグレードを実行できません。このシナリオでは、アップグレードトランザクションが失敗して次のエラーが表示され、Leapp
によりアップデートが行われません。upgrade[469]: STDERR: upgrade[469]: Error in PREIN scriptlet in rpm package unbound-libs upgrade[469]: Error: Transaction failed upgrade[469]: Container el8userspace failed with error code 1. unbound-libs has a PREIN failure
この問題を回避するには、更新時に、データベース
user
、groups
、およびhosts
にのみローカルプロバイダーを使用できるようにシステムを設定します。-
システムの設定ファイル
/etc/nsswitch.conf
を開き、winbind
文字列またはwins
文字列を含むエントリーを検索します。 -
そのようなエントリーを確認するには、
/etc/nsswitch.conf
のバックアップを作成します。 -
/etc/nsswitch.conf
を編集し、winbind
またはwins
を含むエントリーからそれらを削除します。 - インプレースアップグレードを実行します。
アップグレードを行ったら、システムの設定要件に従って、
winbind
文字列およびwins
文字列を、/etc/nsswitch.conf
の各エントリーに追加します。(BZ#1410154)
-
システムの設定ファイル
Leapp
ユーティリティーは、アップグレードプロセス時にカスタマイズされた認証設定を変更しません。非推奨のauthconfig
ユーティリティーを使用して RHEL 7 システムで認証を構成した場合は、RHEL 8 での認証が正しく機能しない場合があります。RHEL 8 システムでカスタム構成が正しく機能するようにするには、authselect
ユーティリティを使用して RHEL 8 システムを再構成します。重要インプレースアップグレード中に、非推奨のプラグ可能認証モジュール (PAM) の
pam_krb5
またはpam_pkcs11
が削除されます。したがって、RHEL 7 システムの PAM 構成に、pam_krb5
モジュールまたはpam_pkcs11
モジュールが含まれ、これらのモジュールに必要不可欠
または必須
の制御値がある場合は、インプレースアップグレードを実行すると、システムからロックアウトされる可能性があります。この問題を回避するには、アップグレードプロセスを開始する前に、RHEL 7 システムを再構成して、pam_krb5
またはpam_pkcs11
を使用しないようにします。
-
IBM Zシステムでは、
Leapp
では、DASD ディスクが常に接続されていることが必要になります。したがって、/etc/dasd.conf
ファイルが存在しない場合、インプレースアップグレードは失敗します。この問題を回避するには、touch > /etc/dasd.conf
コマンドを使用して、空のdasd.conf
ファイルを作成します。(BZ#1783248) お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージと同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードする前に、以下のいずれかのオプションを選択します。
- サードパーティーパッケージの削除
- サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
-
インプレースアップグレード時に、
docker
パッケージは警告なしに削除されます。RHEL でコンテナーを使用する場合は、RHEL 8 にアップグレードする前に Podman に移行してください。(BZ#1858711)
3.4. サポートの利用
サポートケースを作成するには、製品で RHEL 8 を選択し、システムの sosreport
を添付します。
-
システムで
sosreport
を生成するには、次のコマンドを実行します。
# sosreport
ケース ID は空のままにできます。
sosreport を生成する方法は、ナレッジベースのソリューション「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。
カスタマーポータルでサポートケースを作成し、管理する方法は、ナレッジベースのアーティクル「カスタマーポータルでサポートケースを作成および管理する」を参照してください。
付録A RHEL 7 リポジトリー
アップグレードの前に、「アップグレードに向けて RHEL 7 システムの準備」の手順 3 で説明されているように、適切なリポジトリーを有効になっていることを確認してください。
アップグレード時に Red Hat Subscription Manager を使用する予定がある場合には、subscription-manager repos --enable repository_id
コマンドを使用して、アップグレードの前に以下のリポジトリーを 有効にする必要があります。
アーキテクチャー | リポジトリー | リポジトリー ID |
---|---|---|
64 ビット Intel | Base |
|
Extras |
| |
64 ビット ARM | Base |
|
Extras |
| |
IBM POWER8 (リトルエンディアン) | Base |
|
Extras |
| |
IBM POWER9 (リトルエンディアン) | Base |
|
Extras |
| |
IBM Z | Base |
|
Extras |
| |
IBM Z (Structure A) | Base |
|
Extras |
|
次のリポジトリーは、アップグレード前に subscription-manager repos --enable repository_id
コマンドを使用して 有効にできます。
アーキテクチャー | リポジトリー | リポジトリー ID |
---|---|---|
64 ビット Intel | 任意 |
|
Supplementary |
| |
64 ビット ARM | 任意 |
|
Supplementary | 該当なし | |
IBM POWER8 (リトルエンディアン) | 任意 |
|
Supplementary |
| |
IBM POWER9 (リトルエンディアン) | 任意 |
|
Supplementary |
| |
IBM Z | 任意 |
|
Supplementary |
| |
IBM Z (Structure A) | 任意 |
|
Supplementary | 該当なし |
インプレースアップグレードの前に RHEL 7 Optional または RHEL 7 Supplementary リポジトリーを有効にすると、Leapp
は、RHEL 8 CodeReady Linux Builder リポジトリーまたは RHEL 8 Supplementary リポジトリーをそれぞれ有効にします。
カスタムリポジトリーを使用する場合は、「Configuring custom repositories」の指示に従って、カスタムリポジトリーを有効にします。
法律上の通知
このページには機械翻訳が使用されている場合があります (詳細はこちら)。