Azure Linux VM でのカーネル パニック

適用対象: ✔️ Linux VM

まとめ

この記事では、カーネル パニックを引き起こす可能性がある複数の条件について説明し、トラブルシューティングのガイダンスを提供します。

一般に、カーネル パニックは、カーネルが正しく読み込むことができないため、システムの起動に失敗する状況です。 カーネル パニックの別の形式は、カーネルが処理方法を知らない状況に遭遇し、停止することによって自分自身を保護するときに発生します。

前提条件

コンソールが有効になっており、Linux VM で機能していることを確認します。

カーネル パニックを特定する方法

Azure ポータルを使用して、ブート診断ブレード、シリアル コンソール ブレード、または AZ CLI で VM のシリアル コンソール ログ出力を表示し、特定のカーネル パニック文字列を特定します。

カーネルパニックは以下の出力に似た形で表示され、シリアルコンソールログの最後に現れます。

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

最も一般的なカーネル パニック イベントの一部:

シナリオ 1: 起動時にカーネル パニックが発生する

起動時にカーネル パニックが発生すると、VM はオペレーティング システムの起動プロセスを完了できなくなります。 これは、仮想マシンが起動されるたびに発生し、ログインを許可しません。

この種のイベントは一般的に関連していますが、これらに限定されません。

• 最近のカーネル アップグレード。
• 最近のカーネルのダウングレード。
• カーネル モジュールの変更。
• オペレーティング システムの構成の変更 (GRUB、sysctl、SELinux)。
  • SELinux の問題。
• 重要なファイルとディレクトリがありません。
• 重要なシステム コア ライブラリとパッケージがありません。
• ファイルに対するアクセス許可が正しくありません。
• パーティションがありません。

シナリオ 1 の解決策

この種のカーネル パニックに対処するには、次の方法を使用できます。

方法 1: Azureシリアル コンソールを使用する

Azureシリアル コンソールを使用してブート プロセスを中断し、使用可能な場合は以前のカーネル バージョンを選択します。 これにより、VM を再度起動できるようになります。その後、次のいずれかの方法を使用して、非起動カーネルの特定の問題を修正できます。

• 不足している initramfs を再生成または再インストール。
• 問題のあるカーネルを再インストールします。
• 読み込まれたカーネル モジュールまたは不足しているカーネル モジュールを確認します。
• パーティションを確認します。

方法 2: 復旧 VM を使用したオフライン修復

Azureシリアル コンソールを使用できない場合、または以前のカーネルを使用できない場合は、オフライン修復を行うために復旧/修復 VM が必要です。

Repair VM コマンドを使用して、ターゲット VM の OS ディスクのコピーがアタッチされている修復 VM を作成します。 次に、 chroot を使用 修復 VM に OS ファイル システムのコピーをマウントします。 その後、カーネルの問題を修正するには、次の方法を試してください。

• 不足している initramfs を再生成または再インストール。
• 問題のあるカーネルを再インストールします。
• 読み込まれたカーネル モジュールまたは不足しているカーネル モジュールを確認します。
• パーティションを確認します。
• 不足しているファイルを回復。
• 不足している重要なシステム コア ライブラリとパッケージを回復します。

シナリオ 2: 実行時のカーネル パニック

この種のカーネル パニックは、通常、オペレーティング システムの起動プロセスが完了した後に予期しない時間にトリガーされ、VM が応答を停止し、ログインを妨げます。 これは一般的に関連しますが、次に限定されません。

• 最近のカーネル アップグレード。
• 最近のカーネルのダウングレード。
• カーネル モジュールの変更。
• オペレーティング システムの構成の変更 (GRUB、sysctl、SELinux)。
  • SELinux の問題。
• アプリケーション ワークロードの変更。
• アプリケーション開発の変更またはバグ。
• カーネルのバグの可能性。
• パフォーマンス関連の問題。

シナリオ 2 の解決策

この種のカーネル パニックに対処するには、次の方法を使用できます。

• リソースの使用状況とシステムの全体的なパフォーマンスを確認します。 カーネル パニックは、VM のサイズ変更につながる可能性のあるリソースの不足に関連している可能性があります。
• 可能であれば、対応する Linux ディストリビューション リポジトリで利用可能な最新の更新プログラムをインストールします。 カーネル パニックは、カーネルまたはその他のソフトウェアの既知のバグに関連している可能性があります。
• カーネル パニックが最近のカーネルの変更に関連している可能性があります。その場合は、シナリオ 1 の Resolution で説明されているように、以前のカーネル バージョンで起動することをお勧めします。
• 上記のオプションが該当しない場合は、kdump を構成し、さらに分析をサポートして共有するコア ダンプを生成することが必要な場合があります。

より具体的なカーネル パニック シナリオ

特定のトラブルシューティング/回復手順を使用する一般的なカーネル パニック シナリオ: