當 Linux Kernel 發生 Panic 時

作為作業系統的提供者，我們幾乎和 Kernel 一起陷入恐慌。這會自動觸發團隊放下手邊的所有工作，立刻投入問題的解決。如果無法快速修復，後果可能十分嚴重。

當作業系統無法啟動

此時選項極其有限：

• 系統無法執行任何指令或診斷工具。
• 無法查看日誌，也無法透過網路遠端存取。
• 這時只能依賴老式的序列控制台。

高端伺服器通常有 BMC/IPMI 作為帶外通道，透過序列連線控制並操作目標機器。如果缺乏這種設備，可以使用網路可訪問的 IP-VGA 或 DIY 的控制台伺服器（帶多個 RS232 接口）。最糟糕的情況是，需親自到現場使用 KVM 顯示器操作，並希望客戶不要在旁盯著。

Kernel Panic 常見原因

多數 Kernel Panic 案例與驅動程式有關，特別是檔案系統的驅動程式。Linux 的根目錄（/）及其子目錄檔案位於檔案系統內，一般是磁碟上的格式化分區。啟動流程如下：

1. 按下電源鍵後，BIOS/UEFI 啟動，並根據啟動順序加載作業系統。
2. 為識別檔案系統，系統需要載入相關驅動程式。
3. 加載的系統通常是 initramfs，這是一個臨時操作系統。

當 initramfs 成功執行時，問題較易處理，至少能進入啟動流程的各個階段，透過修改 Kernel 參數調查問題。以下是我的檢查重點：

• 驅動程式是否缺失？
• 路徑是否正確？
• 驅動程式是否載入？
• 硬碟是否被檢測到？
• 檔案系統是否被識別？
• 資料夾是否掛載並包含內容？
• 環境變數是否設置正確？
• switchroot 是否成功？

但今天遇到的問題超出了上述範圍。

實際案例

在 initramfs 解壓後，Kernel 崩潰了，列出了驅動程式卻無法告知崩潰原因。我嘗試修改參數（如 initramfs_size、acpi），但未成功。排除硬體問題（如記憶體、硬碟、主板）後，檢查 CI/CD 的最後釋出版本，確認之前的韌體仍正常運作。

問題根源：

比較變更集後，發現 Kernel 版本略有差異：

• kernel-4.18.0-348
• kernel-4.18.0-373

建置流程中，透過 RPM 套件管理器解析依賴並安裝套件。雖然保持套件最新並節省儲存空間，但每次建置都有潛在差異。這次是小版本差異導致 Kernel Panic。

解決步驟

鎖定 Kernel 套件版本：

sh-4.4# dnf install -y 'dnf-command(versionlock)'
sh-4.4# dnf -y install kernel-core-4.18.0-348.el8.x86_64 \\\\
kernel-modules-4.18.0-348.el8.x86_64 \\\\
kernel-headers-4.18.0-348.el8.x86_64 \\\\
kernel-4.18.0-348.el8.x86_64 \\\\
kernel-modules-extra-4.18.0-348.el8.x86_64

sh-4.4# dnf versionlock add