8.5. カーネル

RHEL 7 仮想マシンが ESXi 5.5 で起動できないことがあります。

VMware ESXi 5.5 ハイパーバイザーで RAM が 12GB 以上の Red Hat Enterprise Linux 7 ゲストを実行している場合、一部のコンポーネントは現在、間違ったメモリータイプ範囲レジスター (MTRR) 値で初期化されていたり、システムの起動時に MTRR 値が間違って再設定されています。これにより、ゲストカーネルがパニック状態になったり、ゲストがシステムの起動時に応答しなくなることがあります。

この問題を回避するには、ゲストのカーネルコマンドラインに disable_mtrr_trim オプションを追加します。これにより、MTRR が正しく設定されていれば、ゲストが起動を継続できます。このオプションを使用すると、ゲストは起動中に WARNING: BIOS bug メッセージを出力することに注意してください。これは無視しても問題ありません。

(BZ#1429792)

bnx2xにより特定の NIC ファームウェアが応答しなくなることがあります。

事前ブートドライバーのアンロードシーケンスのバグにより、bnx2x ドライバーがデバイスを超えると、一部のインターネットアダプターのファームウェアが応答しなくなることがあります。bnx2x ドライバーは問題を検出し、カーネルログで「storm stats was not updated for 3 times」というメッセージを返します。この問題を回避するには、ハードウェアベンダーが提供する最新の NIC ファームウェアの更新を適用します。その結果、起動前のファームウェアのアンロードが期待どおりに機能し、bnx2x がデバイス上で引き継ぐとファームウェアがハングしなくなりました。

(BZ#1315400)

i40iw モジュールがシステムの起動時に自動的に読み込まれない

i40e NIC は iWarp に対応していないため、i40iw モジュールはサスペンドおよび再開操作を完全にサポートしません。したがって、一時停止および再開操作が適切に機能するために、i40iw モジュールはデフォルトで自動的に読み込まれません。この問題を回避するには、/lib/udev/rules.d/90-rdma-hw-modules.rules ファイルを編集して、i40iw の自動読み込みを有効にします。

また、同じマシンの i40e デバイスとともに別の RDMA デバイスがインストールされている場合、i40e 以外の RDMA デバイスにより、i40iw モジュールを含む、有効な RDMA スタックモジュールをすべて読み込む rdma サービスがトリガーされます。

(BZ#1622413)

介入のない永続メモリー設定はストレージを使用できません。

以前のバージョンでは、永続メモリーが 64 MB の境界に調整されたシステムでは、namespace を作成できませんでした。そのため、介入のない永続メモリー設定は、ストレージを使用できませんでした。この問題を回避するには、永続メモリーに interleaved モードを使用します。その結果、ほとんどのストレージが利用できるようになり、障害の分離が制限されています。

(BZ#1691868)

永続メモリーのファイルシステムが原因で、システムの起動が失敗する場合がある

永続メモリーのサイズが大きい場合は、システムの起動に時間がかかります。/etc/fstab ファイルが、永続メモリーのファイルシステムを設定すると、デバイスが利用可能になる前にシステムがタイムアウトになる場合があります。その後システムの起動プロセスに失敗して、緊急プロンプトが表示されます。

この問題を回避するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec の値を大きくします。十分に大きな値 (1200s など) を使用します。これにより、システムの起動がタイムアウトしなくなります。

(BZ#1666535)

radeon がハードウェアを適切なハードウェアリセットに失敗します。

現在、radeon カーネルドライバーは、kexec コンテキストでハードウェアを正しくリセットしません。代わりに、radeon が突然終了するため、残りの kdump サービスが失敗します。

このバグを回避するには、/etc/kdump.conf ファイルに以下の行を追加して、kdumpradeon をブラックリストとして追加します。

dracut_args --omit-drivers "radeon"

その後、マシンおよび kdump を再起動します。

このシナリオでは、kdump 時にグラフィックは利用できませんが、kdump は問題なく完了します。

(BZ#1509444)

特定の eBPF ツールにより、IBM Z でシステムが応答しなくなることがあります。

JIT コンパイラーのバグにより、IBM Z の bcc-tools パッケージに含まれる特定の eBPF ツールを実行すると、システムが応答しなくなることがあります。この問題を回避するには、修正がリリースされるまで、IBM Z の dcsnoop ツール、runqlen および slabratetop ツール の使用を回避してください。

(BZ#1724027)

/dev/sg の同時 SG_IO 要求が原因でデータが破損する可能性がある

/dev/sg デバイスドライバーがカーネルデータの同期がない。ドライバーの同時要求は、同時に同じデータにアクセスします。

そのため、ioctl システムコールが、正しいコマンドと同時に送信された別のコマンドの SG_IO 要求のペイロードを誤って使用することがあります。これにより、特定のケースではディスクが破損する可能性があります。Red Hat は、Red Hat Virtualization(RHV)でこのバグを認識しました。

この問題を回避するには、以下のソリューションのいずれかを使用します。

  • /dev/sg ドライバーに同時要求を送信しないでください。これにより、/dev/sg に送信された各 SG_IO 要求が正しいデータを使用することが保証されます。
  • または、/dev/sg の代わりに /dev/sd ドライバーまたは /dev/bsg ドライバーを使用します。このバグは、これらのドライバーには存在しません。

(BZ#1710533)

内部および外部 VLAN タグの順序が間違っている

mlx5 ドライバーを使用する場合は、IEEE802.1Q 標準で QinQ(IEEE802.1Q)をレプリゼンターデバイスで使用すると、システムがスワップ順で内部および外側の VLAN タグを受け取ります。これは、rxvlan オフロードスイッチがこのパスでは有効ではないため、Open vSwitch(OVS)がこのエラーを前にプッシュします。既知の回避策はありません。

(BZ#1701502)

RHEL 7 の Azure インスタンスで vmcore の生成に失敗する

UEFI ブートローダーで起動する Azure インスタンスのシリアルコンソール実装における根本的な問題により、kdump カーネルが起動できなくなります。したがって、クラッシュしたカーネルの vmcore は、/var/crash/ ディレクトリーに取得できません。この問題を回避するには、以下を実行します。

  1. console=ttyS0 パラメーターおよび earlyprintk=ttyS0 パラメーターを /etc/sysconfig/kdump ディレクトリーの KDUMP_COMMANDLINE_REMOVE コマンドラインに追加します。
  2. kdump サービスを再起動します。

これにより、kdump カーネルが正しく起動し、クラッシュ時に vmcore がキャプチャーされることが予想されます。

/var/crash/ に vmcore を保存するのに十分な領域があることを確認します。これは、システムメモリーのサイズまで使用できます。

(BZ#1724993)

KASLR が有効な場合 kdumpctl サービスがクラッシュカーネルをロードできません。

kptr_restrict カーネル調整可能パラメーターの設定により、/proc/kcore ファイルの内容がすべてのゼロとして生成されます。これにより、kdumpctl サービスは /proc/kcore にアクセスしず、KASLR(Kernel Address Space Layout Randomization)が有効な場合にクラッシュカーネルを読み込むことができません。この問題を回避するには、kptr_restrict1 に設定し続けます。これにより、kdumpctl は上記のシナリオでクラッシュカーネルを読み込むことができます。

詳細は、/usr/share/doc/kexec-tools/kexec-kdump-howto.txt ファイルを参照してください。

(BZ#1600148)

2 番目のカーネルで kdump が失敗する

kdump initramfs アーカイブはクラッシュダンプをキャプチャーするための重要なコンポーネントです。ただし、これは実行するマシン用に厳密に生成され、一般はありません。ディスクの移行またはディスクイメージを使用して新規マシンをインストールすると、2 番目のカーネルで kdump が失敗する場合があります。

この問題を回避するには、ディスクの移行を行う場合は、以下のコマンドを実行して initramfs を手動で再構築します。

# touch /etc/kdump.conf # kdumpctl restart

新しいマシンをインストールするためのディスクイメージを作成する場合には、ディスクイメージに kdump initramfs を含めないことが強く推奨されます。領域を節約するのに役立ち、不明な場合は kdump が自動的に initramfs を構築します。

(BZ#1723492)