3 既知の問題
この章では、Unbreakable Enterprise Kernelリリース5の既知の問題について説明します。
Armの使用不可または利用不可の機能
このセクションでは、動作しない、テストされていない、または機能を使用できなくする問題があることがわかっている特定の機能を呼び出します。
-
InfiniBand
InfiniBandハードウェアは現在、UEK R5を使用したArmアーキテクチャではサポートされていません。
-
FibreChannel
FibreChannelハードウェアは現在、UEK R5を使用するArmアーキテクチャではサポートされていません。
-
RDMA
RDMAおよびRDMAで説明されているサブ機能は、Armではサポートされていません。
-
OCFS2
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
を使用します。 (Bug ID 27687153, 27759954, 27812727,、および27862655)
[aarch64] Kdumpの問題
64-bit Arm (aarch64)アーキテクチャ・プラットフォームでKdumpを使用する場合、いくつかの問題が検出されています。
-
Mellanox ConnectXデバイスを使用するとKdumpが失敗
mlx4_core
またはmlx5_core
ドライバ・モジュールを使用するMellanoxハードウェア・デバイスがあるシステムでは、Kexecはクラッシュ・カーネルのロードに失敗し、mlx4_core
またはmlx5_core
ドライバの初期化中にハングアップします。回避策は、
/etc/sysconfig/kdump
のKDUMP_COMMANDLINE_APPEND
オプションにrd.driver.blacklist=mlx4_core
またはrd.driver.blacklist=mlx5_core
を追加することにより、クラッシュ・カーネルでのドライバのロードを無効にすることです。 この解決策は、vmcoreファイルをローカルに保存するように構成した場合にのみ可能であることに注意してください。 デバイス経由でvmcoreをリモート・ホストに保存するようにKdumpが構成されている場合、この回避策は失敗します。 (バグID 27915989)(バグID 27916214) -
ixgbe
デバイス上でリモート・ダンプ・ターゲットを使用するように構成されている場合、Kdumpは失敗Kdumpが
ixgbe
ネットワーク・デバイス上のリモート・ダンプ・ターゲットを使用するように構成されているシステムでは、Kdump Vmcore保存サービスはvmcoreファイルをターゲットの宛先に保存できません。 (バグID 27915827) -
igb
デバイス上でリモート・ダンプ・ターゲットを使用するように構成すると、Kdumpが失敗し、ハングアップigb
ネットワーク・デバイス上でリモート・ダンプ・ターゲットを使用するようにKdumpが構成されているシステムでは、NETDEV WATCHDOGはタイムアウト・エラーを返し、ネットワーク・アダプタが継続してリセットされるため、kexecがクラッシュ・カーネルをロードしようとするとシステムがハングします。 (Bug ID 27916095)
[aarch64] KVMでCPUホット・プラグ機能が機能しない
CPUホット・プラグ機能はQEMUで使用可能ですが、Arm64 Linuxカーネルは、実行中の仮想マシンへの新しい仮想CPUsの追加を処理できません。 QEMUを使用してKVM内の実行中の仮想マシンに仮想CPUを追加すると、エラーが返されます:
kvm_init_vcpu failed: Device or resource busy
CPUホット・プラグ機能は、64-bit Armプラットフォーム上でUEK R5では現在使用できません。 (バグID 28140386)
RDMAの問題
RDMAには次の問題があります:
-
ibacm
サービスはデフォルトで無効になっていますibacm
サービスは、インストール直後にデフォルトで無効になっています。 つまり、リブート後もibacm
サービスは自動的に起動しません。 再起動後にこのサービスを開始するには、サービスを有効にする必要があります:# systemctl enable ibacm
(Bug ID 28074471)
-
Network Managerの制御が有効または無効になっているときの問題
RDMAに使用されるインタフェースに
NM_CONTROLLED=yes
が設定されている場合、いくつかの問題が確認されています。 これらの理由から、インタフェース構成でNM_CONTROLLED=no
を設定することをお薦めします。ただし、Network Manager制御が無効の場合、InfiniBandインタフェースではCONNECTED_MODE=yes
パラメータは無視されます。 この問題を回避するには、次のコマンドを実行して手動で接続モードを設定します:# echo connected > /sys/class/net/ib0/mode
ここで、ib0はモードを変更するインタフェースです。 再起動後にこのコマンドを実行する必要があります。 (Bug ID 28074921)
-
エラー。他のホストではすでにアドレスxxx.xxx.xxx.xxxが使用されています
特定のインスタンスでは、次のエラー・メッセージが表示されることがあります:
Error, some other host already uses address xxx.xxx.xxx.xxx
このエラー・メッセージがトリガーされる可能性のある2つのインスタンスは、次のとおりです:
-
アクティブ・ボンディングが有効で、
ifup
ib-interfaceコマンドを実行します。 -
systemctl start rdma
コマンドを実行するとき。
どちらの場合も、InfiniBandインタフェースが正常に起動されるため、このメッセージは無視できます。 (バグID 28097516)
-
-
resilient_rdmaip
をアンロードすると、InfiniBandインタフェースへのアクセスに問題が発生する可能性がありますresilient_rdmaip
モジュールをアンロードすると、InfiniBandインタフェースへのアクセスおよび構成に問題が発生する可能性があります。 モジュールがアンロードされた後にInfiniBandインタフェースでifconfigコマンドを使用しようとすると、デバイスが見つかりませんというメッセージが表示され、これらのインタフェースのIP情報は使用できません。 インタフェースは、ifupコマンドを使用して再初期化する必要があります。 アクティブ・ボンディング機能はこの問題の影響を受けません。 (バグID 28123680)
Dockerの問題
以下は、Dockerの既知の問題です:
-
yum installをoverlayfsファイル・システム上のコンテナ内で実行すると、次のエラーが発生して失敗します:
Rpmdb checksum is invalid: dCDPT(pkg checksums): package_name
このエラーは、Dockerfileビルドを破壊する可能性がありますが、カーネルからの予期された動作であり、upstreamの既知の問題です(https://github.com/docker/docker/issues/10180を参照)
回避策は、パッケージのインストールの前に、touch /var/lib/rpm/*を実行します。
この問題は、Docker HubまたはOracle Container Registryで入手できるOracle Linuxイメージでは修正されていますが、サード・パーティのイメージに基づくコンテナを実行する場合にはまだ発生する可能性があります。 (バグID 21804564)
-
XFS形式ストレージで
overlay2
ストレージ・ドライバを使用する場合、Dockerが失敗する可能性があります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)
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の下では、スロットはNVMeデバイスに直接バインドされ、PCIeコントローラにはバインドされません。 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が表示されて、ディスク・ドライブを安全に取り外すことができることが示される場合があります。