1. リリース・ノートfor Unbreakable Enterprise Kernelリリース5更新4
  2. 既知の問題
機械翻訳について

3 既知の問題

この章では、Unbreakable Enterprise Kernelリリース5の既知の問題について説明します。

Armの使用不可または利用不可の機能

この項では、機能していない、カウントされていない、または機能を使用できないようにする問題があることが判明している特定の機能について説明します。

  • InfiniBand

    InfiniBandハードウェアは現在、UEK R5を使用したArmアーキテクチャではサポートされていません。

  • FibreChannel

    FibreChannelハードウェアは現在、UEK R5を使用するArmアーキテクチャではサポートされていません。

  • RDMA

    RDMAおよびあらゆるサブ機能は、Armではサポートされていません。

  • OCFS2

    OCFS2ファイル・システムはArmではサポートされていません。

  • セキュア・ブート

    Secure Boot機能は現在サポートされていないか、Armで使用できません。

[aarch64] IOMMUの問題

ブート時間の拡大、ソフト・ロック・アップ、クラッシュなどのパフォーマンスの問題は、入出力メモリー管理ユニット(IOMMU)機能がアクティブなときにUEK R5を実行している64-bit Arm (aarch64)アーキテクチャで発生する可能性があります。 これらの問題は、Mellanox CX-3とCX-4 Cardを使用するArmハードウェアで確認されています。 ただし、異なるハードウェア上の異なるドライバでも同様の問題が発生する可能性があります。

UEK R5はデフォルトでswiotlbを使用するように構成されています。 IOMMU機能の使用を有効にするには、カーネル・コマンド・ラインでiommu.passthrough=0を使用します。 (バグID 27687153、27812727および27862655)

[aarch64] Kdumpの問題

64ビットArm (aarch64)アーキテクチャでKdumpを使用する場合は、次の問題に注意してください。

  • リモート・ターゲットでMellanox ConnectXデバイスを使用すると、Kdumpが失敗

    mlx4_coreまたはmlx5_coreドライバ・モジュールを使用するMellanoxハードウェア・デバイスを持つシステムでは、Kexecはクラッシュ・カーネルをロードできず、リモート・ダンプ・ターゲットが使用されるとmlx4_coreまたはmlx5_coreドライバが初期化され、ハングアップします。

    回避策は、vmcoreファイルをローカルに格納するか、/etc/sysconfig/kdumpのKDUMP_COMMANDLINE_APPENDオプションにrd.driver.blacklist=mlx4_coreまたはrd.driver.blacklist=mlx5_coreを追加して、クラッシュ・カーネルへのドライバのロードを無効にすることです。 (バグID 27915989および27916214)

  • igbデバイス上でリモート・ダンプ・ターゲットを使用するように構成すると、Kdumpが失敗し、ハングアップ

    igbネットワーク・デバイス上でリモート・ダンプ・ターゲットを使用するようにKdumpが構成されているシステムでは、NETDEV WATCHDOGはタイムアウト・エラーを返し、ネットワーク・アダプタが継続してリセットされるため、kexecがクラッシュ・カーネルをロードしようとするとシステムがハングします。 (Bug ID 27916095)

  • 一部のAMDハードウェアでKdumpが失敗することがある

    UEK R5U4カーネルを実行している一部のAMDハードウェアでKdumpが失敗することがあります。 影響を受けるハードウェアにはAMD EPYC CPU (codename Naples and Rome)サーバーが含まれます。

    この問題を回避するには、/etc/sysconfig/kdump構成ファイルを変更し、KDUMP_COMMANDLINE_APPENDから「iommu=off」コマンド行オプションを削除してから、変更を有効にするためにkdumpサービスを再起動します。

    (バグID 31127379)

[aarch64] CPUホット・プラグ機能がKVMで機能しません

CPUホット・プラグ機能はQEMUで使用できますが、aarch64 Linuxカーネルでは、実行中の仮想マシンへの新しい仮想CPUの追加を処理できません。 QEMUを使用してKVMで実行中の仮想マシンに仮想CPUを追加する場合、次のエラーが返されます: 

kvm_init_vcpu failed: Device or resource busy

64-bit ArmプラットフォームのUEK R5では、CPUホット・プラグ機能は現在使用できません。 (バグID 28140386)

[aarch64] Mellanox ConnectX-3 Pro Ethernetコントローラのネットワーク接続に失敗

Mellanoxネットワークは、特定のファームウェア・バージョンのMellanox ConnectX-3 Pro Ethernetコントローラを使用するArmプラットフォーム・システムで失敗することがあります。 通常、問題は次のdmesg出力になります: 

...
[   21.605491] mlx4_core 0001:01:00.0: Failed to initialize event queue
table, aborting
[   22.660967] mlx4_core: probe of 0001:01:00.0 failed with error -12
[   22.704966] mlx4_en: Mellanox ConnectX HCA Ethernet driver v4.0-0
[   22.711355] mlx4_en 0000:01:00.0: Activating port:1
[   22.742948] mlx4_en: 0000:01:00.0: Port 1: Using 32 TX rings
[   22.748600] mlx4_en: 0000:01:00.0: Port 1: Using 8 RX rings
[   22.754437] mlx4_en: 0000:01:00.0: Port 1: Initializing port
[   22.760602] mlx4_en 0000:01:00.0: registered PHC clock
[   22.766283] mlx4_en 0000:01:00.0: Activating port:2
[   22.766956] mlx4_core 0000:01:00.0 enp1s0: renamed from eth0
[   22.778621] mlx4_en: 0000:01:00.0: Port 2: Failed to allocate NIC
resources
[   22.785776] mlx4_en 0000:01:00.0: removed PHC
[   25.488635] mlx4_en: enp1s0: Steering Mode 1
...

この問題は、ブート時にmaxcpus=8カーネル・パラメータを使用して解決でき、ブート・プロセス中に使用可能なCPUの数を制限できます。 システムの起動が完了すると、Systemdは使用可能なすべてのCPUを有効にし、パフォーマンスへの影響はなくなります。

システムのブート時にすべてのカーネルに対して使用されるようにこのパラメータを設定するには、GRUB構成を編集します。 これを行うには、テキスト・エディタで/etc/sysconfig/grubのGRUB_CMDLINE_LINUX行を編集します。次に例を示します: 

GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/linux1-swap rd.lvm.lv=linux1/root \
  rd.lvm.lv=linux1/swap rhgb quiet maxcpus=8"

レガシーBIOSを使用している場合は、次のブートで使用されるように、変更内容でgrub構成を更新するには、次のように実行します: 

# grub2-mkconfig -o /boot/grub2/grub.cfg

または、UEFIを使用してブートしている場合は、次を実行します: 

# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

この問題は、このハードウェアのあとのファームウェア・バージョンでのみ発生します。 HVE102M-0.2ファームウェアを使用したカードでは問題はレプリケートされませんが、ファームウェアがHVE104N-1.12にアップグレードされたときには表示されます。 カード・ファームウェアをダウングレードすることで問題を回避することもできます。 (バグID 30877943)

ファイル・システムの問題

次に、Unbreakable Enterprise Kernelリリース5更新4でサポートされるファイル・システムに固有の既知の問題を示します。

ext4: 頻繁にシステム停止を繰り返すと、ファイル・システムの破損が発生する可能性があります

ext4を使用しているシステムが繰り返し頻繁にシャットダウンすると、ファイルシステムが壊れている可能性があります。 この問題は、複製するのが困難であるため、コーナー・ケースとみなされます。 この問題は上流のコードに存在し、提案されたパッチは現在検討中です。 (バグID 27547113)

xfs: xfs_repairは、破損したリンク数の修復に失敗しました

xfs_repairコマンドを使用してxfsファイル・システムを修復し、無効なiノード数がある場合、ユーティリティは破損したリンク数の修復に失敗し、リンク数の検証中にエラーを返す可能性があります。 問題は現在調査中ですが、UEK R5でリリースされたxfsprogs-4.15-1パッケージに関連しているようです。 この問題は、ol7_latest yumリポジトリで入手可能な以前のxfsprogs-4.5.0-18.0.1パッケージ・バージョンを使用している場合は表示されないことがあります。 (バグID 28070680)

RDMAの問題

RDMAには次の問題があります:

  • ibacmサービスはデフォルトで無効になっています

    ibacmサービスは、インストール直後にデフォルトで無効になります。つまり、ibacmサービスは再起動後に自動的に起動しません。 これは想定された動作です。 ibacmサービスを使用するための要件はアプリケーション固有です。 アプリケーションでこのサービスが必要な場合、再起動後にサービスを起動する必要がある可能性があります: 

    # systemctl enable ibacm

    (Bug ID 28074471)

  • エラー: その他のホストでは、アドレスxxx.xxx.xxx.xxxがすでに使用されています

    特定のインスタンスでは、次のエラー・メッセージが表示されることがあります: 

    Error, some other host already uses address  xxx.xxx.xxx.xxx

    この問題は、通常、アクティブ結合が有効になっている場合に発生し、ifup ib-interfaceコマンドを実行します。

    InfiniBandインタフェースが正常に起動されたため、このメッセージは無視できます。 (バグID 28097516)

Dockerの問題

以下は、Dockerの既知の問題です:

  • yumのインストールは、overlayfsファイル・システム上のコンテナ内で失敗する可能性があります

    overlayfsファイル・システム上のコンテナ内でyum installコマンドを実行すると、次のする可能性があります: 

    Rpmdb checksum is invalid: dCDPT(pkg checksums): package_name

    このエラーにより、Dockerfileビルドが壊れることがありますが、カーネルおよび既知の問題をアップストリームと想定しています。 https://github.com/moby/moby/issues/10180を参照してください。

    回避策は、パッケージのインストールの前に、touch /var/lib/rpm/*を実行します。

    この問題は、Docker HubまたはOracle Container Registryで使用可能なOracle Linuxイメージに固定されています。ただし、サード・パーティのイメージに基づくコンテナを実行する場合は、引き続き問題が発生する可能性があります。 (バグID 21804564)

  • Dockerは、XFS形式の記憶域でoverlay2記憶域ドライバを使用している場合に失敗することがあります

    ftypeが1に設定されていない場合、XFSでのオーバーレイ・マウントを防ぐためにカーネル・パッチが適用されました。 この修正は、d_typeサポートが有効化されていない場合に、XFSがオーバーレイ・ファイル・システムのホワイト・アウト機能を正しくサポートしなかった問題を解決します。 Dockerエンジンがすでにoverlay2記憶域ドライバでXFSフォーマットの記憶域を使用している場合、-n ftype=1オプションを有効にして、基盤となるXFSファイルシステムが作成されていないと、カーネルをアップグレードするとDockerが失敗する可能性があります。 Oracle Linux 7のルート・パーティションは自動的に-n ftype=0でフォーマットされ、XFSがファイルシステムとして選択されます。 したがって、この環境でoverlay2記憶域ドライバを使用する場合は、この目的のために別のデバイスをフォーマットする必要があります。 (Bug ID 25995797)

IOMMUカーネル・オプションはデフォルトで有効になっています

UEK R5U1以降、IOMMU機能はx86_64カーネルでデフォルトで有効になっています。 この変更により、シングル・ルート入出力仮想化(SR-IOV)やほかの仮想化拡張が容易になりますが、IOMMUが有効になっていると検出を完了できない特定のハードウェアでブート障害の問題が発生することも知られています。 この機能のステータスは、iommu=onとして/proc/cmdレポートに表示されなくなりました。ブート失敗が発生した場合は、カーネルcmdlineオプションとして明示的に無効にする必要があります。 別の回避策として、ベンダーの指示に従って、システムROM内のIOMMUまたはIntel-Vtdを無効にできます。

これらのブート障害の問題は、特定のBroadcomネットワーク・デバイス(HP Gen8サーバーなど)に対応して検出されました。 詳細は、https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04565693を参照してください。

LXCの問題

LXCの既知の問題は次のとおりです:

  • LXC読取り専用ip_local_port_rangeパラメータ

    lxc-1.1以降およびUEK R5では、ip_local_port_rangeは読取り専用ではなく、Oracle Linuxコンテナの/proc/sys/net/ipv4にある読取り/書込み可能パラメータです。 (バグID 21880467)

NVMeデバイス名はリブート後も変更されます

UEK R5では、NVMeサブシステムおよびマルチパスのサポートが追加されるため、カーネルによって生成される列挙デバイス名は安定していません。 この動作は、カーネルがほかのブロック・デバイスを処理する方法と似ています。 fstabファイルのマウントを処理するために列挙型のカーネル・インスタンス名を使用した場合、マウントは失敗するか、または予想外に動作する可能性があります。

ブロック・デバイスを参照するときは、列挙されたカーネル・インスタンス名を使用しないでください。 かわりに、UUID、パーティション・ラベルまたはファイル・システム・ラベルを使用して、NVMeデバイスを含むすべてのブロック・デバイスを参照します。 デバイスUUIDまたはラベルが不明な場合は、blkidコマンドを使用してこの情報を表示します。

マルチパスになる前に、サブシステム番号が通常はコントローラ番号にマップされます。 したがって、/dev/nvme0n1のサブシステムがコントローラ/dev/nvme0と提携していると仮定できます。 この相関はもう存在しません。 マルチパスを有効にする場合は、サブシステムに複数のコントローラが含まれることがあります。 この場合、/dev/nvme0n1は/dev/nvme1と/dev/nvme2のコントローラと簡単に提携することができます。 現在、サブシステムのデバイス名とコントローラのデバイス名の間には特定の相関関係は存在しません。

NVMeデバイス・ホット・プラグ・プロシージャの変更

UEK R5では、NVMeサブシステムおよびマルチパスのサポートが追加されるため、カーネルによって生成される列挙デバイス名は安定していません。 その結果、ホット・プラグ機能を使用してNVMeデバイスを識別および切断する手順は、ほかのカーネル・リリースを使用した場合の手順とは少し異なります。

適切なデバイスを識別、電源切断および切断するには、次のステップを実行します:

  1. lsblkコマンドを使用して、WWNまたはUUIDに従って削除するディスクを特定します: 

    # lsblk -o +UUID,WWN,MODEL

    デバイスに割り当てられている列挙されたカーネル・インスタンス名をノートします。次に例を示します: nvme0n1。

    重要:

    デバイス名が、アタッチ先のコントローラまたはPCIeブリッジに必ずしもマップされていないことを理解することが重要です。 「NVMeデバイス名はリブート後も変更されます」を参照してください。

  2. デバイス・パスを検索して、デバイスのPCIドメイン識別子を取得します: 

    # find /sys/devices -iname nvme0n1
                        
/sys/devices/pci0000:85/0000:85:01.0/0000:8d:00.0/nvme/nvme1/nvme0n1

    デバイスの返されるパスの0000:8d:00.0は、デバイスのPCIドメイン識別子です。 続行するには、この情報が必要です。

  3. NVMeドライブの物理スロット番号を取得します。 UEK R5では、スロットはPCIeコントローラではなくNVMeデバイスに直接バインドされます。

    lspciコマンドを実行し、デバイスのPCIドメイン識別子を冗長モードで問い合せることで、NVMeデバイスのスロット番号を特定できます。次に例を示します: 

    # lspci -s 0000:8d:00.0 -vvv
8d:00.0 Non-Volatile memory controller: Intel Corporation Express Flash NVMe
P4500 (prog-if 02 [NVM Express])
        Subsystem: Oracle/SUN Device 4871
        Physical Slot: 104-1
…

    前述の例では、デバイスの物理スロット番号は104-1であることに注意してください。 続行するには、この値が必須です。

  4. デバイスの物理スロット番号を使用して、そのバス・インタフェースを見つけます: 

    # find /sys -iname "104-1"
/sys/bus/pci/slots/104-1

  5. 返されたバス・インタフェース・パスを使用してNVMeドライブの電源を切断します: 

    # echo 0 > /sys/bus/pci/slots/104-1/power

    ハードウェアによっては、システムのフロント・パネルにある青色のディスクLEDが表示され、ディスク・ドライブを安全に取り外すことができることが示される場合があります。

Avago MegaRAID SAS 9460-16iコントローラのメモリーを割り当てる際のカーネル警告

Avago MegaRAID SAS 9460-16iコントローラ用のmegaraid_sasモジュールをロードするときに、カーネル警告を表示する問題は、このカーネル・リリースで導入されます。 この問題は、カーネルがIOリクエスト・フレーム・プールにメモリーを割り当てようとすると発生します。

この問題は、オプションcma=64Mを含めるようにGRUB_CMDLINE_LINUX行を更新するために/etc/defaults/grubファイルを編集することにより、起動時に連続メモリー割当て(cma)値を64Mに設定することで解決されます。 たとえば: 

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=ol7/root rd.lvm.lv=ol7/swap
rhgb quiet cma=64M"

(バグID 29635963、29618702)

メモリー・ホット・プラグ操作を使用して使用可能なメモリーを縮小すると、KVMゲストがクラッシュ

KVMゲストは、メモリーのホット・プラグ操作を使用することで、ゲスト・メモリーが96GB以上2GB以下で減った場合にクラッシュすることがあります。 この問題はUEK R5で記録されていますが、同様の問題がRHCKで確認されています。 この動作は想定されており、メモリー不足がどのように機能しているかに関連しています。 大量のゲスト・メモリーを縮小すると、メモリー不足(OOM)の条件を引き起こす可能性があります。ゲスト・オペレーティング・システムで現在使用されている量よりもメモリーが減少する場合は、プロセスは自動的に中断されます。 (Bug ID 27968656)

起動後にMellanox ConnectXアダプタが検出されない

Mellanox ConnectXアダプタを使用しているシステムでは、ドライバはブート時にInfiniBandおよびRMDAモジュールをロードしないため、RDMAおよびInfiniBand関連ツール(ibstatなど)の使用時にアダプタを検出できません。 通常、エラーは次のように表示されます: 

ibpanic: [26013] main: stat of IB device 'mthca0' failed: No such file or directory

この問題は、mlx4_coreおよびmlx5_coreドライバは、PXEブートを容易にするためにinitramfsに含まれていますが、InfiniBandおよびRDMAモジュールは含まれていないために発生します。 PXEブートのためにドライバが必要な場合は、ブート後にドライバを手動で再ロードして、RDMAホット・プラグ・シーケンスをトリガーできます。次に例を示します: 

# modprobe mlx5_core

PXEブートにmlx4_coreまたはmlx5_coreドライバが必要ない場合は、これらのドライバをinitramfsから削除し、必要に応じてブート後にロードでき、RDMAホット・プラグ・シーケンスが正常にトリガーされます。 initramfsからドライバを削除するには、次の行を含む/etc/dracut.conf.d/10-mlx_dracut-denylist.confを作成します: 

omit_drivers+=" mlx4_* mlx5_* mlxfw "

これを行ったら、次を実行してinitramfsを再構築します: 

# dracut -f

変更は再起動後に有効になります。

(バグID 31353413)