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

VPS 在核心更新後無法開機時，應先做什麼

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

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

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

SSH 無法使用時，如何連線到主控台？

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

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

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

如何在 GRUB 選單中選用較舊的核心？

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

選單出現後，選擇「Advanced options for Ubuntu」。該子選單會列出所有已安裝的核心，最新版本排在最前面，每個核心都有一個 recovery mode 項目。選擇第二個一般項目，也就是最新核心下方的核心，然後按 Enter。Recovery mode 是另一種模式：它會開機進入最小化的 single user 系統，供修復使用，不是用來讓服務恢復上線。

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

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

dpkg 的輸出就是已安裝核心的清單。如果只有一行，表示完全沒有可回復使用的備用核心，這是首先要修正的問題。

GRUB 選單從未出現。現在該怎麼辦？

雲端映像檔通常會使用隱藏選單的設定。Ubuntu 映像檔通常會在 /etc/default/grub.d/ 下的檔案中將逾時設為 0，因此系統會立即啟動最新的核心，沒有可按的按鍵。

另一種情況則相反：選單顯示在畫面上並等待輸入，看起來像是系統卡住。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" 會將選單輸出到圖形主控台與序列埠，因此你可以在管理面板提供的任一檢視器中看到選單。console= 核心參數也會將後續的啟動訊息輸出到相同位置。每次啟動延遲 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 元件；修復方式是重建該 image，而不是處理核心。

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

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

升級期間未掛載 /boot/efi 是 UEFI 機器常見的原因。維護 EFI system partition 的套件會因此寫入一般的空目錄。firmware 會持續啟動舊的 boot entry，直到該 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

從救援模式修復，當所有核心都無法啟動時

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

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

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

GRUB 可以只啟動某個項目一次，之後恢復到您選定的預設項目。先將預設項目設為您信任的核心，再讓新核心僅啟動一次。如果啟動失敗，從面板執行硬重設即可返回正常核心，不必掌握主控台的操作時機。

在 /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 位於選單最上方，也就是最新的核心。這裡使用標題比使用編號更安全，因為每次安裝或移除核心時，編號都會變動。

無頭伺服器上執行 autoremove 為何有風險

APT 會維護一份不得自行移除的核心套件清單。請查看該清單：

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

每當核心套件變更時，系統就會重新產生這個檔案。它會保護目前執行中的核心與最近使用的核心。風險在於執行時機。重新開機並切換至新的核心後立即執行 sudo apt autoremove --purge，受保護清單已經更新，因此你原本仰賴的舊核心不再受到保護。對有鍵盤可操作的機器而言，這只是帶來不便。對無頭伺服器而言，這可能決定你是能選擇開機選單項目，還是必須從救援映像檔掛載磁碟。

至少保留兩個核心；/boot 空間充足時，保留三個。先檢查 uname -r，再依名稱移除舊核心，這樣就不會刪除目前正在執行的核心：

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

之後再次執行最後一個命令。數量從三個降至兩個，代表清理完成。數量降至一個，則表示下一次重新開機時可能會造成服務中斷。

升級前建立快照

在 apt upgrade 前建立的快照，是唯一不依賴任何啟動程序的復原方式。還原快照會將磁碟恢復到舊核心仍為預設核心的狀態，之後即可在已開啟主控台的情況下重新嘗試升級。執行中的機器所建立的快照具備當機一致性，也就是磁碟狀態如同突然斷電時所擷取的狀態。因此，若服務供應商支援離線快照，請先關閉伺服器再建立快照。快照也不等於備份，因為快照通常與所複製的磁碟位於相同的基礎架構。了解VPS 快照與實際備份的差異，才能判斷在問題不只涉及核心時，哪一種方式能協助你復原。

這在版本升級時尤其重要，因為核心、initramfs 工具、bootloader 與 GRUB 設定會在同一次執行中變更。請在開始Ubuntu 24.04 升級至 26.04前立即建立快照，不要在前一晚建立，這樣還原點才會對應到即將變更的機器狀態。如果伺服器尚未提供這項升級，原因是排程而非設定損壞，因為 LTS 到 LTS 的升級只有在第一個 point release，即 26.04.1發布後才會開放。

unattended-upgrades 如何處理核心套件

Ubuntu 的 unattended-upgrades 會在不提示的情況下安裝安全性更新，核心套件也和其他套件一樣，透過 security pocket 取得。這會產生兩個結果。

第一，新核心已安裝，但目前尚未執行。核心只有在開機時才會生效。系統會產生檔案 /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 月安裝核心，直到 6 月因完全無關的原因重新開機後才無法正常啟動。導致開機失敗的變更已經是 3 個月前的事，因此當天執行的操作看不出任何原因。你可以在 /var/log/apt/history.log 找到安裝目前導致開機失敗之核心的執行記錄。

請在你選定的日期主動重新開機，並事先開啟主控台工作階段。這個習慣能把難以追查的服務中斷，變成只需 2 分鐘完成的選單操作。如果你想保留自動化，又不想遭遇突如其來的重新開機，請保留自動安裝，停用自動重新開機，並參閱如何在 Ubuntu 上設定 unattended-upgrades以取得確切設定。使用 sudo apt-mark hold linux-image-generic 保留核心套件會完全停止這些套件的更新，也會同時停止核心安全性修正，因此應將其視為你決定接受的取捨，而不是安全措施。

FAQ

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

開啟供應商的 console（VNC 或 serial），並從控制面板觸發 hard reset，因為您無法登入以正常重新啟動。機器重新啟動時，反覆按下 Esc；若是傳統 BIOS boot，則按住 Shift，讓 GRUB menu 暫停顯示。選擇「Advanced options for Ubuntu」，再選取最新 kernel 下方的項目。看到 login prompt 後，執行 uname -r 確認目前使用的 kernel，並執行 dpkg -l 'linux-image-*' 查看已安裝的其他 kernel。系統恢復執行後，再開始診斷。

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

Cloud image 通常會在 /etc/default/grub.d/ 下的檔案中將 GRUB timeout 設為 0，因此不需按鍵就會啟動最新的 kernel。在 /etc/default/grub 中設定 GRUB_TIMEOUT=10 和 GRUB_TIMEOUT_STYLE=menu，加入 GRUB_TERMINAL="console serial"，讓 menu 也能透過 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，且 menu 中沒有 fallback entry。

unattended-upgrades 會導致 boot 失敗嗎？

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