排解因核心異常終止而導致的 Linux VM 啟動問題

本文說明如何疑難排解 VM 因核心錯誤而停止回應的問題。

如要瞭解其他開機失敗原因，以及如何自動偵測原因，請參閱「排解 Linux Compute Engine 執行個體開機問題」。

事前準備

  • 如要在 Cloud Logging 中記錄序列埠輸出內容，請先熟悉 Cloud Logging。
  • 如果尚未設定驗證，請先完成設定。驗證程序會確認您的身分，以便授予 Google Cloud 服務和 API 的存取權。如要從本機開發環境執行程式碼或範例，您可以選取下列其中一個選項，向 Compute Engine 進行驗證：

    選取這個頁面上範例的預計用途分頁：

    控制台

    使用 Google Cloud 控制台存取 Google Cloud 服務和 API 時，不需要設定驗證。

    gcloud

    1. 安裝 Google Cloud CLI。 完成後，執行下列指令來初始化 Google Cloud CLI：

      gcloud init

      如果您使用外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

  • 設定預設區域和可用區。

    • REST

    如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

      安裝 Google Cloud CLI。

      如果您使用外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

    詳情請參閱 Google Cloud 驗證說明文件中的「使用 REST 進行驗證」一節。

核心錯誤

如果核心無法正確載入客體 OS 啟動所需的 initramfs 模組，就可能發生核心錯誤。

另一種核心錯誤形式可能發生在核心不知道如何處理特定要求，並透過停止運作來保護自己的情況。執行 RedHat、SUSE、CentOS 或 Ubuntu 的 Compute Engine VM 可能會發生核心錯誤。

常見錯誤訊息

以下列舉一些最常見的參考用核心錯誤事件：

Kernel panic - not syncing: hung_task: blocked tasks
 
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Kernel panic - not syncing: NMI: Not continuing
 
Kernel panic - not syncing: out of memory. panic_on_oom is selected
 
Kernel panic - not syncing: Fatal Machine check

常見原因

造成核心錯誤的原因有很多，常見原因包括：

  • grub.cfg 檔案中沒有與核心對應的 initramfs 檔案相關項目。
  • 核心安裝期間，系統不會在 /boot 目錄中產生 initramfs 檔案。
  • initramfs 檔案僅部分生成或損毀。

問題

當 VM 執行個體發生核心錯誤時，常見的症狀是核心不允許您連線至 VM，即使使用序列控制台也一樣。

請檢查序列控制台記錄，找出客體 OS 載入的核心，例如：

[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-1160.95.1.el7.x86_64 (mockbuild@x86-vm-42.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Thu Aug 10 10:46:21 EDT 2023
此外，請檢查核心錯誤。這項錯誤通常會在 VM 啟動時顯示在核心行，或在序列主控台記錄結尾顯示，並伴隨多個堆疊呼叫追蹤記錄。

以下範例顯示因 initramfs 問題而發生的核心錯誤事件：

[    1.520840] No filesystem could mount root, tried:
[    1.520840]
[    1.521964] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.523495] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.0-1160.95.1.el7.x86_64 #1
[    1.524932] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
[    1.526901] Call Trace:
[    1.527421]  dump_stack+0x41/0x60
[    1.527978]  panic+0xe7/0x2ac
[    1.528578]  mount_block_root+0x2be/0x2e6
[    1.529693]  ? do_early_param+0x95/0x95
[    1.530441]  prepare_namespace+0x135/0x16b
[    1.531237]  kernel_init_freeable+0x203/0x22d
[    1.532081]  ? rest_init+0xaa/0xaa
[    1.532808]  kernel_init+0xa/0x103
[    1.533395]  ret_from_fork+0x35/0x40
[    1.535229] Kernel Offset: 0x23a00000 from 0xffffffff81000000

解決核心恐慌錯誤

如要解決核心錯誤，請按照下列步驟操作：

  1. 連線至序列埠控制台， 並從 Google Cloud 控制台登入 VM。

  2. 在 Google Cloud 控制台中，按一下 VM 的「Reset」(重設)。

  3. GRUB 啟動畫面顯示後，請選取先前可正常運作的核心或救援核心，然後啟動系統。這會導致 VM 以所選核心啟動。

    核心錯誤

  4. VM 可供存取後，您就能啟動與 VM 的 SSH 連線。

  5. 找出問題原因，並據此採取進一步行動。

    舉例來說，如果 initramfs 檔案遺失或損毀，請完成下列步驟：

    1. 使用 dracut 指令，產生與原始核心對應的 initramfs 檔案：

      dracut -f /boot/initramfs-KERNEL_VERSION.img KERNEL_VERSION

      將 KERNEL_VERSION 替換為 VM 目前的核心版本。例如：3.10.0-1160.95.1.el7.x86_64。

    2. 使用 grub2-mkconfig 指令更新 grub2.cfg 檔案，例如：

      grub2-mkconfig -o /boot/grub2/grub.cfg

    3. initramfs 檔案產生後，您就可以重新啟動 VM，不會發生任何錯誤。