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)
[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)
ファイル・システムの問題
UEK R5U5でサポートされているファイル・システムに固有の既知の問題を次に示します。
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 installコマンドは、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
記憶域ドライバを使用する場合は、この目的のために別のデバイスをフォーマットする必要があります。(バグ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デバイスを識別および切断する手順は、ほかのカーネル・リリースを使用した場合の手順とは少し異なります。
適切なデバイスを識別、電源切断および切断するには、次のステップを実行します:
-
lsblkコマンドを使用して、WWNまたはUUIDに従って削除するディスクを特定します:
# lsblk -o +UUID,WWN,MODEL
デバイスに割り当てられている列挙されたカーネル・インスタンス名をノートします。次に例を示します:
nvme0n1
。重要:
デバイス名が、アタッチ先のコントローラまたはPCIeブリッジに必ずしもマップされていないことを理解することが重要です。 「NVMeデバイス名はリブート後も変更されます」を参照してください。
-
デバイス・パスを検索して、デバイスの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ドメイン識別子です。 続行するには、この情報が必要です。 -
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
であることに注意してください。 続行するには、この値が必須です。 -
デバイスの物理スロット番号を使用して、そのバス・インタフェースを見つけます:
# find /sys -iname "104-1" /sys/bus/pci/slots/104-1
-
返されたバス・インタフェース・パスを使用してNVMeドライブの電源を切断します:
# echo 0 > /sys/bus/pci/slots/104-1/power
ハードウェアによっては、システムのフロント・パネルにある青色のディスクLEDが表示され、ディスク・ドライブを安全に取り外すことができることが示される場合があります。
Avago MegaRAID SAS 9460-16iコントローラのメモリーを割り当てる際のカーネル警告
Avago MegaRAID SAS 9460-16iコントローラのmegaraid_sas
モジュールをロードするときにカーネル警告が発生する問題が、このカーネル・リリースで導入されました。 この問題は、カーネルがIOリクエスト・フレーム・プールにメモリーを割り当てようとすると発生します。
この問題を解決するには、次のように/etc/defaults/grub
ファイルを編集し、cma=64M
オプションを含むようにGRUB_CMDLINE_LINUX
行を更新して、起動時に連続したメモリー割当て(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ゲストがクラッシュする可能性があります
メモリー・ホット・プラグ操作を使用してゲスト・メモリーを96GB以上から2GBに削減すると、KVMゲストがクラッシュすることがあります。 この問題はUEK R5で記録されていますが、同様の問題がRHCKで確認されています。 この動作は想定されており、メモリー不足がどのように機能しているかに関連しています。 ゲスト・メモリーを大量に縮小すると、メモリー不足(OOM)状態になる可能性があります。メモリーがゲスト・オペレーティング・システムで現在使用されている量より少ない量に縮小されると、プロセスは自動的に強制終了されます。
(Bug ID 27968656)
Mellanox ConnectXアダプタがブート時に検出されない
Mellanox ConnectXアダプタを使用しているシステムでは、ドライバは起動時にInfiniBandおよびRMDAモジュールをロードしないため、ibstatコマンドなどのRDMAおよびInfiniBand関連ツールを使用するときにアダプタが検出されません。
通常、次のようなエラーが表示されます:
ibpanic: [26013] main: stat of IB device 'mthca0' failed: No such file or directory
この問題は、PXEブートを容易にするためにinitramfsにmlx4_core
およびmlx5_core
ドライバが含まれていても、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)