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
一些最常見的核心異常事件：
| 恐慌訊息 | 原因 |
|---|---|
| 糟糕： 0000 [#1] SMP “ （檢查記錄以取得詳細數據） | 系統因取值錯誤而造成系統恐慌。 |
| SysRq：觸發當機傾印 | 核心傾印是以 sysrq-c 起始，或透過將 c 回應至 /proc/sysrq-trigger 來起始。 |
| pathname/filename>：<line number> 的 <kernel BUG！ | 此格式是失敗 BUG 檢查的標準（就像 ASSERT 一樣，但邏輯是反轉的）。 檔名和行號會指出哪個 BUG 檢查失敗。 |
| 核心異常 - 未同步處理：軟鎖：已停止工作 | 軟鎖定偵測器發現 CPU 未在軟鎖定閾值內排程監視程式工作。 |
| 核心異常 - 未同步處理：監視程序偵測到 CPU 0 上的硬式 LOCKUP | 硬式鎖定偵測器發現 CPU 在硬式鎖定閾值內未收到任何 hrtimer 中斷。 |
| 核心異常 - 未同步處理：hung_task：封鎖的工作 | 已停止的工作監視程序偵測到至少有一個工作處於無法中斷狀態，超過封鎖的工作逾時值。 |
| 核心異常 - 未同步處理：記憶體不足。 已選取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進程是第一個要啟動且不應該結束的進程。 |
| 核心異常 - 未同步處理：VFS：無法在未知區塊上掛接根 fs（0,0） | 假設核心會使用 initramfs 掛接 rootfs。 當核心沒有 initramfs 時，就會發生此錯誤。 |
案例 1：開機時發生核心異常
開機時發生核心異常，可防止 VM 完成作業系統啟動程式。 每次啟動虛擬機時都會發生，且不允許登入。
這種事件通常相關，但不限於：
- 最近的核心升級。
- 最近的核心降級。
- 核心模組變更。
- 操作系統設定變更 （GRUB、sysctl 和 SELinux）。
- 遺漏重要的檔案和目錄。
- 遺漏重要的系統核心連結庫和套件。
- 檔案的許可權錯誤。
- 遺漏數據分割。
案例 1 的解決方案
若要處理這類核心異常狀況，可以使用下列方法：
方法 1：使用 Azure 序列控制台
使用 Azure 序列控制台來中斷開機程式，並選取先前的核心版本，如果有的話。 如此一來，VM 就可以再次開機，然後使用下列其中一種方法來修正非開機核心的特定問題：
方法 2：使用救援 VM 脫機修復
如果 Azure 序列主控台無法使用或沒有先前的核心可用，您需要救援/修復 VM 才能進行離線修復。
使用 [ 修復 VM ] 命令 來建立已鏈接目標 VM OS 磁碟復本的修復 VM。 然後使用 chroot 掛接修復 VM 中的 OS 檔案系統複本。 之後，請嘗試下列方法來修正核心問題：
案例 2：運行時間的核心異常
在操作系統啟動程式完成之後，這種核心異常通常會在無法預期的時候觸發，並導致 VM 停止回應，防止其登入。 它通常相關，但不限於：
- 最近的核心升級。
- 最近的核心降級。
- 核心模組變更。
- 操作系統設定變更 （GRUB、sysctl 和 SELinux）。
- 應用程式工作負載變更。
- 應用程式開發變更或 Bug。
- 可能的內核錯誤。
- 效能相關問題。
案例 2 的解決方案
若要處理這類核心異常狀況，可以使用下列方法：
- 檢閱資源使用量和整體系統效能。 核心恐慌可能與可能導致 VM 重設大小的資源短缺有關。
- 可能的話，請安裝對應 Linux 發行版存放庫中可用的最新更新。 核心異常可能與核心或其他軟體中的已知錯誤有關。
- 核心異常有可能與最近的核心變更有關，在此情況下，建議您透過先前的核心版本開機，如案例 1 的解決方式中所述。
- 如果上述選項不適用，可能需要設定 kdump 併產生核心傾印，以與支持共用以進行進一步分析。
更具體的核心異常案例
具有特定疑難解答/復原指示的常見核心異常案例：
| Document | 案例 |
|---|---|
| 主機節點升級後 Azure Linux VM 上發生以 3.10 為基礎的核心異常 | 本文討論在 Azure 中執行 3.10 核心的 Azure Linux VM 在主機節點升級後當機時所發生的問題。 |
| 如何從核心相關的開機問題復原 Azure Linux 虛擬機器 | 本文提供Linux虛擬機在套用核心變更之後無法重新啟動的問題解決方案。 |
與我們連絡，以取得說明
如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。