5 Oracle Linuxのアップグレードのトラブルシューティング

この章では、トラブルシューティング情報を提供し、アップグレード・プロセスに影響する可能性のある既知の問題について説明します。

トラブルシューティングのためのツール

次のオプションを使用して、アップグレード前のレポートの生成時または実際のアップグレードの実行時に、さらに出力を生成します。

• --verboseは、警告、エラー・メッセージおよびその他の重要な情報を表示します。

• --debugは、--verboseオプションと同じ出力に加えてデバッグ情報を追加します。

トラブルシューティング情報を取得するために、次のリソースとツールを使用できます。

• /var/log/leapp/leapp-report.txt

• /var/log/leapp/leapp-upgrade.log

• /var/log/leapp/dnf-debugdata/: デバッグ情報のディレクトリ。なお、このディレクトリは、preupgradeまたはupgradeコマンドの発行時に--debugオプションを使用した場合にのみ作成されます。

• journalctlコマンド

既知の問題

Oracle Linux 8システムをOracle Linux 9にアップグレードする際に発生する可能性がある既知の問題を次に示します。

アップグレードの問題

• オプションのResilient StorageグループがLeappでサポートされていない

  Leappでは、オプションのResilient Storageグループはサポートされていません。そのグループの特定のパッケージがシステムに存在すると、leappのアップグレードが完了しなくなる可能性があります。

  たとえば、Resilient Storageグループにはlvm2-clusterパッケージが含まれています。Oracle Linux 8インストールでは、オプションで、このパッケージをインフラストラクチャ・サーバーおよびファイル・プロファイル、またはプリント・サーバー・プロファイルの一部として追加できます。ただし、このパッケージは阻害要因であり、Leappのアップグレードが失敗する原因となります。

  バグID 33573562

• インストール対象としてマークされている不足パッケージがLeappによってレポートされることがある

  /var/log/leapp/leapp-preupgrade.logまたは/var/log/leapp/leapp-upgrade.logファイルで、次のような警告がレポートされることがあります:

  Warning: Packages marked by Leapp for install not found in repositories 
  metadata: rpcgen python3-pyxattr libnsl2-devel rpcsvc-proto-devel

  これらのパッケージは、開発者リポジトリであるOracle Linux9 Codeready Builderリポジトリ内にあり、デフォルトでは無効になっています。

  システムでこれらのパッケージが必要な場合は、アップグレード前またはアップグレード・フェーズの間に、--enablerepo ol9_codeready_builderオプションを適切なLeappコマンドに追加します。次に例を示します。

  sudo leapp upgrade --oraclelinux --enablerepo ol9_codeready_builder

  Leappによるアップグレードの間に有効になったリポジトリが、アップグレード完了後もOracle Linux 9システム上で有効なままになります。

  または、アップグレードの完了後、dnfコマンドを使用して、インストールに必要なパッケージを手動でインストールできます。

  バグID 32827043

• 一部のel8パッケージがアップグレードされないことがある

  前の項目で示したのと同じ、MySQL関連の*.el8パッケージを検出するrpm -qaコマンド構文で、システム上のアップグレードされなかったその他の*el8パッケージも一覧表示されることがあります。開発者リポジトリなど、Leappでサポートされていないリポジトリからインストールされたパッケージは、アップグレードされない可能性があります。そのようなパッケージの場合、次を実行します。

  1. https://yum.oracle.comにアクセスして、必要なパッケージが含まれているOracle Linux 9リポジトリを確認します。

  2. アップグレードが完了したら、それらのOracle Linux 9リポジトリからそのパッケージを手動でインストールします。

  3. 必要なすべてのパッケージがインストールされたら、残っているel8パッケージをシステムから削除します。

  バグID 32878386

• (aarch64)アップグレード・ログでvmdモジュール関連のエラーがレポートされることがある

  aarch64システムでのアップグレードの完了後に、Leappのアップグレード・ログで次のメッセージがレポートされることがあります。

  dracut-install: Failed to find module 'vmd'

  VMDモジュールはArmアーキテクチャには適用されないため、このエラー・メッセージは無視してかまいません。

  バグID 34172552

• 従来のディレクトリ/var/runを参照するエラーがレポートされた

  アップグレード中に、/var/runディレクトリを参照する次のようなメッセージがレポートされます。

    Installing       :
  leapp-upgrade-el8toel9-0.16.0-6.0.3.el8_6.20220810014405.8fa95c0.noarch      
                                                     6/6
    Running scriptlet:
  leapp-upgrade-el8toel9-0.16.0-6.0.3.el8_6.20220810014405.8fa95c0.noarch      
                                                     6/6
  [/usr/lib/tmpfiles.d/dnssec-trigger.conf:1] Line references path below legacy
  directory /var/run/, updating /var/run/dnssec-trigger → /run/dnssec-trigger;
  please update the tmpfiles.d/ drop-in file accordingly.
  .
  .
  .

  これらのメッセージは無視できます。アップグレードまたはパッケージのインストールは正常に完了します。

  代替の回避策として、メッセージ内の指示に従って構成を更新し、従来の/var/run/*ディレクトリ・パスを/run/*に変更できます。

  バグID 34491952

• Oracle Linux 8からOracle Linux 9へのアップグレード時に署名されていないパッケージが警告を生成する

  この問題は、Oracle Linux 7からアップグレードされ、後でOracle Linux 9にアップグレードされるOracle Linux 8システムに適用されます。

  Leappを使用してOracle Linux 7システムをOracle Linux 8にアップグレードすると、署名されていないパッケージのkernel-workaround-0.1-1.el8.src.rpmがアップグレード・プロセスの一部としてインストールされます。Leappのアップグレードは正常に完了しましたが、パッケージについて通知されません。

  後でLeappを実行してこの同じシステムをOracle Linux 9にアップグレードした場合、今回はアップグレード・プロセスでパッケージの存在が検出され、次のように/var/log/leapp/leapp-report.txtで警告が生成されます:

  ----------------------------------------
  Risk Factor: high
  Title: Packages not signed by Oracle found on the system
  Summary: The following packages have not been signed by Oracle and may be
  removed during the upgrade process in case Oracle-signed packages to be
  removed during the upgrade depend on them:
  - gpg-pubkey
  - kernel-workaround
  Key: f5a5d58476a97bf0a8904d00df5d1321189849ad
  ----------------------------------------

  メッセージは無視できます。パッケージによってアップグレードの完了が妨げられることはありません。

  (バグID 35343479)

システム管理の問題

• Ksplice Uptrackソフトウェアでエラー・メッセージが表示される

  アップグレード中に、Oracle Ksplice Uptrackソフトウェアで次のようなエラーがレポートされることがあります。

  [ 256.033527] upgrade[390]: Upgrading : uptrack-1.2.80-0.el9.noarch 577/1453
  [ 256.037151] upgrade[390]: Running scriptlet: uptrack-1.2.80-0.el9.noarch 577/1453
  ...
  [ 256.045914] upgrade[390]: Traceback (most recent call last):
  [ 256.049230] upgrade[390]: File "/usr/lib/uptrack/access-key-from-uln", line 9, in <module>
  [ 256.051376] upgrade[390]: from up2date_client import up2dateAuth, rpcServer
  [ 256.056490] upgrade[390]: File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 74
  [ 256.059251] upgrade[390]: os.chmod(path, 0600)
  [ 256.060997] upgrade[390]: 
  [ 256.062842] upgrade[390]: SyntaxError: invalid token

  このレポートは、既知の無害な問題であるため無視してかまいません。アップグレードが完了すると、Kspliceは正常に動作し続けます。

ファイル・システムとストレージの問題

• RAID構成にBtrfsがあるシステムはアップグレードできない

  RAID構成でBtrfsファイル・システムが使用されているシステムは、アップグレードできません。preupgradeコマンドによって生成された/var/log/leapp/leapp-report.txtでは、この構成は阻害要因としてフラグ付けされ、処置は提供されません。システムをアップグレードし、その構成が検出されると、アップグレード・プロセスは停止します。

• winbindおよびwins Sambaモジュールが使用されている場合はアップグレードがブロックされる

  /etc/nsswitch.confでwinbindおよびwins Sambaモジュールが使用されている場合、アップグレードはブロックされます。回避策として、まずファイルからこれらのモジュールを削除して、アップグレードを実行します。アップグレードが完了したら、これらのモジュール・エントリをファイルに復元します。

  これらのモジュールの構成の詳細は、Oracle Linux 9 共有ファイル・システムの管理を参照してください。

• ネットワークにマウントされたファイル・システムがあるホストはアップグレードできない

  Leappでは、ネットワーク・ストレージ、NFSまたはiSCSIにマウントされたファイル・システムがあるシステムのアップグレードはサポートされていません。回避策として、ファイル・システムをアンマウントし、/etc/fstabのそれらのエントリをコメント・アウトします。アップグレードが完了したら、エントリを復元し、ファイル・システムを再マウントできます。

ネットワークの問題

• カーネルで使用されるNICと同じ接頭辞が付いた複数のNICがシステムにある場合はアップグレード・エラーが発生する可能性がある

  アップグレードするシステムに、カーネルで使用されているNICと同じ接頭辞(ethなど)を共有する複数のNICがある場合は、インプレース・アップグレード・プロセスでエラーが発生することがあります。アップグレード後に、システムのネットワーク接続性が失われます。

  詳細は、『Oracle Linux 8 ネットワークの設定』の「ネットワーク・インタフェース名について」を参照してください。

• NetworkManagerがアップグレード完了後に起動されないことがある

  アップグレード後、システムのNetworkManagerが、その名前解決サービスが失敗したことが原因で起動されない場合があります。この障害は、サービスのステータスを確認することによって確認できます。

  systemctl status systemd-resolved.service

  ● systemd-resolved.service - Network Name Resolution 
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; 
  disabled; > 
     Active: inactive (dead) 
       Docs: man:systemd-resolved.service(8) 
             https://www.freedesktop.org/wiki/Software/systemd/resolved

  /var/log/messagesファイルには、次のエラーも報告されます。

  dbus-daemon[742]: [system] Activation via systemd failed for unit 
  'dbus-org.freedesktop.resolve1.service': Unit 
  dbus-org.freedesktop.resolve1.service not found.

  この問題を解決するには、次のいずれかの回避策を選択します。

  • NetworkManagerを、systemd-resolved.serviceを使用しないように構成します。

    次のエントリを/etc/NetworkManager/conf.d/no-systemd-resolved.confファイルに追加します。

    [main]
    systemd-resolved=false

  • 次のようにsystemd-resolved.serviceを有効にします。

    systemctl enable systemd-resolved.service

    Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service → 
    /usr/lib/systemd/system/systemd-resolved.service. 
    Created symlink 
    /etc/systemd/system/multi-user.target.wants/systemd-resolved.service → 
    /usr/lib/systemd/system/systemd-resolved.service.

    systemctl start systemd-resolved.service

  特定の設定に使用しているネットワーク名解決モデルとより一貫性のある他の方法を採用することもできます。役立つ情報については、『Oracle Linux 9 ネットワークの設定』の「ネットワーク・インタフェース名について」を参照してください。

仮想化とコンテナの問題

• アップグレード後にKVM仮想マシンのスナップショットが一覧表示されないことがある

  アップグレード後に、libvirtdサービスにより、次のようなスナップショット関連のエラー・メッセージがレポートされることがあります。

  libvirtd[53328]: internal error: Failed to parse snapshot XML from file 
  '/var/lib/libvirt/qemu/snapshot/path-to-previous-snapshot-file'

  さらに、アップグレード前からの使用可能なスナップショットを一覧表示すると、空のリストが生成されます。

  sudo virsh snapshot-list previous-snapshot-file

   Name   Creation Time   State 
  -------------------------------

  回避策として、システムを再起動します。ブート・プロセスの最後に、スナップショットがリストされ、再度使用できるようになります。

• ネストされた仮想化構成ではlibvirtdサービスを再起動できないことがある

  ネストされた仮想化設定では、アップグレード後に、ネストされたKVMホストでlibvrtdサービスが再起動されないことがあります。

  回避策として、ネストされたKVMホストを再起動します。

• Oracle Linux 8 KVMホストのアップグレード時にパッケージのインストールの失敗がレポートされた

  KVMホストのアップグレード時に、ユーザー・スペース・パッケージのインストールに失敗します。このエラーは、アップグレード前フェーズで検出されることもあります。Leappユーティリティでは、次の例のようなメッセージでこの問題がレポートされます。

  Risk Factor: high
  Title: Unable to install RHEL 9 userspace packages
  Summary:
  ...
  Fatal glibc error: CPU does not support x86-64-v2
  ...

  このエラーは、仮想マシンのXMLファイルにcpu mode宣言がないために発生します。この問題を回避するステップは次のとおりです。

  1. 次のコマンドを実行します。

     sudo virsh edit vm-name

  2. 仮想マシンのXMLファイルに次の宣言を追加します。

     <cpu mode='host-model' check='partial'/>

  3. アップグレード前プロセスを再実行します。

  ノート:

  この問題は、Oracle Linux 9: リリース・ノートfor Oracle Linux 9に記載されている問題「Oracle Linux 9ホストでの起動時にKVM仮想マシンでパニックが発生する」に関連しています。

ハードウェア関連の問題

• 認識されないハードウェアがあるシステムはアップグレードできない

  e1000ドライバなどの特定のハードウェアに対するサポートがRHCK 8から始まるRHCKから削除されました。そのようなハードウェアがインストールされているプラットフォームでは、アップグレードを続行できません。UEKが引き続きハードウェアをサポートしていても、システムでハードウェアが検出された場合、アップグレード手順は抑制されます。

Leappオーバーレイ・サイズの問題

• アップグレードでオーバーレイ・サイズの拡張が必要なことがある

  多数のパッケージを含むOracle Linux 8システムをOracle Linux 9にアップグレードすると、アップグレード中に使用されるLeappオーバーレイ・ファイル・システム内の領域が不足しているために、失敗することがあります。次のエラーメッセージが表示されることがあります。

  Error: Transaction test error: 
    installing package package-name needs 4MB on the / filesystem 

  回避策として、LEAPP_OVL_SIZE変数を増やします。デフォルト・サイズは4096です。実際に必要なサイズは、設定に応じて大きくなることがあります。次のコマンドを使用します。

  sudo export LEAPP_OVL_SIZE=new-size

  注意:

  この変数に設定する新しいサイズは、ルート・パーティションで使用可能な領域の50を超えないようにする必要があります。

オープン・ファイル制限の値が低い問題

• アップグレードでオープン・ファイル制限の引上げが必要なことがある

  オープン・ファイル制限が低く設定されているOracle Linux 8システムをOracle Linux 9にアップグレードすると、失敗する可能性があります。アップグレード中に、次のエラー・メッセージ(または同様のメッセージ)が表示される場合があります:

  Traceback (most recent call last):
    File "/usr/lib/python3.6/site-packages/leapp/libraries/stdlib/__init__.py", line 185, in run
    File "/usr/lib/python3.6/site-packages/leapp/libraries/stdlib/call.py", line 199, in _call
    File "/usr/lib/python3.6/site-packages/leapp/libraries/stdlib/call.py", line 73, in _multiplex
    File "/usr/lib/python3.6/site-packages/leapp/libraries/stdlib/__init__.py", line 146, in _logfile_logging_handler
    File "/usr/lib64/python3.6/logging/__init__.py", line 1296, in debug
    File "/usr/lib64/python3.6/logging/__init__.py", line 1444, in _log
    File "/usr/lib64/python3.6/logging/__init__.py", line 1454, in handle
    File "/usr/lib64/python3.6/logging/__init__.py", line 1516, in callHandlers
    File "/usr/lib64/python3.6/logging/__init__.py", line 865, in handle
    File "/usr/lib/python3.6/site-packages/leapp/logger/__init__.py", line 40, in emit
    File "/usr/lib/python3.6/site-packages/leapp/logger/__init__.py", line 45, in _do_emit
    File "/usr/lib/python3.6/site-packages/leapp/utils/audit/__init__.py", line 87, in store
    File "/usr/lib/python3.6/site-packages/leapp/utils/audit/__init__.py", line 73, in get_connection
    File "/usr/lib/python3.6/site-packages/leapp/cli/commands/upgrade/util.py", line 36, in wrapper
    File "/usr/lib/python3.6/site-packages/leapp/utils/audit/__init__.py", line 60, in create_connection
    File "/usr/lib/python3.6/site-packages/leapp/utils/audit/__init__.py", line 27, in _initialize_database
  sqlite3.OperationalError: unable to open database file

  これは、Oracle Linux 9 ca-certificatesパッケージ内のファイルの数が増加したことが原因です。原則として、パッケージ化されたファイルの数が大幅に増加したパッケージが更新される場合も、同様の問題が発生する可能性があります。エラーは、Oracle Linux 9へのOracle Linuxインプレース・アップグレード中にleappがopen files制限に達したときに表示されます。

  回避策として、アップグレードを開始する前に、Oracle Linuxシステムのulimit open files変数を増やします。問題を引き起こすことがわかっている値は1024です。たとえば、次のコマンドでは、まだデフォルトのopen files制限を使用しているシステムが表示されます:

  ulimit -a | grep open
  open files                      (-n) 1024

  オープン・ファイル制限を10000に変更します。次を実行します:

  ulimit -Sn 10000

  変更が行われたことを確認します。たとえば、次のコマンドでは、open files制限が10000であるOracle Linuxシステムが表示されます:

  ulimit -a | grep open
  open files                      (-n) 10000