検索

9.2. トラブルシューティングのヒント

download PDF

以下のトラブルシューティングのヒントを参照してください。

アップグレード前のフェーズ

  • システムが アップグレードの計画 に記載されている条件をすべて満たしていることを確認してください。
  • アップグレードの準備 に記載されているすべての手順を実行してください。たとえば、システムで、カーネル (eth) が使用する接頭辞に基づいた名前を持つ NIC (Network Interface Card) を複数使用しないようにします。
  • /var/log/leapp/answerfile ファイルで、Leapp に必要な質問をすべて回答している。回答が見つからない場合は、Leapp によりアップグレードが行われません。以下に例を示します。

    • Are there no VDO devices on the system?
  • アップグレード前のレポートで特定されたすべての問題は、/var/log/leapp/leapp-report.txt にあることを確認してください。これを行うには、Web コンソールを介したアップグレードの可能性の評価および自動修復の適用 で説明されているように、Web コンソールを使用することもできます。

例9.1 Leapp answerfile

以下は、編集されていない /var/log/leapp/answerfile ファイルの例です。

[check_vdo]
# Title:              None
# Reason:             Confirmation
# ============================= check_vdo.confirm =============================
# Label:              Are all VDO devices, if any, successfully converted to LVM management?
# Description:        Enter True if no VDO devices are present on the system or all VDO devices on the system have been successfully converted to LVM management. Entering True will circumvent check of failures and undetermined devices. Recognized VDO devices that have not been converted to LVM management can still block the upgrade despite the answer.All VDO devices must be converted to LVM management before upgrading.
# Reason:             To maximize safety all block devices on a system that meet the criteria as possible VDO devices are checked to verify that, if VDOs, they have been converted to LVM management. If the devices are not converted and the upgrade proceeds the data on unconverted VDO devices will be inaccessible. In order to perform checking the 'vdo' package must be installed. If the 'vdo' package is not installed and there are any doubts the 'vdo' package should be installed and the upgrade process re-run to check for unconverted VDO devices. If the check of any device fails for any reason an upgrade inhibiting report is generated. This may be problematic if devices are dynamically removed from the system subsequent to having been identified during device discovery. If it is certain that all VDO devices have been successfully converted to LVM management this dialog may be answered in the affirmative which will circumvent block device checking.
# Type:               bool
# Default:            None
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
# confirm =

Label フィールドは、回答が必要な質問を指定します。この例では、質問は Are all VDO devices, if any, successfully converted to LVM management? です。

この質問に回答するには、最後の行をコメント解除し、回答として True または False を入力します。この例では、選択した回答は True です。

[check_vdo]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True

ダウンロードフェーズ

  • RPM パッケージのダウンロード中に問題が発生した場合は、/var/log/leapp/dnf-debugdata/ ディレクトリーにあるトランザクションデバッグデータを調べてください。

    注記

    /var/log/leapp/dnf-debugdata/ ディレクトリーは空であるか、トランザクションデバッグデータが生成されていない場合は存在しません。これは、必要なリポジトリーが利用できない場合に発生する可能性があります。

Initramfs フェーズ

  • このフェーズでは、潜在的な失敗により Dracut シェルにリダイレクトされます。ジャーナルを確認してください。

    # journalctl

    あるいは、reboot コマンドを実行して、Dracut シェルからシステムを再起動し、/var/log/leapp/leapp-upgrade.log ファイルを確認します。

アップグレード後のフェーズ

  • システムが正常にアップグレードされたように見えても、古い RHEL 8 カーネルで起動した場合は、システムを再起動して、GRUB でデフォルトエントリーのカーネルバージョンを確認してください。
  • アップグレード後の状態の確認 で推奨されている手順を必ず行ってください。
  • SELinux を Enforcing モードに切り替えてから、アプリケーションやサービスが停止したり、適切に動作しなかったりした場合は、ausearchjournalctldmesg のいずれかのユーティリティーで、サービスの拒否を検索します。

    # ausearch -m AVC,USER_AVC -ts boot
    # journalctl -t setroubleshoot
    # dmesg | grep -i -e selinux -e type=1400

    最も一般的な問題は、ラベルが間違っていることにより発生します。詳細は、Troubleshooting problems related to SELinux を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.