既知の問題
この項では、この更新の既知の問題について説明します。
btrfs、ext4およびxfs: 凍結および凍結解除操作が複数のスレッドで実行される場合のカーネル・パニック
サポートされているいずれかのファイル・システム上の複数のスレッドで、凍結および凍結解除操作が実行されることによって、システムが停止し、カーネル・パニックが発生する場合があります。 これは、実際に凍結される前に凍結解除操作がトリガーされた場合に発生する競合状態の結果です。 結果として発生するロック解除操作により、存在しないロックに対する書込み操作が試行され、カーネル・パニックが発生します。 (バグID 25321899)
btrfs
-
btrfs filesystem balanceコマンドでは、特定の状況でRAIDレベルを変更できるという警告はなく、操作を取り消す選択肢はありません。 (バグID 16472824)
-
btrfsがコピーオンライトであるということは、ファイル・システム上のすべての操作で、最初にディスク・スペースが必要になるということです。 スペースが残っていないディスクでは、すべての操作を実行できず、ファイルの削除もできない場合があります。 メタデータを格納するスペースがない場合、
ENOSPCエラーが返されます。 この場合、メタデータ領域を予約している可能性があるバックグラウンド・ライトバックをクリアできるため、操作を再試行する前にsyncを実行します。 もう1つの潜在的な回避策は、btrfs device addコマンドを使用してディスクまたはファイル・バックアップ・ループ・デバイスを追加することです。 データおよびメタデータの格納に使用されるメカニズムによって、dfなどのツールによって返される情報に混乱が生じる可能性があります。 データ用に使用できるスペースがまだある場合でも、メタデータ用に割り当てられているすべてのディスク・スペースが一杯になる場合があります。 この場合、ファイル・システムのバランスがとれず、btrfs fi balance操作を実行して問題を解決できます。 詳細は、https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_spaceを参照してください。 -
ファイルの途中でデータを上書きすると、上書きされた領域は、btrfs qgroup showによって表示される領域使用量の2倍にカウントされます。 btrfs quota rescanを使用すると、この問題の修正にも役立ちません。 (バグID 16609467)
-
-sオプションを使用して、ページ・サイズとは異なるセクター・サイズをmkfs.btrfsに指定した場合、作成されたファイルシステムはマウントできません。 デフォルトでは、セクター・サイズは、ページ・サイズと同じになるように設定されます。 (バグID 17087232)
-
UEK R4で使用する
btrfs-progsおよびbtrfs-progs-develパッケージは、ol6_x86_64_UEKR4およびol7_x86_64_UEKR4ULNチャネル、Oracle Linux Yum Server上のol6_UEKR4およびol7_UEKR4チャネルで入手可能です。 UEK R3では、これらのパッケージは、ol6_x86_64_latestおよびol7_x86_64_latestULNチャネル、Oracle Linux Yum Server上のol6_latestおよびol7_latestチャネルで入手可能でした。
ext4
-
破損した孤立inodeリストを処理するときにシステムが停止する
孤立inodeリストが破損した場合、inodeが繰り返し処理され、システムが停止する場合があります。 たとえば、孤立inodeリストにブートローダーinodeの参照が含まれている場合、
ext4_iget()によって不正なinodeが返されることによって処理ループが発生し、これにより、システムが停止することがあります。 (バグID 24433290) -
負の
i_sizeを使用してファイルに追加した後、アンマウントでシステムが停止するファイル・システムで負の
i_sizeを使用してinodeをロードすることは無効ですが、このようなファイルの作成とそのファイルへの追加は可能です。 これにより、ライトバックの基礎となるルーチンで整数オーバーフローが発生し、カーネルがロックされます。 (バグID 25565527) -
inodeの
i_extra_sizeフィールドを使用する場合、inodeサイズの動的拡張中にハングがext4ファイル・システムで発生します。 (バグID 25718971)
xfs
-
ディレクトリreadaheadの完了によってアンマウント後にシステムが停止する可能性がある
ファイル・システムがマウント後に突然アンマウントされた場合、ディレクトリreadaheadによってシステムが停止する可能性があります。 ディレクトリreadaheadの遅延が長くなると、アンマウントが完了した後にバッファI/O完了が発生する可能性があります。 ディレクトリreadahead I/Oの持つ非同期的な性質から、readahead I/O完了が発生したときにコア・データ構造が解放済になっている場合があり、これにより、完了によるメモリー・アクセスが無効になる可能性があります。 このことによって、カーネル・パニックおよびシステム停止が発生する場合があります。 (バグID 25550712)
-
v5スーパーブロックでのログ・リカバリの問題によって、破損したファイル・システム・エラーが誤って発生する
v5スーパーブロックでのログ・リカバリの問題により、書込み対象のバッファについてメタデータLSNが更新されなくなることで、破損エラーが発生する場合があります。
[1044224.901444] XFS (sdc1): Metadata corruption detected at xfs_dir3_block_write_verify+0xfd/0x110 [xfs], block 0x1004e90 [1044224.901446] XFS (sdc1): Unmount and run xfs_repair ... [1044224.901460] XFS (sdc1): xfs_do_force_shutdown(0x8) called from line 1249 of file fs/xfs/xfs_buf.c. Return address = 0xffffffffa07a8910 [1044224.901462] XFS (sdc1): Corruption of in-memory data detected. Shutting down filesystem [1044224.901463] XFS (sdc1): Please umount the filesystem and rectify the problem(s) [1044224.904207] XFS (sdc1): log mount/recovery failed: error -117 [1044224.904456] XFS (sdc1): log mount failed"
問題は、後続のリプレイされた更新によって有効ではなくなったバッファ更新をログがリプレイしようとすることです。 これにより、実際にはファイル・システムが正常であっても、破損エラーが発生します。 (バグID 25380003)
-
負の
i_sizeを使用してバッファによるファイルへの追加を実行した後、アンマウントでシステムが停止するファイル・システムで負の
i_sizeを使用してinodeをロードすることは無効ですが、このようなファイルの作成は可能であり、そのファイルにバッファが追加される場合、ライトバックの基礎となるルーチンでの整数オーバーフローによってカーネルがロックされます。 直接追加ではこの動作は発生しません。 (バグID 25565490) -
推測による事前割当てを持つ2つのエクステントのファイルに対する
xfs_fsr中にシステムが停止する推測による事前割当てによって生成されたエクステントに対する
xfs_fsrプロセス中に、使用されるdi_nextents呼出しではこれらのエクステントが考慮されないことが原因で、すべてのエクステントが収まるかどうかを決定するコードが計算を誤ります。 これにより、インメモリーinodeは破損し、最終的に、コードは誤って計算された範囲を使用してメモリー構造の移動を試みます。 このことによってカーネル・パニックが発生します。 (バグID 25333211) -
Oracle Linux 6で読取り専用で再マウントするとXFS割当てが無効になる
Oracle Linux 6では、ファイル・システムが読取り専用権限で再マウントされると、XFSでの割当てが無効になります。 (バグID 22908906)
-
d_typeサポートがない場合、オーバーレイ・ファイル・システムをXFSでマウントできませんオーバーレイ・ファイル・システムは、
d_typeサポートと呼ばれる機能に依存します。 この機能は、基本ファイル・システム内のディレクトリ・エントリのファイルのメタデータを提供するデータ構造内のフィールドです。 オーバーレイ・ファイル・システムはこのフィールドを使用して、所有者変更およびホワイトアウトなどの多数のファイル操作を追跡します。ファイル・システムが作成される場合、-n ftype=1オプションを使用して、d_typeサポートをXFSで有効化できます。d_typeサポートが有効化されていない場合、オーバーレイ・ファイル・システムが破損し、予期しない動作をする場合があります。 このため、d_typeサポートが有効化されていない場合、UEK R4のこの更新リリースでは、XFSベースでオーバーレイ・ファイル・システムをマウントできません。XFSがファイル・システムとして選択される場合、Oracle Linuxのルート・パーティションは下位互換性のために
-n ftype=0で自動的にフォーマットされるので、オーバーレイ・ファイル・システムがすでに配置され、代替ストレージにホストされていない場合、これらをd_typeサポートが有効な状態でフォーマットされているファイル・システムに移行する必要があります。XFSファイル・システムが正しくフォーマットされていることを確認するには:
# xfs_info /dev/sdb1 |grep ftype/dev/sdb1を正しいストレージ・デバイスへのパスに置き換えます。 このコマンドによって返される情報に
ftype=0が含まれる場合、このディレクトリに保持されるオーバーレイ・データを正しくフォーマットされているストレージに移行する必要があります。オーバーレイ・ファイル・システムのサポートとともにXFSファイル・システムで新しいブロック・デバイスを正しくフォーマットするには、次のコマンドを実行します。
# mkfs -t xfs -n ftype=1 /dev/sdb1/dev/sdb1を正しいストレージ・デバイスへのパスに置き換えます。 ファイル・システムを作成する場合に
-n ftype=1オプションを使用する必要があります。使用可能な追加のブロック・ストレージがない場合、XFSファイル・システム・イメージを作成し、これをループバック・マウントできます。 たとえば、ルート・ディレクトリに5GBのイメージ・ファイルを作成するには、次のコマンドを使用できます。
# mkfs.xfs -d file=1,name=/OverlayStorage,size=5g -n ftype=1一時的にこのファイルをマウントするには、次のコマンドを入力できます。
# mount -o loop -t xfs /OverlayStorage /mntこのストレージの永続マウントを行う
/etc/fstabのエントリは次のようになります。/OverlayStorage /mnt xfs loop 0 0この構成は、アップグレードの問題を解決する一時的な解決策として役立つ可能性があります。 ただし、永続ストレージの形式としてループバック・マウントされたファイル・システム・イメージを使用することは本番環境で推奨されていません。 (バグID 26165630)
Docker
-
overlayfsファイル・システムのコンテナ内でyum installを実行すると、次のエラーで失敗する可能性があります:
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 Engineがoverlay2ストレージ・ドライバとともにXFS形式ストレージをすでに使用している場合、カーネルのアップグレードにより、基礎となるXFSファイル・システムが-n ftype=1オプションが有効な状態で作成されない場合にDockerが失敗する可能性があります。 Oracle Linux 7のルート・パーティションは、XFSがファイル・システムとして選択される場合に-n ftype=0で自動的にフォーマットされます。 したがって、この環境でoverlay2ストレージ・ドライバを使用する場合、この目的のために個別のデバイスをフォーマットする必要があります。 (バグID 25995797) -
overlay2ストレージ・ドライバを使用し、SELinuxが有効な場合、Dockerが失敗する可能性がありますDocker Engineが
overlay2ストレージ・ドライバを使用するよう構成され、SELinuxが有効でEnforcingモードに設定されている場合、Dockerコンテナは適切に機能できず、権限エラーが発生します。overlay2ストレージ・ドライバとともにDockerを使用する場合、SELinuxをPermissiveモードに設定する必要があります。 (バグID 25684456)
DIF/DIXは、extファイル・システムではサポートされていません
SCSI規格に追加されたDIF (Data Integrity Field)およびDIX (Data Integrity Extension)機能は、メモリー管理システムによるバッファ内のデータの変更試行を正しく処理できるファイル・システムに依存しています書き込みのためにキューに入れられます。
ext2、ext3、およびext4ファイル・システム・ドライバは、チェックサムの失敗や「論理ブロック・ガードのチェックに失敗しました」というエラーを引き起こすI/Oの間にページが変更されるのを防ぎません。 XFSなどの他のファイル・システムもサポートされています。 (バグID 24361968)
DTrace
-
USDTプローブ定義での引数の宣言は、
enum、struct、unionなどの派生型を使用して宣言できません。 -
次のコンパイラの警告は、
string型のUSDTプローブ定義引数(C型ではなくD型)の場合、無視できます。provider_def.h:line#: warning: parameter names (without types) in function declaration
-
-
dlopen()を最初のスレッド以外のスレッドで実行するustack()、usym()、uaddr()およびumod()下のマルチスレッド・プロセスは、dlopen()で使用するシンボルに対して厳密なシンボル解決を実行しません。 (バグID 20045149)
LXC
-
lxc-netサービスは、Oracle Linux 6にインストールした直後に起動されるとは限りませんlxc-netサービスは、RPMインストール後スクリプトの一部としてこのアクションが指定されている場合でも、Oracle Linux 6へのインストール直後に起動されるとは限りません。 これにより、lxcbr0インタフェースが起動しなくなります。 インストール後にこのインタフェースが起動していない場合は、service lxc-net startを実行して手動で起動できます。 (バグID 23177405) -
LXC読取り専用
ip_local_port_rangeパラメータlxc-1.1以降およびUEK R4では、ip_local_port_rangeは、読取り専用ではなく、Oracle Linuxコンテナの/proc/sys/net/ipv4下の読取り書込み可能パラメータです。 (バグID 21880467)
起動時にコンソールが停止したように見える
ASPEEDグラフィック・コントローラでハードウェア上のOracle Linux 6を起動すると、udevの開始後の起動プロセス中にコンソールが停止したように見える場合があります。 ただし、システムは正常に起動しており、アクセス可能です。 回避策は、nomodesetを/etc/grub.confのカーネル・ブート・パラメータとして追加します。 (バグID 22389972)
Oracle Linux 6でイニシエータからOFED iSERターゲット・ログインが失敗する
oracle-ofed-releaseパッケージがインストールされ、iSER (RDMA用のiSCSI拡張機能)ターゲットが構成されているOracle Linux 6システムでは、イニシエータとしてのiSERターゲットへのログインが失敗します。 Oracle Linux 6イニシエータ・マシンでは、次の動作が一般的です。
# iscsiadm -m node -T iqn.iser-target.t1 -p 10.196.100.134 --login Logging in to [iface: default, target: iqn.iser-target.t1, portal: 10.196.100.134,3260] (multiple) iscsiadm: Could not login to [iface: default, target: iqn.iser-target.t1, portal: 10.196.100.134,3260]. iscsiadm: initiator reported error (8 - connection timed out) iscsiadm: Could not log into all portals
これは予期された動作であり、無効なコンテキストからの書込みに対して保護するためのCVE-2016-4564の更新情報修正によるものです。
(バグID 23615903)
Shared Receive Queue (SRQ)はReliable Datagram Sockets (RDS)のための試験的な機能でありデフォルトでは無効になっている
rds_rdmaモジュール内のリソース使用量を最適化するSRQ関数は、試験的なものであり、デフォルトでは無効になっています。 rds_ib_srq_enabledフラグを設定することでこの機能を有効にすると、警告メッセージが表示されます。 (バグID 23523586)
rds_rdmaモジュールのアンロードまたは削除はサポートされていません
rds_rdmaモジュールがロードされると、rmmodまたはmodprobe -rを使用してモジュールを削除することはできません。 rds_rdmaモジュールのアンロードはサポートされておらず、カーネル・パニックを引き起こす可能性があります。 このモジュールに対してmodule_unload_allowedフラグを設定しないでください。 (バグID 23580850)
Oracle VM Server上でのMellanox® HCA使用時のdom0メモリー要件の増加
dom0でUEKR4u2以上を実行するOracle VM Serverは、Mellanox®ドライバを使用するために400MB以上のメモリーが必要です。 これは、カーネルの新しいバージョンでSRQカウントのデフォルト・サイズが64Kから256Kに増加し、mlx_coreモジュールでデフォルトでscale_profileオプションが有効になったためです。
dom0でメモリー不足エラーが検出された場合は、dom0メモリーの最大サイズを増加させる必要があります。 別の回避策は、mlx4_coreドライバのモジュール・パラメータの手動設定を含んでいる可能性があります。 これを行うには、/etc/modprobe.d/mlx4_core.confを編集し、scale_profileを0に設定します。 あるいは、log_num_srqを16に設定します。 この問題に推奨される解決方法は、Oracle VM Server上のdom0に割り当てられているメモリーの増加です。 (バグID 23581534)
SDPのパフォーマンスの低下
Sockets Direct Protocol (SDP)は、InfiniBandネットワークを介して、TCPにかわるものとしてRDMAを提供するよう設計されており、UEK R4 U2以降などの最近のカーネルでパフォーマンス低下をもたらすことがわかっています。 このプロトコルに関して実施している開発はありません。
このプロトコルのライブラリはまだこのカーネルに使用可能ですが、サポートは限定されています。 より安定した代替案として、InfiniBand上でIPに加えてTCPを使用することを検討する必要があります。 (バグID 22354885)
ネットワーク・インタフェース・カード用のi40eドライバ・モジュールを使用して、ホスト上のKVMゲストのDHCPが失敗
KVMゲスト内からDHCPリクエストを行うvirtioネットワーク・インタフェースとブリッジしたときに、i40eドライバ・モジュールが正しく機能しません。 DHCPリクエストはvirtioネットワーク・インタフェースを介して送信されますが、リクエストはi40eネットワーク・インタフェース・カードを超えてネットワークに到達しません。 この機能後退は、ブロードキャスト・フィルタを追加するかわりに、無差別モードでのVSIブロードキャストを有効にするために適用されたパッチによるものです。 修正は調査中です。 (バグID 25825419)
ホストからゲストに大規模ファイルをコピーするときにHyper-V fcopyプロセスが失敗する
Oracle Linuxゲスト(UEK R4を実行し、Microsoft® Windows 2012 R2 Hyper-Vシステムでホストされている)は、Guest services機能とhypervfcopydサービスを使用して、ホストからゲスト仮想マシンに大規模ファイルをコピーするとき、ファイル・コピーを完了できない場合があります。 この問題は、10GBを超えるファイルをホストからゲスト・マウント・ポイントにコピーするときに発生することがあり、その場合、ホスト・ログに次のようなエラー・メッセージが記録されます。
Copy-VMFile : The operation cannot be performed while the virtual machine is
in its current state. The name of the virtual machine is TestVM and its ID is
9ebdc189-439a-4db2-b33f-05f3b07726bf.
At line:1 char:1 + Copy-VMFile "TestVM" -SourcePath "E:\ISO\largefile.7z"
-DestinationPath "/mnt" -C ...
...
+ CategoryInfo : InvalidResult: (:) [Copy-VMFile],
VirtualizationOperationFailedException
+ FullyQualifiedErrorId :
InvalidState,Microsoft.HyperV.PowerShell.Commands.CopyVMFileCommandこの問題は、様々なファイル・システム・タイプで再現されます。 この問題は断続的に発生し、すべてのコピー試行で発生するわけではありません。 (バグID 25866707および25866691)