9.4. RHEL 8.8 から RHEL 9.2 へのアップグレードに関する既知の問題
以下は、RHEL 8.8 から RHEL 9.2 にアップグレードする際に発生する可能性のある既知の問題です。
- 現在、ネットワークチーミングは、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 8 システムが、Red Hat が提供しているにもかかわらず RHEL 9 で利用できないデバイスドライバーを使用している場合、
Leappはアップグレードを行いません。ただし、RHEL 8 システムが、Leappが/etc/leapp/files/device_driver_deprecation_data.jsonファイルにデータを持たないサードパーティーのデバイスドライバーを使用している場合、Leappはそのようなドライバーを検出せず、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。 お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージの名前と同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードする前に、以下のいずれかのオプションを選択します。
- サードパーティーパッケージの削除
- サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
- RHEL 8 では、VDO マネージャーまたは論理ボリュームマネージャー (LVM) を使用して、Virtual Data Optimizer (VDO) ボリュームを管理できます。RHEL 9 では、LVM を使用した VDO ボリュームの管理のみが可能です。RHEL 9 で VDO 管理のボリュームを引き続き使用するには、アップグレード前にそれらのボリュームを LVM 管理の VDO ボリュームにインポートします。詳細は、LVM への既存 VDO ボリュームのインポート を参照してください。
- インプレースアップグレードは、ソフトウェア Redundant Array of Independent Disks (RAID) を備えたシステムでは失敗する可能性があります。(BZ#1957192)
Leappユーティリティーは通常、インプレースアップグレード時に、RHEL 8 と RHEL 9 の間のネットワークインターフェイスコントローラー (NIC) 名を保持します。ただし、ネットワークボンディングを持つシステムなど、一部のシステムでは、RHEL 8 と RHEL 9 の間で NIC 名を更新する必要がある場合があります。これらのシステムで、以下の手順を実行します。-
Leapp ユーティリティーが元の RHEL 8 の NIC 名を誤って保持しないように、
LEAPP_NO_NETWORK_RENAMING=1環境変数を設定します。 - インプレースアップグレードを実行します。
ネットワークが正常に機能していることを確認します。必要に応じて、ネットワーク設定を手動で更新します。
(BZ#1919382)
-
Leapp ユーティリティーが元の RHEL 8 の NIC 名を誤って保持しないように、
- 利用可能なディスク容量が十分にない場合には、インプレースアップグレードが失敗する可能性があります。エラーメッセージとログには、問題および解決に関する誤解を招く情報や無効な情報が含まれる場合があります。この問題を解決するには、leapp fails with "There is not enough space on the file system hosting /var/lib/leapp directory to extract the packages" を参照してください。(BZ#1832730、BZ#2210300)
BIOS を使用してシステムを起動する場合は、コアイメージのインストールに十分な領域が、ブートディスクの埋め込み領域に含まれていないと、GRUB2 ブートローダーをアップグレードするときにインプレースアップグレードが失敗します。これによりシステムが破損し、RHEL 6
fdiskユーティリティーなどを使用してディスクが手動でパーティション分割された場合に発生する可能性があります。この問題がユーザーに影響するかどうかを確認するには、以下の手順を実行します。インストールされたブートローダーを使用してディスク上の最初のパーティションを開始するセクターを決定します。
# fdisk -lコアイメージに十分なスペースを確保する標準のパーティショニングは、セクター 2048 から始まります。
開始セクターに十分なスペースがあるかどうかを判断します。RHEL 9.0 コアイメージには少なくとも 36 KiB が必要です。たとえば、セクターサイズが標準の 512 バイトの場合、セクター 73 以下から開始すると十分なスペースが得られません。
注記RHEL 9 コアイメージは 36 KiB より大きい場合があり、開始セクターの値を高く指定しなければいけない可能性があります。現在の RHEL 9 コアに必要な領域を常に確認してください。
埋め込み領域に十分なストレージ領域が含まれていない場合は、インプレースアップグレードを実行する代わりに、RHEL 9 システムの新規インストールを実行します。
(BZ#2181380)
インプレースアップグレード後、システムが以下の条件を満たす場合、SSH キーは自動生成されなくなりました。
- システムがクラウド上にあります。
- cloud-init パッケージがインストールされている。
ssh_genkeytypes 設定は、/etc/cloud/cloud.cfg ファイルで ~ に設定されます。これはデフォルトです。
この問題により、元のキーが削除された場合にシステムが SSH を使用して接続できなくなります。この問題を回避するには、ナレッジベースソリューション Unable to SSH to new Virtual Machine after upgrading the template to RHEL 8.7 or 9 を参照してください。(BZ#2210012)
マウントされているファイルシステムが多すぎると、アップグレード前のプロセスが失敗し、次のエラーメッセージが表示される可能性があります。
OperationalError: unable to open database file
この問題が発生した場合は、以下の手順を実行します。
- システムパーティションに関係がなく、アップグレードプロセス中に必要のないファイルシステムをすべてアンマウントします。
-
/etc/fstabファイルのアンマウントされたファイルシステムのエントリーをコメントアウトして、アップグレードプロセス中にマウントされないようにします。 アップグレード後に元のファイルシステム設定を復元します。
- * 現在、ARM アーキテクチャーを持つ Amazon Web Services (AWS) 上で Red Hat Update Infrastructure (RHUI) を使用してインプレースアップグレードを実行すると、問題が発生します。代わりに Red Hat Subscription Management (RHSM) を使用してください。(RHEL-38909)
