9.3. 既知の問題

以下は、RHEL 7 から RHEL 8 にアップグレードする際に発生する可能性のある既知の問題です。

  • 現在、ネットワークチーミングは、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 システムで、Red Hat が提供しているにもかかわらず RHEL 8 で利用できないデバイスドライバーを使用している場合は、Leapp でアップグレードが行われません。ただし、RHEL 7 システムが、Leapp/etc/leapp/files/device_driver_deprecation_data.json ファイルにデータを持たないサードパーティーのデバイスドライバーを使用している場合、Leapp はそのようなドライバーを検出せず、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。
  • /etc/nsswitch.conf ファイルで winbind および wins Samba モジュールが使用されている場合は、インプレースアップグレードを実行できません。このシナリオでは、アップグレードトランザクションが失敗して次のエラーが表示され、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

    この問題を回避するには、更新時に、データベース usergroups、および hosts にのみローカルプロバイダーを使用できるようにシステムを設定します。

    1. システムの設定ファイル /etc/nsswitch.conf を開き、winbind 文字列または wins 文字列を含むエントリーを検索します。
    2. そのようなエントリーを確認するには、/etc/nsswitch.conf のバックアップを作成します。
    3. /etc/nsswitch.conf を編集し、winbind または wins を含むエントリーからそれらを削除します。
    4. インプレースアップグレードを実行します。
    5. アップグレード後、システム設定要件に基づいて、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 モジュールが含まれており、これらのモジュールに required または requisite の制御値がある場合、インプレースアップグレードを実行すると、システムからロックアウトされる可能性があります。この問題を回避するには、アップグレードプロセスを開始する前に、RHEL 7 システムを再設定して、pam_krb5 または pam_pkcs11 を使用しないようにします。

  • お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージの名前と同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードの前に次のいずれかのオプションを選択してください。

    1. サードパーティーパッケージの削除
    2. サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
  • セキュリティー上の理由から、シングル DES (DES) およびトリプル DES (3DES) 暗号化タイプのサポートは RHEL 8 から削除されました。ただし、RHEL 7 Identity Management (IdM) は引き続き 3DES 暗号化に対応しています。
    IdM クライアントのアップグレードまたは IdM 環境全体の RHEL 7 から RHEL 8 への移行は可能です。これは、RHEL の両方のバージョンがデフォルトでより強力な AES 暗号化タイプを優先するためです。

    IdM のバージョンデフォルトの暗号化タイプその他のサポートされる暗号化タイプ

    RHEL 7

    aes256-cts
    aes128-cts

    camellia256-cts
    camellia128-cts
    des3-hmac
    arcfour-hmac

    RHEL 8

    aes256-cts
    aes128-cts

    aes256-sha2
    aes128-sha2
    camellia256-cts
    camellia128-cts
    arcfour-hmac [a]

    [a] RC4 暗号化は、新しい暗号化タイプ AES-128 および AES-256 よりも安全ではないと見なされるため、RHEL 8 ではデフォルトで非推奨となり、無効にされています。古い Active Directory 環境との互換性のために RC4 サポートを有効にする方法は、AD および RHEL で一般的な暗号化タイプに対応 を参照してください。

    IdM 以外の Kerberos Distribution Center (KDC)、サービス、またはユーザーが DES または 3DES の暗号化 のみ を使用するように手動で設定した場合、RHEL 8 の最新の Kerberos パッケージに更新した後に、以下のようなサービス中断が発生する可能性があります。

    • Kerberos 認証エラー
    • unknown enctype 暗号化エラー
    • DES で暗号化されたデータベースマスターキー (K/M) を使用する KDC が起動に失敗する

    Red Hat では、お使いの環境で DES または 3DES 暗号化を使用しないことを推奨します。Kerberos プリンシパルが強力な暗号化タイプを使用するように設定する方法の詳細は、MIT Kerberos ドキュメントの Retiring DES を参照してください。

  • インプレースアップグレードは、ソフトウェア Redundant Array of Independent Disks (RAID) を備えたシステムでは失敗する可能性があります。(RHEL-3279)
  • Puppet を使用するシステムなど、無効な GRUB ブートローダー仕様のシステムは、新しいカーネル用に新しい initramfs を作成できません。この問題を回避するには、第 6 章 アップグレード後のタスクの実行 で説明されているように、ブートローダーエントリーからパッケージと古いカーネルを手動で削除します。(BZ#1955099)
  • Relax-and-Recover(ReaR) ユーティリティーは、IBM Z アーキテクチャーでは利用できません。そのため、IBM Z システムは OpenSCAP スイートで完全に修正することはできず、セキュリティーベースラインに完全に準拠しない場合があります。(BZ#1958939)
  • Leapp ユーティリティーは、インプレースアップグレード時に、通常 RHEL 7 から RHEL 8 の間にネットワークインターフェイスコントローラー (NIC) 名を保持します。ただし、ネットワークボンディングを備えたシステムなどの一部のシステムでは、RHEL 7 と RHEL 8 の間で NIC 名を更新する必要があります。これらのシステムで、以下の手順を実行します。

    1. Leapp ユーティリティーが元の RHEL 7 の NIC 名を誤って保持しないように、LEAPP_NO_NETWORK_RENAMING=1 環境変数を設定します。
    2. インプレースアップグレードを実行します。
    3. ネットワークが正常に機能していることを確認します。必要に応じて、ネットワーク設定を手動で更新します。

      (BZ#1919382)

  • BIOS を使用してシステムを起動する場合は、コアイメージのインストールに十分な領域が、ブートディスクの埋め込み領域に含まれていないと、GRUB2 ブートローダーをアップグレードするときにインプレースアップグレードが失敗します。これによりシステムが破損し、RHEL 6 fdisk ユーティリティーなどを使用してディスクが手動でパーティション分割された場合に発生する可能性があります。この問題がユーザーに影響するかどうかを確認するには、以下の手順を実行します。

    1. インストールされたブートローダーを使用してディスク上の最初のパーティションを開始するセクターを決定します。

      # fdisk -l

      コアイメージに十分なスペースを確保する標準のパーティショニングは、セクター 2048 から始まります。

    2. 開始セクターに十分なスペースがあるかどうかを判断します。RHEL 8 コアイメージには少なくとも 32 KiB が必要です。たとえば、セクターサイズが標準の 512 バイトの場合、セクター 66 以下から開始すると十分なスペースが得られません。

      注記

      RHEL 8 コアイメージは 32 KiB より大きい場合があり、開始セクターの値を高く指定しなければいけない可能性があります。現在の RHEL 8 コアに必要な領域を常に確認してください。

    3. 埋め込み領域に十分なストレージ領域が含まれていない場合は、インプレースアップグレードを実行する代わりに、RHEL 8 システムの新規インストールを実行します。

      (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)

  • ハードウェアレベル 13 で作成され、UEFI で起動している VMWare 仮想マシンでは、NVRAM ファイルが小さすぎるため、アップグレード中に問題が発生する可能性があります。この問題と解決方法の詳細は、VMWare: Getting "No space left on device" when executing efibootmgr or mokutil command to add entries を参照してください。(RHEL-3362)
  • ISO イメージを含む RHUI を使用してアップグレードしようとすると、アップグレードが失敗する可能性があります。この問題を回避するには、--iso オプションを使用せずにアップグレードを実行するか、Offline Leapp upgrade using ISO fails with "Failed to synchronize cache for repo 'rhul-microsoft-azure-rhel8', ignoring this repo に記載されている手順を実行します。(RHEL-3296)
  • アップグレード前のプロセスが失敗し、次のエラーメッセージが表示される場合があります。

    MountError: failed to create target directory …

    この問題が発生した場合は、LEAPP_OVL_IMG_FS_EXT4=1 環境変数をエクスポートします。詳細は、Leapp can fail with a MountError (OverlayFS + XFS ftype=1) を参照してください。RHEL 9

  • マウントされているファイルシステムが多すぎると、アップグレード前のプロセスが失敗し、次のエラーメッセージが表示される可能性があります。

    OperationalError: unable to open database file

    この問題が発生した場合は、次の手順を実行してください。

    1. システムパーティションに関係がなく、アップグレードプロセス中に不要なファイルシステムをすべてアンマウントします。
    2. /etc/fstab ファイル内のアンマウントされたファイルシステムのエントリーをコメントアウトして、アップグレードプロセス中にマウントされないようにします。
    3. アップグレード後に元のファイルシステム設定を復元します。

      (RHEL-3320)

  • システムに /etc/sysconfig/kernel システム設定ファイルがない場合、アップグレードは失敗し、システムが破損します。この問題を回避するには、予想される設定でファイルを手動で作成します。詳細は、ブートローダーの検証 を参照してください。(RHEL-22306)
  • /etc/fstab ファイルで定義されているマウントされたファイルシステムのいずれかに 共有 伝播フラグが設定されていない場合、アップグレードが失敗する可能性があります。この問題を回避するには、これらのファイルシステムを再マウントして共有として設定します。

    # mount -o remount --make-shared <mountpoint>

    mountpoint を 各ファイルシステムのマウントポイントに置き換えます。

    詳細は、DNF トランザクションチェック中に Leapp の RPM ファイルをロードできません を参照してください。(RHEL-23449)