8.8. カーネル
RHEL 9 カーネルで kdump サービスが起動しない
RHEL 9 カーネルには、crashkernel=auto パラメーターがデフォルトとして設定されていません。そのため、デフォルトでは kdump が起動できません。
この問題を回避するには、crashkernel= オプションを必要な値に設定します。
たとえば、grubby ユーティリティーを使用して 256 MB のメモリーを確保するには、以下のコマンドを入力します。
# grubby --args crashkernel=256M --update-kernel ALL
その結果、RHEL 9 カーネルは kdump を開始し、設定されたメモリーサイズの値を使用して vmcore ファイルをダンプします。
(BZ#1894783)
kdump メカニズムは LUKS 暗号化ターゲットで vmcore ファイルをキャプチャーできない
Linux Unified Key Setup (LUKS) で暗号化されたパーティションを使用するシステムで kdump を実行する場合、システムには一定量の使用可能なメモリーが必要です。使用可能なメモリーが必要なメモリー量より少ない場合、systemd-cryptsetup サービスはパーティションのマウントに失敗します。その結果、2 番目のカーネルは LUKS 暗号化ターゲット上のクラッシュダンプファイル (vmcore) のキャプチャに失敗します。
kdumpctl Estimate コマンドを使用すると、kdump に必要な推奨メモリーサイズである 推奨クラッシュカーネル値 を照会できます。
この問題を回避するには、次の手順を使用して、LUKS 暗号化ターゲットで kdump に必要なメモリーを設定します。
推定
crashkernel値を出力します。# kdumpctl estimate
crashkernelの値を増やして、必要なメモリー量を設定します。# grubby --args=crashkernel=652M --update-kernel=ALL
システムを再起動して、変更を反映させます。
# reboot
これにより、LUKS で暗号化したパーティションがあるシステムで kdump が正常に機能します。
(BZ#2017401)
起動時にクラッシュカーネルメモリーの割り当てに失敗する
特定の Ampere Altra システムでは、利用可能なメモリーが 1 GB 未満の場合に、起動中に kdump の使用に対してクラッシュカーネルメモリーの割り当てに失敗します。その結果、必要なメモリーが使用可能なメモリーサイズを超えているため、kdumpctl コマンドは kdump サービスの開始に失敗します。
回避策として、crashkernel パラメーターの値を 240 MB 以上減らしてサイズ要件に合わせます (例 : crashkernel=240M)。その結果、Ampere Altra システムで kdump のクラッシュカーネルメモリー割り当てが失敗しなくなりました。
kTLS は、TLS 1.3 の NIC へのオフロードをサポートしない
Kernel Transport Layer Security(kTLS) は、TLS 1.3 の NIC へのオフロードをサポートしていません。そのため、NIC が TLS オフロードをサポートしていても、TLS 1.3 によるソフトウェア暗号化が使用されます。この問題を回避するには、オフロードが必要な場合は TLS 1.3 を無効にしてください。その結果、TLS 1.2 のみをオフロードすることができます。TLS 1.3 が使用されている場合、TLS 1.3 をオフロードすることができないため、パフォーマンスが低下します。
(BZ#2000616)
Secure Boot で fadump を有効にすると、GRUB Out of Memory (OOM) が発生する可能性があります。
Secure Boot 環境では、GRUB と PowerVM は、ブートメモリー用に、RMA (Real Mode Area)と呼ばれる 512 MB のメモリー領域を割り当てます。リージョンはブートコンポーネントに分割され、いずれかのコンポーネントが割り当てを超えると、メモリー不足の問題が発生します。
通常、デフォルトでインストールされている initramfs ファイルシステムと vmlinux シンボルテーブルは、このような障害を回避するために割り当て制限内に抑えられています。ただし、システムで Firmware Assisted Dump (FADump) が有効になっている場合は、デフォルトの initramfs サイズが増加して 95 MB を超える可能性があります。これにより、システムを再起動するたびに GRUB OOM 状態になります。
この問題を回避するには、Secure Boot と FADump を一緒に使用しないでください。この問題の回避方法は、link:https://www.ibm.com/support/pages/node/6846531 を参照してください。
(BZ#2149172)
Secure Boot のシステムは、動的 LPAR 操作を実行できません。
以下の条件のいずれかが満たされた場合、ユーザーはハードウェア管理コンソール (HMC) から動的論理パーティション (DLPAR) 操作を実行できません。
-
Secure Boot 機能は、整合性モードでカーネル
ロックダウンメカニズムを暗黙的にオンにする機能が有効になっている。 -
カーネル
ロックダウンメカニズムが、整合性モードまたは機密性モードで手動で有効にされている。
RHEL 9 では、カーネルの lockdown により、/dev/mem 文字デバイスファイルからアクセスできるシステムメモリーへの RunTimeAbstraction Services (RTAS) アクセスが完全にブロックされています。正しく機能させるには、いくつかの RTAS 呼び出しで /dev/mem への書き込みアクセスが必要です。したがって、RTAS 呼び出しが正しく実行されず、ユーザーには以下のエラーメッセージが表示されます。
HSCL2957 Either there is currently no RMC connection between the management console and the partition <LPAR name> or the partition does not support dynamic partitioning operations. Verify the network setup on the management console and the partition and ensure that any firewall authentication between the management console and the partition has occurred. Run the management console diagrmc command to identify problems that might be causing no RMC connection.
(BZ#2083106)
64 ビット ARM CPU で正しくコンパイルされたドライバーでのプログラム失敗に関して dkms が誤った警告を出す
Dynamic Kernel Module Support (dkms) ユーティリティーは、64 ビット ARM CPU のカーネルヘッダーが、ページサイズが 4 キロバイトのカーネルと 64 キロバイトのカーネルの両方で動作することを認識しません。その結果、dkms は、カーネルの更新時に kernel-64k-devel パッケージがインストールされていない場合、正しくコンパイルされたドライバーでプログラムが失敗した理由に関して誤った警告を出します。この問題を回避するには、kernel-headers パッケージをインストールします。このパッケージは、両タイプの ARM CPU アーキテクチャー用のヘッダーファイルを含むもので、dkms とその要件に特化したものではありません。
(JIRA:RHEL-25967)
