AWS企業開戶代辦 解決 EC2 Linux 實例啟動卡在 GRUB 界面或 Kernal Panic 的救急指南

先判斷是 GRUB 卡住，還是核心已經炸掉

EC2 Linux 實例開不了機，最怕的不是畫面難看，而是你一時分不清楚問題卡在哪一段。是還停在 GRUB，還是已經進到 Linux 核心，卻在載入過程中直接 panic？這兩種狀況，處理方法完全不同。前者多半是開機載入器、分割區、UUID 或 /boot 設定出問題；後者則常見於核心、initramfs、檔案系統或 fstab 配置錯誤。

GRUB 卡住的常見畫面

如果你看到的是 GRUB 選單出不來、卡在 grub rescue>、黑畫面閃游標，或是選完系統後直接回到 GRUB，那通常還沒真正進入作業系統。這類問題多半和啟動磁碟找不到、/boot 損壞、grub.cfg 設定錯誤、UUID 改變，或 BIOS 與 UEFI 模式不一致有關。

AWS企業開戶代辦 Kernel Panic 的常見畫面

如果畫面已經出現 Linux 核心訊息，接著看到 VFS: Unable to mount root fs、Kernel panic - not syncing，或 Attempted to kill init 之類的字樣，表示核心已經起來了，只是無法把根檔案系統掛上來，或者 init 程序根本沒辦法正常啟動。這時候就不要再執著於重開，方向應該是檢查磁碟、掛載點、initramfs 與核心版本。

救援前先做的三件事

先拍快照，不要先亂修

救援的第一步不是動手改設定，而是先保住退路。把根磁碟做快照，必要時連資料碟一起備份。很多人一急就直接編輯配置檔，結果把原本還有機會救回來的系統，改成更難收拾。快照不是浪費時間，而是你在出手前最便宜的保險。

先確認磁碟型態與分割區

EC2 上常見的陷阱之一，是你以為系統磁碟叫 /dev/xvda，實際上在 Nitro 架構下看到的是 /dev/nvme0n1、/dev/nvme1n1 這類名稱。名稱不同不代表磁碟不同，真正要看的是分割區、檔案系統與 UUID。先用 lsblk -f、blkid 把布局看清楚，別急著掛載。

能進 Serial Console 就先看一次

如果你的帳號與實例已啟用 EC2 Serial Console，先透過序列主控台看開機訊息，能省掉很多猜測。它不一定能直接修好問題，但通常能幫你確認到底是 GRUB 當掉，還是核心啟動後出現 panic。知道卡點在哪裡，後面每一步都會更準。

最穩的做法：掛到救援實例修

1. 停機並分離根磁碟

如果問題不是單純的輸入錯誤或暫時性故障，最穩妥的方法就是把根 EBS 卷拆下來，掛到另一台正常的救援實例上處理。流程很簡單：先停止故障實例，再分離 root volume，接著在同一可用區域開一台健康的救援主機，把故障卷掛成次要磁碟。這樣做的好處是，你能用正常系統環境進入磁碟內容，不必在壞掉的開機流程裡硬撐。

2. 找出真正的 root 分割區

磁碟掛上去之後，先不要急著 mount。先看清楚哪個分割區是 root，哪個是 /boot，哪個是 /boot/efi。這一步很重要，因為如果你把錯誤分割區掛進 /mnt，後面所有修改都會寫錯地方。

lsblk -f
blkid

看完之後，再把正確分割區掛載到 /mnt。如果有獨立的 /boot 或 /boot/efi，也要一併掛上，否則你修了 grub.cfg，實際上可能只是在改一個沒有被開機流程讀到的版本。

mount /dev/nvme1n1p1 /mnt
mount /dev/nvme1n1p2 /mnt/boot
mount /dev/nvme1n1p3 /mnt/boot/efi

上面的裝置名稱只是示意，實際請以 lsblk 輸出為準。

先修 GRUB，再談開機

檢查 grub.cfg 與 UUID

AWS企業開戶代辦 GRUB 問題裡，UUID 不一致是老毛病。只要你曾經重建檔案系統、替換 EBS、調整分割區，或從快照還原過磁碟，UUID 就可能跟原本不同。這時候 /etc/fstab 與 grub.cfg 如果還是舊值，開機時就會找不到正確的根分割區。

vi /mnt/etc/fstab
blkid

做法很直接：把實際查到的 UUID 跟設定檔逐一比對。若是 UUID 已經變了，就把設定修正成新的值。若有掛載點在啟動時不是必要條件，先暫時註解掉，讓系統至少能順利進入完整環境。

重新生成 GRUB 設定

當系統能進入 chroot 後，先補齊必要的掛載點，再重建 GRUB 設定。RHEL、CentOS、Amazon Linux 類系統，通常用 grub2-mkconfig；Ubuntu、Debian 類系統，常見的是 update-grub。別把兩邊的做法混在一起，否則你會得到一份看似存在、實際卻不會被讀取的設定檔。

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

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

如果是 Debian 或 Ubuntu 系統，則改用：

update-grub

GRUB 本體也壞了就重裝

如果你連 GRUB 選單都出不來，或者停在 grub rescue>，那就不是單純設定錯誤而已，通常要直接重裝 boot loader。這裡要注意 BIOS 與 UEFI 的差別：有些系統只要執行 grub2-install /dev/nvme1n1 就能修好；有些則必須先確認 /boot/efi 已正確掛載，再用對應參數重建啟動項目。原則很簡單，先確認目前是什麼開機模式，再選對指令，不要拿 UEFI 的方法修 BIOS，也不要反過來亂試。

Kernel Panic 多半不是「重開就好」

先看是哪一種 panic

Kernel panic 不是單一故障，而是一組結果。你要先看訊息內容，再判斷真正的病灶。如果是 VFS: Unable to mount root fs，通常表示核心找不到根檔案系統，常見原因有磁碟驅動沒載入、initramfs 缺模組、root= 參數錯誤，或檔案系統本身壞掉。如果是 Kernel panic - not syncing: Attempted to kill init，則可能是 init 程序有問題，或開機過程中的掛載與服務啟動失敗得太早，導致系統無法繼續。

重建 initramfs

很多人忽略 initramfs，結果一直在核心版本上打轉。事實上，若你最近更新過 kernel，或是更換了 NVMe、LVM、RAID、加密磁碟相關設定，initramfs 可能根本沒把必要模組帶進去。這時候最有效的動作，往往就是重建 initramfs，讓核心在開機初期就能載入對應驅動。

dracut -f

如果是 Debian、Ubuntu 系統，則用：

update-initramfs -u -k all

不要小看這一步。很多看起來像是大災難的 panic，實際上只是模組沒被打包進去，重新生成一次就恢復正常。

檢查 fstab 和掛載點

開機時卡住，不一定是核心壞了，也可能是系統在掛載某個不存在的磁碟時，一路等到超時。最常見的罪魁禍首就是 /etc/fstab。例如你曾經拔掉資料碟、改過卷 ID，或搬過快照，fstab 卻還在要求系統掛載舊的 UUID，結果開機流程就被拖死。處理方式很簡單：先把不必要的掛載項目註解掉，讓主機先起來。對非關鍵磁碟，加上 nofail 也是常見做法，至少不會因為一顆資料碟不見，整台主機跟著陪葬。

vi /mnt/etc/fstab

回滾核心版本，往往比硬修更快

新核心剛更新就壞，先回舊版

如果故障點發生在最近一次 kernel 更新之後，最實際的策略不是硬撐新版本，而是先回到能正常開機的舊版核心。對線上系統來說，能先恢復服務比什麼都重要。只要主機先活過來，之後還有時間慢慢查是哪個模組、哪個安全更新，或哪個相依套件造成問題。

在 chroot 裡檢查已安裝的核心版本，必要時把預設啟動項改回舊核心。很多管理者在這一步猶豫太久，反而讓恢復時間拉長。記住一件事：救援時先求可用，再求完美。

特別注意 AWS 上的驅動相容性

EC2 的環境跟本機測試不完全一樣。你在本地看起來正常的核心，到了雲端可能因為缺少 NVMe、XFS、LVM 或磁碟加密相關模組而開不了機。若你的實例類型、磁碟控制器或檔案系統有變更，務必確認對應驅動已包含在核心與 initramfs 內。很多問題不是 Linux 本身壞掉，而是移到 AWS 後，環境條件變了。

把磁碟放回去之前，做最後檢查

檢查設定檔有沒有明顯錯誤

AWS企業開戶代辦 在把卷掛回原本實例前，請至少確認這幾件事：/etc/fstab 的 UUID 是真的存在、/boot 與 /boot/efi 若有獨立分割都已正確掛載、GRUB 設定檔已重新產生、initramfs 也已更新。這些檢查看起來瑣碎，但它們往往就是能不能開機的分水嶺。

關閉 chroot，卸載並脫離

exit
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt/boot/efi
umount /mnt/boot
umount /mnt

卸載乾淨後，再把 volume 從救援實例分離，重新掛回原本的 EC2 實例，最後開機測試。若成功進系統，建議先觀察一次日誌，再評估是否要清理多餘的核心版本與過時設定。不要一修好就立刻關掉觀察，很多問題會在第一次完整開機後才露出尾巴。

如果真的還是起不來，照這個順序排

1. 確認 root volume 是否掛錯。
2. 確認 fstab 的 UUID 與檔案系統一致。
3. 確認 /boot 是否獨立分割且已正確掛載。
4. 重新產生 grub.cfg。
5. 重新建 initramfs。
6. 回退到舊核心。
7. 檢查檔案系統是否損毀，必要時離線修復。

AWS企業開戶代辦 這個順序的好處，是從最常見、最容易修的地方先下手，不會一開始就把問題想得太大。很多 EC2 Linux 實例看起來像整台壞掉，實際上只是 UUID 改了、核心版本沒對上，或某個掛載點在開機時拖垮了整條流程。只要你把判斷順序理清楚，救援速度會快很多。

平時先把這些準備好，故障時會差很多

把快照與版本管理當成日常

真正成熟的做法，不是等出事才救，而是把風險預先攤平。每次升級 kernel、修改 fstab、調整 RAID、LVM 或加密設定前，先做快照。這不是官腔，而是所有救援流程裡最便宜、也最有效的保護手段。你今天多花幾分鐘，往往能替明天省下幾小時。

保留一台能登入的救援實例

如果你的環境很重要，建議固定準備一台同區域的救援實例，平常不用，出事時直接拿來掛卷排障。把常用工具先裝好，例如 lsblk、blkid、dracut、grub、xfsprogs、e2fsprogs，你會發現現場處理速度差很多。救援不是靠運氣，而是靠準備。

EC2 上的開機問題，表面看是 GRUB 或 Kernel Panic，底層其實就三件事：開機載入器找不找得到核心、核心載入後找不找得到根檔案系統、系統初始化時有沒有被錯誤設定絆住。只要抓住這條線，處理起來就不會亂。先保資料，再修啟動鏈，最後才是優化與清理，這才是救急的正確順序。