GCP 常見問題與教學―掛載硬碟錯誤導致 VM 開機失敗

「GCP 掛載硬碟錯誤，導致 VM 開機失敗怎麼辦？」許多企業剛把 VM 搬遷上雲時，面對開機失敗問題都會因為無法走到機房拯救主機而異常慌張。所以這次我們將模擬掛載硬碟錯誤的情境並示範2種救援教學，希望未來大家遇到類似狀況都能冷靜地成功救援主機！

GCP VM 開機失敗問題：掛載硬碟錯誤

我們剛開始使用雲端主機時，常會把 VM（虛擬機器）當成自家機房的主機在處理。但其實這兩者有一個非常大的差異，就是「你沒辦法走到機器前面排除問題」！如果是自家機房的主機，不論發生任何狀況我們都可以走進機房，使用救援模式或插入光碟（Live DVD）來拯救自家的主機。

但在雲端環境我們就沒辦法這麼做了，Google 的機房不像自家機房可以讓我們來去自如啊！而根據 Cloud Ace 自身後台數據統計，雲端 VM 最常被詢問的問題就是：「使用 Linux 主機，掛載硬碟（Disk）失敗導致無法開機成功！」所以今天我們就來示範一下這個問題該如何解決吧！

GCP VM 掛載硬碟錯誤狀況模擬

首先我們在 Google Cloud Platform（GCP）專案建一台作業系統為 Debian 的主機，並加掛一顆 50 GB 的 Disk，其他選項保持預設。建立之後我們直接 SSH 連線進去，輸入 lsblk 並查看目前 Disk 掛載的狀況。

現在我們知道有 sdb 這顆 50 GB 的 Disk，但到這邊還不能用！必須先輸入下方的指令進行格式化，完成後我們就能看到這顆 Disk 已成功格式化。上面這段過程，想更仔細了解的人可參考 GCP 官網上的《格式化並掛載非開機磁碟的操作步驟》喔！

sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb

接下來在我們要掛載 Disk 之前，還要先建立一個目錄當作掛載點（步驟1）。完成後再輸入指令進行正式掛載（步驟2），掛載成功後，還要記得更改目錄權限讓大家都能寫資料進去！（步驟3）

步驟1：sudo mkdir -p /mnt/disks/disk-data

步驟2：sudo mount -o discard,defaults /dev/sdb /mnt/disks/disk-data

步驟3：sudo chmod a+w /mnt/disks/disk-data

上述3個步驟完成後，我們可以看到更改權限前後的狀況如下圖。但這目前只是暫時掛載成功，重開機後又恢復到尚未掛載的狀態。如果想要開機自動掛載，必須要做接下來的設定，就是更改 /etc/fstab 這個檔案！

這邊提醒大家千萬要注意一點，就是這個檔案只要有任何錯誤就會造成開機失敗，而且是無法進入命令列的那種！所以一定要記得先把檔案備份起來，萬一改錯就用下方的檔案覆蓋回去。

sudo cp /etc/fstab /etc/fstab.backup

然後在更改 fstab 之前，必須要先取得 Disk 的 UUID，所以要輸入下方步驟1的指令。而在得到 UUID 後，我們先把它複製起來並準備正式來修改 fstab，這邊請各位輸入步驟2的指令。在完成上2個步驟後，我們可看到檔案樣子呈現如下圖：

步驟1：sudo blkid /dev/sdb

步驟2：sudo vim /etc/fstab

接著這邊我們要再加入新的一行（詳見範例）。相關參數的細節這邊不多做解釋，但各位記得多檢查一下標準格式喔！另外補充一點，我們可以使用 mount -a 來根據 fstab 一次掛載所有 disk ，這樣萬一 fstab 有寫錯，就能及時看到錯誤並修正！

範例：UUID=0f652379-a4d2-4d2a-a047-7bcd2ea73457 /mnt/disks/disk-data ext4 discard,defaults 0 2

如果掛載沒錯誤當然就不會看到任何訊息，但我們也可以寫個檔案進目錄，確認這個 Disk 是可以用的。檔案範例如下，大家可以寫進自己的目錄試試看，而如果沒問題就可以放心地儲存離開。

cd /mnt/disks/disk-data/
echo "hellow_world" > hello.txt
cat hello.txt

一切確認無誤後，接下來就要進行第一次緊張的重開機！首先我們點擊 VM 右邊三小點裡面的 Reset。重開後再 SSH 進去，成功進入命令列然後再輸入 lsblk 確認 Disk 自動掛載成功。

那接著重頭戲來了，我們要故意弄壞它！首先把好的 fstab 檔案備份一次（步驟1），然後進去修改裡面的內容，例如把 UUID 和掛載點都改掉（步驟2）。這邊我故意把新 Disk 的 UUID 加上「-2」，掛載點也加上「-2」（詳見下圖）。

步驟1：sudo cp /etc/fstab /etc/fstab.backup

步驟2：sudo vim fstab

上面修改的內容儲存好後，接著我們故意去卸載它（步驟3），然後再故意掛載錯的路徑（步驟4）。上面兩個步驟完成後，我們就能看到掛載點不存在的錯誤訊息。

步驟3：sudo umount /mnt/disks/disk-data

步驟4：sudo mount -o discard,defaults /dev/sdb /mnt/disks/disk-data-2

所以接下來我們可以重開機並見證鋪陳已久的開機失敗時刻，深吸一口氣重開機後果不其然收到開機失敗的訊息。那接下來就讓我們一起來看看面對這樣的狀況，可以利用哪兩種方法救援吧！

GCP 硬碟掛載錯誤救援教學一：使用 Serial Port 連到主機

開頭我們說過雲端主機和地端主機最大的差異是我們「沒辦法走到機器前面排除問題」，但其實我們進入主機後會看到的「CONNECT TO SERIAL CONSOLE」，就是模擬我們真的走到主機面前的樣子。

補充一下，「Connecting to serial ports is enabled in project-wide metadata」這行字代表我們可以在 metadata 設定啟用這個功能。所以未來專案裡任何一台機器開不了，都可以用 Serial Console 進去救援。而回到救援主機這項任務，點擊按鈕後它一樣會開啟一個視窗，並告訴你按 Enter 可以進去。

但按了 Enter 後，它告訴我們 root account is locked，表示 root 沒有設密碼不能登入。其實這是常態，因為 root 權限非常大，預設都不給開，除非使用者平常有意識到這點然後已經設好了密碼，這樣才能正常進入 serial console。

但其實我們通常還是建議不要啟用 root ，因為如果你的主機 IP 是直接曝露在網路上的，那真的無時無刻都有駭客在嘗試登入你的主機，說實話非常危險！所以這邊要再介紹主機救援的第二種方法給大家。

GCP 硬碟掛載錯誤救援教學二：主機 Boot Disk 重掛載+修改 fstab

這邊要介紹的第二個救援方法雖然有點麻煩，但幾乎都能成功。所以還是建議大家遇到這類型的開機失敗狀況可優先嘗試這個方法，下面就讓我們一起來看看要如何操作吧！首先我們把無法開機的主機關機，接著在找到 Boot Disk 後，點擊它進入 Disk 的頁面。

進入 Boot Disk 頁面後我們接著點擊「Create Snapshot」，然後在幫 Snapshot 完成命名後按下「CREATE」來進行快照備份。

再來我們要另外建一台新的主機 instance-2。這邊的重點是要把剛剛那個 snapshot-1 掛成另一顆 Disk，然後去修復它的 fstab。加好舊機器的 Disk 後，我們接著要連進去 instance-2 。提醒一下掛載前一樣先用 lsblk 查看它的 ID 是多少！

這邊請大家特別注意，真正有資料的分割是9.9GB 的 sdb1 喔，小心不要掛載錯了！那現在一樣先建立掛載點並把 Boot Disk 掛起來。掛載成功後，我們進去該目錄確認一下，從 /mnt/disks/boot-disk 開始，就是原本開不起來那台機器的根目錄。

sudo mkdir -p /mnt/disks/boot-disk
sudo mount -o discard,defaults /dev/sdb1 /mnt/disks/boot-disk

而我們從這裡去找 etc/fstab，應該就會看到下圖黃框裡那個寫錯的 fstab 檔案，那既然成功找到了，下一個步驟當然就是更改它啦！方法很簡單就是直接把寫錯的那一行刪掉。

sudo vim fstab 

fstab 修改提醒
其實這次我們應該只要把 UUID 和掛載點的「-2」刪掉，讓最前面的 disk-data 可以再掛載回來就好了。但除非我們有信心 fstab 能改一次就正確，不然還是建議先不要掛載額外的 disk-data，等到 Boot Disk 開機成功後再重新掛 disk-data 也不遲喔！
（下圖截自：Google Cloud Shell 頁面 ©2022 Google）

fstab 改好之後，我們再來去修改 instance-2 這台機器，這邊首先把 boot-disk-2 卸載掉，接著再建立一台新機器，其中引用的 Boot disk 就是我們剛改過 fstab 的那一顆。然後在 Boot disk 裡選擇 CHANGE，用 boot-disk-2 當做 boot disk 來開機。

接著我們來確認主機相關資訊，沒問題的話按下建立。接著再點擊 instance-3 的 SSH 按鈕，看看剛剛救的主機能不能成功連進去。這邊讓我們一起深吸一口氣，緩和一下緊張的情緒來看結果吧！

成功了！恭喜各位我們的 Boot Disk 救援成功！那接著我們再去看看 fstab 檔案，確認一下是修改回來的樣子，如此一來就可以再重新掛回原本那顆 disk-data 啦。另外這裡提供一下 Google Cloud 官方文件《Recovering an inaccessible VM or a full boot disk》，當中有完整的教學。

各位若看到這裡，應該就知道未來如果碰到類似狀況，只要把相關 Disk 做 Snapshot ，然後想辦法在其他主機開起來即可。而同樣概念套用到任何 Disk 相關的異動，包含加新 Disk、Disk加大、掛載或卸載 Disk 等一律適用。又或者只要主機有重大的安裝或設定，都先做 Snapshot！這樣不論發生任何事情，我們手邊都有一個備份，要做什麼緊急處置都很方便。而 Snapshot 的教學可參考《如何輕鬆備份 GCP 上 VM 的資料？快照 Snapshot 自動備份設定教學》這篇文章喔！

如開頭所述，雲端主機無法讓我們來去自如，所以一遇到主機需要救援的狀況多數人都會很緊張！因此在這邊特別分享 Disk 掛載錯誤導致開機失敗的2種救援方法給大家。各位對以上內容如有任何問題歡迎留言詢問，有 GCP 相關需求或技術問題也都歡迎聯絡我們，喜歡這種常見問題解答系列的話也可以留言讓我們知道喔！

▋延伸閱讀：

・【GCP教學】第一次開 Google VM 就上手 – Compute Engine 操作簡介
・【GCP教學】第一次開Google VM要注意什麼？Compute Engine開機詳細介紹
・使用 Google VM 的5大常見錯誤 – 有一種叫忘記關機！
・【GCP教學】如何輕鬆備份 GCP 上 VM 的資料？快照 Snapshot 自動備份設定教學