次の方法で共有

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

  • [アーティクル]

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

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

前提条件

Linux VM で シリアル コンソール が有効で機能していることを確認します。

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

Azure portalを使用して、ブート 診断 ブレード、シリアル コンソール ブレード、または 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

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

パニック メッセージ 理由
Oops: 0000 [#1] SMP " (詳細についてはチェック ログ) 不適切なアドレスを逆参照したため、システムがパニックに陥りました。
SysRq: クラッシュ ダンプをトリガーする コア ダンプは、sysrq-c または /proc/sysrq-trigger に c をエコーすることによって、ユーザーによって開始されました。
pathname/filename>:<line number> の <kernel BUG! この形式は、失敗した BUG チェックの標準です (ASSERT と同じですが、ロジックは反転されます)。 ファイル名と行番号は、失敗した BUG チェックを示します。
カーネル パニック - 同期しない: softlockup: ハングしたタスク ソフト ロックアップ検出器は、ソフト ロックアップしきい値内でウォッチドッグ タスクをスケジュールしていない CPU を検出しました。
カーネル パニック - 同期していない: Cpu 0 でウォッチドッグによってハード LOCKUP が検出されました ハード ロックアップ検出器は、ハード ロックアップしきい値内で hrtimer 割り込みを受信していない CPU を検出しました。
カーネル パニック - 同期しない: hung_task: ブロックされたタスク ハングしたタスク ウォッチドッグは、ブロックされたタスクのタイムアウト値を超える中断できない状態にあるタスクを少なくとも 1 つ検出しました。
カーネル パニック - 同期していない: メモリ不足。 panic_on_oomが選択されている システムはメモリを使い果たしてスワップを行い、強制強制実行プロセスを開始してメモリを解放しました (既定の動作ではありません)。
カーネル パニック - 同期しない: メモリ不足で、強制終了可能なプロセスがありません.... システムはメモリを使い果たしてスワップし、メモリを解放するためにプロセスを強制終了していますが、強制終了するプロセスが不足しています。
カーネル パニック - 同期していない: NMI が発生しました。詳細については、統合管理ログを参照してください。 ウォッチドッグが NMI (マスク不可割り込み) をインターセプトしました。
カーネル パニック - 同期していない: NMI IOCK エラー: 続行しない システムは、(メモリ パリティ エラーではなく) ハードウェアから IO チェック NMI を受け取り、kernel.panic_on_io_nmiが設定されました (既定値ではありません)。
カーネル パニック - 同期しない: NMI: 続行しない システムは NMI (ハードウェアまたはメモリ パリティ エラー) を受け取り、kernel.panic_on_unrecovered_nmiが設定されました (既定値ではありません)。
カーネル パニック - 同期しない: nmi watchdog システムは NMI を受け取り、kernel.panic_on_timeoutまたはkernel.panic_on_oopsが設定されました (既定値ではありません)。
カーネル パニック - 同期しない: 致命的なマシン チェック 致命的な条件チェック例外イベントが発生したマシン。
カーネルパニック - 同期していない:initを殺そうとしました! init プロセスは、最初に開始されるプロセスであり、終了しないでください。

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

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

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

シナリオ 1 の解決策

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

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

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

方法 2: レスキュー VM を使用したオフライン修復

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

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

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

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

シナリオ 2 の解決策

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

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

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

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

ドキュメント シナリオ
ホスト ノードのアップグレード後に 3.10 ベースのカーネル上の Azure Linux VM がパニックする この記事では、Azure でホスト ノードのアップグレード後に 3.10 ベースのカーネルを実行している Azure Linux VM がクラッシュしたときに発生する問題について説明します。
カーネル関連のブートの問題から Azure Linux 仮想マシンを回復する方法 この記事では、カーネルの変更を適用した後に Linux 仮想マシン (VM) を再起動できない問題の解決策について説明します。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。