VPS 更新核心後無法開機怎麼辦？

VPS 在更新核心後無法開機時，第一步該做什麼

VPS 在更新核心後無法開機時，通常可以在幾分鐘內復原，因為這次更新並未刪除昨天仍能正常運作的核心。Ubuntu 會將新核心安裝在舊核心旁邊，只變更 GRUB 預設啟動的項目。因此，第一步不是修復系統，而是在開機選單中選取上一個核心，先恢復登入提示，再從正在執行的系統進行診斷。

在伺服器上處理這個問題，方式不同於修復筆記型電腦，因為伺服器沒有連接鍵盤，也沒有螢幕顯示 kernel panic。SSH 也不會回應，因為系統尚未執行到啟動 sshd 的階段。以下所有操作都必須透過供應商的 console 進行。

變更任何設定前，先閱讀自己的 console。畫面上的文字會決定問題屬於哪一類；兩台都「無法開機」的伺服器，可能需要完全相反的修復方式。

SSH 無法使用時，如何進入主控台？

開啟供應商的控制面板，尋找主控台功能。常見名稱包括 VNC console、web console、noVNC 和 serial console。如果兩者皆有，優先使用 serial console，因為它會提供可捲動及複製的純文字內容；VNC 畫面則只是一張螢幕影像。請在機器狀態正常時立即找出這項功能，並確認可以開啟。等到服務中斷時才尋找，會讓你在最需要保持冷靜時浪費時間。這項檢查應列入新 VPS 上線後的前 10 分鐘，與防火牆規則及 SSH keys 一併完成。

大多數控制面板也提供 rescue mode 或 recovery image。它會從供應商的網路啟動小型系統，並將你的磁碟附加為額外裝置，因此磁碟上的任何系統都不會執行。當 GRUB 本身損壞時，rescue mode 是備援方式；如果你決定不再救援某台伺服器，也可以使用它將資料複製出來。

通常必須從控制面板執行 hard reset，才能進入開機選單，因為你無法在無法登入的機器上執行 sudo reboot。hard reset 等同於切斷電源。檔案系統會處於非正常關機狀態，因此下次開機時可能會執行檔案系統檢查。

如何在 GRUB 選單中選擇較舊的 kernel？

從按下 reset 的那一刻起監看主控台。在最初幾秒內反覆按下 Esc；如果機器使用 legacy BIOS 模式開機，則按住 Shift。可操作的時間很短，而主控台檢視器通常需要 1 秒才能連線，因此請提早開始按鍵，並持續按下。

選單出現後，選擇「Ubuntu 的進階選項」。該子選單會列出所有已安裝的 kernel，最新版本在最上方；每個 kernel 也各有一個 recovery mode 項目。選擇第 2 個一般項目，也就是位於最新版本下方的 kernel，然後按 Enter。recovery mode 是另一種模式：它會開機進入最小化的 single user 系統，用於修復工作，不是用來讓服務恢復上線。

如果較舊的 kernel 能夠開機，表示伺服器已恢復執行。確認目前使用的 kernel，並記下版本號碼。

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

dpkg 的輸出就是已安裝 kernel 的清單。如果只有 1 行，表示完全沒有 fallback，這是首先要修正的問題。

GRUB 選單完全沒有出現。該怎麼辦？

Cloud image 通常會隨附隱藏選單的設定。Ubuntu image 通常會在 /etc/default/grub.d/ 下的檔案中將 timeout 設為 0，因此會立即啟動最新的 kernel，沒有任何可按的按鍵。

另一種情況則相反：選單顯示在畫面上並等待操作，看起來像是系統卡住。GRUB 會記錄啟動失敗，下一次啟動時可能會停留在選單，直到有人按下按鍵。沒有鍵盤的主機會永遠停在這裡。如果主控台顯示選單且畫面沒有變化，就是發生了這種情況。選取一個項目後繼續啟動。

請在機器運作正常時同時修正這兩種情況。編輯 /etc/default/grub：

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

接著套用設定，並確認你的修改仍然存在，因為 /etc/default/grub.d/ 中的檔案會在 /etc/default/grub 之後讀取，可能覆寫你的設定。

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" 會將選單顯示到圖形主控台和 serial port，因此無論面板提供哪一種檢視器，都能看到選單。console= kernel arguments 也會將後續的啟動訊息輸出到相同位置。每次啟動延遲 10 秒，換來凌晨 2 點仍能實際存取的選單，代價很低。

我遇到的是哪一類故障？

查看主控台停止更新前的最後 20 行。核心更新後的狀況，大多可歸入以下 4 種模式。

GRUB 找不到自己的檔案。 你會看到 grub rescue> 提示字元，或看到分割區或檔案不存在的錯誤，而且完全沒有核心訊息出現。此時核心尚未開始執行。這通常是磁碟或分割區變更，或 bootloader 寫入錯誤裝置所造成，不是單靠核心套件引起的問題。

核心啟動，但無法掛載 root。 畫面會持續顯示核心訊息，接著進入提示字元為 (initramfs) 的 busybox shell，或以無法掛載 root filesystem 的 kernel panic 結束啟動流程。核心已成功載入。initramfs 是用來尋找並掛載實際 root filesystem 的小型暫存 root，但它找不到磁碟。在 Ubuntu 上，這個 shell 通常會先顯示放棄等待 root device 的訊息，並列出所需的 UUID。複製該 UUID，稍後與 blkid 的輸出比對。

Logical volume 從未出現。 這是上一類問題的一種特定原因。在 (initramfs) 提示字元下執行 ls /dev/mapper。如果唯一的項目是 control，表示沒有啟用任何 LVM (logical volume manager) volume，因此 root device 尚不存在。手動啟用 volume group：

lvm vgchange -ay
ls /dev/mapper
exit

exit 會將控制權交回 initramfs script，讓它重新嘗試掛載。如果系統接著成功啟動，表示新的 initramfs 缺少 LVM 元件。修復方式是重新建立該映像，而不是處理核心本身。

完全沒有 Linux 訊息。 主控台只顯示 firmware 文字、UEFI (unified extensible firmware interface) shell、沒有核心輸出的空白畫面，或不斷重新啟動。故障發生在 Linux 執行之前。系統恢復後，請確認伺服器實際使用的啟動模式，因為許多 VPS 執行個體以 legacy BIOS 模式啟動，完全不會使用 EFI 路徑：

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

在 UEFI 機器上，升級期間未掛載 /boot/efi 是常見原因。維護 EFI system partition 的套件因此會改寫一般的空目錄。firmware 會持續啟動舊的 boot entry，直到該項目與磁碟上的內容不再相符。

還有一種情況根本不是啟動失敗。如果你進入顯示系統處於 emergency mode 的 root shell，表示核心已啟動，但 userspace 停止執行。通常原因是 /etc/fstab 中有錯誤的設定行，或 filesystem 檢查失敗。在該 shell 中執行 journalctl -xb，並查看失敗的 unit 名稱。

核心套件損壞，還是 initramfs 損壞？

這兩種問題在主控台上的現象看起來相同，但修復方式不同。先啟動舊版核心，再比較檔案。

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

每個已安裝版本都應有一個 vmlinuz- 和一個相符的 initrd.img-，且檔案大小應合理。若缺少 initrd，或其大小明顯小於其他版本，表示 initramfs 產生失敗。最常見的原因是 /boot 已滿，套件日誌中會留下相關證據：

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log 也會確切列出最近幾次執行所安裝的套件及時間，可據此確認哪些內容發生變更。

如果 /boot 已滿，先釋放磁碟空間，再為所需版本重建映像並更新選單。請從自己的 ls 輸出取得版本字串，因為下方的預留值不是真實版本：

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

最後的 ls 用於確認結果。檔案大小正常表示映像已建立。若核心映像本身損壞，或 dpkg -l 顯示套件狀態不是 ii，請重新安裝套件：

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

從 rescue mode 修復，讓沒有任何 kernel 能啟動的系統恢復

如果選單中的每個項目都失敗，請啟動供應商提供的 rescue image，從系統外部修復磁碟。此時磁碟會顯示為未掛載的裝置，因此磁碟上的任何內容都沒有執行，也不會干擾修復作業。

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

測試新 kernel，避免影響下次開機

GRUB 可以僅啟動某個項目一次，之後返回您選定的預設項目。將預設項目指定為您信任的 kernel，再僅啟動新 kernel 一次。若啟動失敗，從控制面板執行硬重設後，系統就會返回正常的 kernel，無須掌握主控台的操作時機。

在 /etc/default/grub 中設定 GRUB_DEFAULT=saved，執行 sudo update-grub，然後列出項目標題，以便完整指定其中一個：

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list 應將您選定的標題輸出為 saved_entry。這項輸出可證明機制正常運作，因為儲存設定需要可寫入的 /boot/grub/grubenv，而在部分配置中該檔案可能會靜默地變成不可寫入。項目 0 位於選單最上方，也就是最新的 kernel。這裡使用標題比使用數字更安全，因為每次安裝或移除 kernel 時，數字都會變動。

為什麼在無頭主機上執行 autoremove 具有風險

APT 會維護一份不得自行移除的 kernel 套件清單。請查看目前的清單：

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

每當 kernel 套件變更時，系統就會重新產生這份檔案。它會保護目前正在執行的 kernel，以及最近使用的 kernel。問題在於執行時機。重新開機並使用新的 kernel 啟動後，立即執行 sudo apt autoremove --purge，受保護清單就已經更新。因此，你原本依賴的舊 kernel 不再受到保護。對有鍵盤可用的機器而言，這只是個不便。對無頭伺服器而言，這可能決定你是能選取開機選單項目，還是必須從救援映像檔掛載磁碟。

至少保留 2 個 kernel；/boot 空間足夠時，保留 3 個。先檢查 uname -r，再依名稱移除舊 kernel。這樣就不會刪除目前正在使用的 kernel：

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

之後再次執行上一個指令。數量從 3 個降至 2 個表示完成清理。數量降至 1 個，則表示下一次重新開機時可能發生服務中斷。

升級前建立快照

在執行 apt upgrade 前建立的快照，是唯一不依賴任何系統啟動程序的復原途徑。還原快照後，磁碟會回到舊版 kernel 設為預設值的狀態，您可以在已開啟主控台的情況下重新嘗試升級。執行中的機器所建立的快照具有當機一致性，表示快照擷取的是彷彿突然斷電時的磁碟狀態。因此，若您的供應商支援離線快照，請先關閉伺服器再建立快照。快照也不是備份，因為快照通常與其複製的 volume 位於同一套基礎架構。了解 VPS 快照與真正備份的差異，才能判斷在故障範圍超出 kernel 時，哪一種方式能協助您復原。

這在 release upgrade 中尤其重要，因為 kernel、initramfs 工具、bootloader 與 GRUB 設定會在同一次執行中一併變更。請在開始執行 Ubuntu 24.04 升級至 26.04 前立即建立快照，不要提前一晚建立，這樣還原點才會與即將變更的機器狀態一致。

unattended-upgrades 如何處理 kernel 套件

Ubuntu 的 unattended-upgrades 會在不詢問的情況下安裝安全性更新，kernel 套件也和其他套件一樣，透過 security pocket 取得。這會帶來兩個結果。

首先，新 kernel 已經安裝，但目前尚未執行。kernel 只有在開機時才會生效。系統會建立 /var/run/reboot-required，而 /var/run/reboot-required.pkgs 會記錄要求重新開機的原因；但除非你在 /etc/apt/apt.conf.d/50unattended-upgrades 中啟用 Unattended-Upgrade::Automatic-Reboot，否則系統不會自行重新啟動。

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

其次，這段落差會掩蓋原因。伺服器可能在 3 月安裝 kernel，直到 6 月因完全無關的原因重新開機，之後才無法正常啟動。導致開機失敗的變更已經過了 3 個月，因此你當天執行的操作無法解釋問題。請在 /var/log/apt/history.log 中尋找安裝目前導致開機失敗之 kernel 的那次執行紀錄。

請在你指定的日期主動重新開機，並事先開啟 console 視窗。這個單一習慣能將難以追查的服務中斷，轉變為只需 2 分鐘選取選單的操作。如果你希望保有自動化但避免意外，請維持自動安裝開啟、自动重新開機關閉，並參閱 如何在 Ubuntu 上設定 unattended-upgrades 取得確切設定。使用 sudo apt-mark hold linux-image-generic 保留 kernel 套件會完全停止這些套件的更新，也會同時停止 kernel 安全性修正，因此應將此視為你決定採取的取捨，而不是安全措施。

FAQ

如何在沒有鍵盤的 VPS 上啟動較舊的 kernel？

開啟供應商提供的主控台（VNC 或 serial），並從控制面板觸發 hard reset，因為您無法登入後正常重新開機。機器重新啟動時，反覆按下 Esc；若使用 legacy BIOS boot，則按住 Shift，讓 GRUB 選單停留在畫面上。選取「Ubuntu 的進階選項」，再選擇位於最新 kernel 下方的項目。出現登入提示後，執行 uname -r 確認目前使用的 kernel，並執行 dpkg -l 'linux-image-*' 查看已安裝的其他 kernel。系統恢復執行後，再開始診斷問題。

為什麼我的 VPS 完全沒有顯示 GRUB 選單？

Cloud image 通常會在 /etc/default/grub.d/ 下的檔案中，將 GRUB timeout 設為 0，因此不會等待按鍵就直接啟動最新的 kernel。在 /etc/default/grub 中設定 GRUB_TIMEOUT=10 與 GRUB_TIMEOUT_STYLE=menu，加入 GRUB_TERMINAL="console serial"，讓選單也能輸出到 serial console，然後執行 sudo update-grub。使用 grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/ 驗證設定，因為該目錄中的檔案會在主檔案之後讀取，可能覆寫您的修改。

應該移除舊的 kernel 以釋放 /boot 的空間嗎？

移除最舊的 kernel，並至少保留 2 個。/boot 已滿本身就是一種故障模式，因為此時 initramfs generation 會失敗，最後只剩沒有可用 image 的 kernel。先檢查 uname -r，再依確切的 package name 執行 purge，確保目前執行中的 kernel 不會成為移除對象。在 headless machine 上，避免直接執行 sudo apt autoremove --purge，因為 protected-kernel list 會在每次 kernel 變更時重新產生；若執行時機不當，可能只剩 1 個 kernel，且選單中沒有 fallback entry。

unattended-upgrades 會導致無法開機嗎？

它可能安裝之後無法啟動的 kernel，但除非 /etc/apt/apt.conf.d/50unattended-upgrades 中的 Unattended-Upgrade::Automatic-Reboot 設為 true，否則不會重新啟動機器。常見情況是延遲發生故障：kernel 在自動執行期間完成安裝，出現 /var/run/reboot-required，直到數週後下次重新開機時，問題才會浮現。請在主控台已開啟的情況下，刻意執行重新開機，並讀取 /var/log/apt/history.log，確認是哪一次執行安裝了目前正在啟動的 kernel。