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

  • [アーティクル]

適用対象: ✔️ 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 をエコーすることによって、ユーザーによって開始されました。
kernel BUG at <pathname/filename>:<line number>! この形式は、失敗したバグ チェックの標準です (ASSERT と同じですが、ロジックは反転されます)。 ファイル名と行番号は、失敗した BUG チェックを示します。
カーネル パニック - 同期していない: ソフトロックアップ: ハングしたタスク ソフト ロックアップ検出機能により、ソフト ロックアップしきい値内でウォッチドッグ タスクをスケジュールしていない 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 ウォッチドッグ システムが NMI を受信し、kernel.panic_on_timeoutまたはkernel.panic_on_oopsが設定されました (既定値ではありません)。
カーネル パニック - 同期していない: 致命的なマシン チェック 致命的な状態に対してマシン チェック例外イベントが発生しました。
カーネルパニック - 同期していない:initを殺そうとしました! init プロセスは最初に開始されるプロセスであり、終了しないでください。

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

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

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

シナリオ 1 の解決策

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

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

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

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

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

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

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

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

シナリオ 2 の解決策

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

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

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

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

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

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

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