共用方式為


Linux 虛擬機器開機後進入 GRUB 修復

適用於:✔️ Linux VM

注意事項

本文所參考的 CentOS 是一種 Linux 發行版,且將到達生命周期結束(EOL)。 請據以考慮您的使用和規劃。 如需詳細資訊,請參閱 CentOS 生命週期結束指引

本文討論造成 GRUB 救援問題的多個條件,並提供疑難解答指引。

在開機程式期間,開機載入器會嘗試找出Linux核心並移交開機控件。 如果無法執行此交接,虛擬機 (VM) 會進入 GRUB 救援控制台。 GRUB 救援控制台提示不會顯示在 Azure 序列控制台記錄中,但可以在 Azure 開機診斷螢幕快照顯示。

識別 GRUB 救援問題

在 Azure 入口網站 的 [VM 開機診斷] 頁面中檢視開機診斷螢幕快照。 此螢幕快照可協助診斷 GRUB 救援問題,並判斷開機錯誤是否造成問題。

下列文字是 GRUB 救援問題的範例:

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

針對 GRUB 救援問題離線進行疑難解答

  1. 若要針對 GRUB 救援問題進行疑難解答,需要救援/修復 VM。 使用 VM 修復命令 來建立修復 VM,該 VM 具有鏈接受影響 VM 的 OS 磁碟復本。 使用 chroot 掛接修復 VM 中的 OS 檔案系統複本。

    注意事項

    或者,您可以使用 Azure 入口網站手動建立救援 VM。 如需詳細資訊,請參閱使用 Azure 入口網站將 OS 磁碟連結至復原 VM,以針對 Linux VM 進行疑難排解

  2. 識別 GRUB 救援問題。 當您遇到下列其中一個 GRUB 救援問題時,請移至對應的區段加以解決:

  3. 解決 GRUB 救援問題之後,請執行下列動作:

    1. 從救援/修復 VM 卸除文件系統的複本。

    2. az vm repair restore執行 命令,將修復的OS磁碟與VM的原始OS磁碟交換。 如需詳細資訊,請參閱使用 Azure 虛擬機修復命令修復 Linux VM 中的步驟 5。

    3. 查看 Azure 序列主控台,或嘗試連線到 VM,檢查 VM 是否可以啟動。

  4. 如果遺失整個 /boot 分割區或其他重要內容且無法復原,建議您從備份還原 VM。 如需詳細資訊,請參閱如何在 Azure 入口網站 中還原 Azure VM 數據。

如需詳細的錯誤、可能的原因和解決方案,請參閱下列各節。

注意事項

在下列各節所述的命令中,將 取代 /dev/sdX 為對應的作系統 (OS) 磁碟裝置。

使用 Azure Linux 自動修復重新安裝 GRUB 並重新產生 GRUB 配置檔

Azure Linux 自動修復 (ALAR) 腳本是使用 Azure Linux 自動修復 (ALAR) 來修正 Linux VM 中所述 VM 修復延伸模組的一部分。 ALAR 涵蓋多個修復案例的自動化,包括 GRUB 救援問題。

ALAR 腳本會使用修復延伸模組 repair-button 來修正 GRUB 問題,方法是指定 --button-command grubfix 第 1 代 VM 或 --button-command efifix 第 2 代 VM。 此參數會觸發自動復原。 實作下列命令,藉由重新安裝 GRUB 並重新產生對應的組態檔,將常見的 GRUB 錯誤修正自動化:

  • 沒有 UEFI 的 Linux VM (BIOS 型 - Gen1):

    az extension add -n vm-repair
    az extension update -n vm-repair
    az vm repair repair-button --button-command 'grubfix' --verbose $RGNAME --name $VMNAME
    
  • 具有 UEFI 的 Linux VM (Gen2):

    az extension add -n vm-repair
    az extension update -n vm-repair
    az vm repair repair-button --button-command 'efifix' --verbose $RGNAME --name $VMNAME
    

重要

請據以取代資源組名 $RGNAME 和 VM 名稱 $VMNAME

修復 VM 腳本會搭配 ALAR 腳本,暫時建立資源群組、修復 VM,以及受影響 VM OS 磁碟的複本。 它會重新安裝 GRUB、重新產生對應的 GRUB 配置檔,然後將中斷的 VM OS 磁碟與複製的固定磁碟交換。 最後, repair-button 腳本會自動刪除包含暫時修復 VM 的資源群組。

重新安裝 GRUB 並手動重新產生 GRUB 配置檔

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。 掛接所有必要的文件系統,包括 //boot 和 在救援/修復 VM 中,然後進入 chroot 環境。

  2. 使用下列其中一個命令重新安裝 GRUB 並重新產生對應的 GRUB 組態檔:

    • 沒有 UEFI 的 RHEL/CentOS/Oracle 7.x/8.x/9.x Linux VM(BIOS 型 - Gen1)

      grub2-install /dev/sdX
      grub2-mkconfig -o /boot/grub2/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
      
    • RHEL/CentOS/Oracle 7.x/8.x/9.x Linux VM 與 UEFI (Gen2)

      yum reinstall grub2-efi-x64 shim-x64
      grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg
      

      如果 VM 執行 CentOS,請將 取代redhat為 grub.cfg 檔案絕對路徑 /boot/efi/EFI/centos/grub.cfg。centos

    • SLES 12/15 Gen1 和 Gen2

      grub2-install /dev/sdX
      grub2-mkconfig -o /boot/grub2/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
      
    • Ubuntu Gen1 和 Gen2

      grub-install /dev/sdX
      update-grub
      
  3. 請移至針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

錯誤:未知的文件系統

下列螢幕快照顯示錯誤訊息:

grub 未知文件系統錯誤的螢幕快照。

此錯誤可能與下列其中一個問題相關聯:

  • /boot 檔系統損毀。

    若要解決此問題,請遵循修正 /boot 文件系統損毀中的步驟。

  • GRUB 開機載入器指向無效的磁碟或磁碟分區。

    若要解決此問題, 請重新安裝 GRUB 並手動重新產生 GRUB 配置檔。

  • 人為錯誤所造成的 OS 磁碟分區數據表問題。

    若要解決這類問題,請遵循錯誤: 如果沒有這類分割 區,如果遺失或建立不正確,則重新建立 /boot 分割區。

修正 /boot 檔案系統損毀

若要修正 /boot 文件系統損毀,請遵循下列步驟:

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。

  2. 請參閱 針對 Azure Linux 中的文件系統損毀錯誤進行疑難解答,以解決對應 /boot 分割區中的損毀問題。

  3. 請移至針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

錯誤 15:找不到檔案

下列螢幕快照顯示錯誤訊息:

找不到 grub 錯誤 15 檔案的螢幕快照。

若要解決這個問題,請依照下列步驟執行:

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。 掛接所有必要的文件系統,包括 //boot 和 在救援/修復 VM 中,然後進入 chroot 環境。

  2. /boot檢查文件系統內容,並判斷遺漏的內容。

  3. 如果缺少 GRUB 組態檔, 請重新安裝 GRUB 並手動重新產生 GRUB 配置檔。

  4. 確認檔案系統中的 /boot 檔案許可權是否正常。 您可以使用執行相同 Linux 版本的另一個 VM 來比較許可權。

  5. 如果遺失整個 /boot 磁碟分區或其他重要內容且無法復原,建議您從備份還原 VM。 如需詳細資訊,請參閱如何在 Azure 入口網站 中還原 Azure VM 數據。

  6. 問題解決之後,請移至針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

錯誤:找不到檔案 '/boot/grub2/i386-pc/normal.mod'

下列螢幕快照顯示錯誤訊息:

找不到 grub 錯誤 normal.mod 的螢幕快照。

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1 以建立一個。 掛接所有必要的文件系統,包括 //boot 和 在救援/修復 VM 中,然後進入 chroot 環境。

  2. 如果您因為損毀錯誤而無法掛接 /boot 文件系統, 請修正 /boot 檔案系統損毀

  3. 當您位於 chroot 內時,請確認目錄中的內容 /boot/grub2/i386-pc 。 如果內容遺失,請從 /usr/lib/grub/i386-pc複製內容。 為此,請使用下列命令:

    ls -l /boot/grub2/i386-pc
    cp -rp /usr/lib/grub/i386-pc /boot/grub2
    
  4. 如果分割區的內容是空的 /boot ,請使用下列命令來重新建立它:

    注意事項

    下列步驟適用於不含 UEFI 的 RHEL/CentOS/Oracle 7.x/8.x Linux VM(BIOS 型 - Gen1)。

    1. 在 chroot 程式下,重新安裝 grub。 /dev/sd[X]以連結至修復/救援 VM 的 OS 磁碟對應複本取代 :

      grub2-install /dev/sd[X]
      
    2. 請確定 /etc/resolv.conf 有有效的 DNS 專案,才能解析存放庫的名稱:

      cat /etc/resolv.conf
      
    3. 重新安裝核心:

      yum reinstall $(rpm -qa | grep -i kernel)
      
    4. 建立 grub.cfg 檔案:

      grub2-mkconfig -o /boot/grub2/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
      
  5. 請繼續進行針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

錯誤:沒有這類分割區

下列螢幕快照顯示錯誤訊息:

沒有這類數據分割之 grub 錯誤的螢幕快照。

在下列其中一個案例中,RHEL 型 VM 上發生此錯誤:Red Hat、Oracle Linux、CentOS:

  • /boot分割區會誤刪除。
  • 分割 /boot 區是使用錯誤的開始和結束扇區重新建立。

解決方案:重新建立 /boot 磁碟分區

如果遺失分割區 /boot ,請遵循下列步驟重新建立分割區:

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。

  2. 使用下列命令,識別資料分割資料表是否建立為 dosGPT 類型:

    sudo fdisk -l /dev/sdX
    
    • Dos 資料分割數據表

      此螢幕快照顯示具有 dos 類型數據分割數據表的開機。

    • GPT 資料分割數據表

      顯示使用 GPT 類型數據分割數據表開機的螢幕快照。

  3. 如果分割區數據表做為分割區數據表類型,請在 dos 系統中重新建立 /boot 分割區。 如果分割區數據表具有 GPT 做為分割區數據表類型,請在 GPT 系統中重新建立 /boot 磁碟分區。

  4. 請確定已使用適當的磁碟安裝 GRUB 開機載入器。 您可以依照重新安裝 GRUB 中的步驟 ,手動 重新產生 GRUB 配置檔,以安裝並設定它。

  5. 請繼續進行針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

在 dos 系統中重新建立 /boot 磁碟分區

  1. 使用下列命令,從救援/修復 VM 重新建立 /boot 分割區:

    sudo fdisk /dev/sdX
    

    使用第一個和最後一個扇區中的預設值,以及分割區類型 (83)。 使用工具中的 fdisk 選項,確定分割/boot區數據表標示為可a開機,如下列輸出所示:

    sudo fdisk /dev/sdc
    
    The device presents a logical sector size that is smaller than
    the physical sector size. Aligning to a physical sector (or optimal
    I/O) size boundary is recommended, or performance may be impacted.
    Welcome to fdisk (util-linux 2.23.2).
    
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    Command (m for help): n
    Partition type:
       p   primary (1 primary, 0 extended, 3 free)
       e   extended
    Select (default p): p
    Partition number (1,3,4, default 1): 1
    First sector (2048-134217727, default 2048):
    Using default value 2048
    Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
    Using default value 2099199
    Partition 1 of type Linux and of size 1 GiB is set
    
    Command (m for help): t
    Partition number (1,2, default 2): 1
    Hex code (type L to list all codes): 83
    Changed type of partition 'Linux' to 'Linux'
    
    Command (m for help): a
    Partition number (1,2, default 2): 1
    
    Command (m for help): p
    
    Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: dos
    Disk identifier: 0x000b7179
    
    Device Boot      Start         End      Blocks   Id  System
    /dev/sdc1   *        2048     2099199     1048576   83  Linux
    /dev/sdc2         2099200   134217727    66059264   8e  Linux LVM
    
    Command (m for help): w
    The partition table has been altered!
    
    Calling ioctl() to re-read partition table.
    
  2. 重新建立遺失 /boot 的數據分割之後,請檢查 /boot 是否已偵測到文件系統。 您應該會看到 的專案 /dev/sdX1 (遺漏 /boot 磁碟分區)。

    sudo blkid /dev/sdX1
    
    sudo blkid /dev/sdc1
    /dev/sdc1: UUID="<UUID>" TYPE="ext4"
    
  3. /boot如果您在重新建立分割區之後看不到blkid文件系統,這表示/boot數據已不存在。 您必須重新建立/boot文件系統(使用相同的 UUID 和專案中的/boot/etc/fstab檔案系統格式),然後從備份還原其內容。

在 GPT 系統中重新建立 /boot 磁碟分區

  1. 使用下列命令,從救援/修復 VM 重新建立 /boot 分割區:

    sudo gdisk /dev/sdX
    

    使用第一個和最後一個扇區中的預設值,以及分割區類型 (8300),如下列輸出所示:

    sudo gdisk /dev/sdc
    GPT fdisk (gdisk) version 1.0.3
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    
    Command (? for help): n
    Partition number (1-128, default 1): 1
    First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
    Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
    Current type is 'Linux filesystem'
    Hex code or GUID (L to show codes, Enter = 8300):
    Changed type of partition to 'Linux filesystem'
    
    Command (? for help): p
    Disk /dev/sdc: 134217728 sectors, 64.0 GiB
    Model: Virtual Disk
    Sector size (logical/physical): 512/4096 bytes
    Disk identifier (GUID): 6D915856-445A-4513-97E4-C55F2E1AD6C0
    Partition table holds up to 128 entries
    Main partition table begins at sector 2 and ends at sector 33
    First usable sector is 34, last usable sector is 134217694
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 6076 sectors (3.0 MiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1         1026048         2050047   500.0 MiB   8300  Linux filesystem
       2         2050048       134215679   63.0 GiB    8E00
      14            2048           10239   4.0 MiB     EF02
      15           10240         1024000   495.0 MiB   EF00  EFI System Partition
    
    Command (? for help): w
    
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    
    Do you want to proceed? (Y/N): Y
    OK; writing new GUID partition table (GPT) to /dev/sdc.
    Warning: The kernel is still using the old partition table.
    The new table will be used at the next reboot or after you
    run partprobe(8) or kpartx(8)
    The operation has completed successfully.
    
  2. 使用下列命令檢查系統是否 /boot 偵測到檔案系統:

    sudo blkid /dev/sdX1
    

    您應該可以看到的項目 /dev/sdX1 (遺漏 /boot 的數據分割)。

    sudo blkid /dev/sdc1
    /dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"
    
  3. /boot如果您在重新建立分割區之後看不到文件系統,這表示/boot數據已不存在。 您必須重新建立 /boot 文件系統(使用專案中的相同 UUID /etc/fstab/boot ),然後 從備份還原其內容。

錯誤:找不到符號 'grub_efi_get_secure_boot'

下列螢幕快照顯示錯誤訊息:

找不到 grub 錯誤 'grub_efi_get_secure_boot' 的螢幕快照。

Linux 核心 4.12.14 版(用於 SLES 12 SP5 中)不支援 安全開機 選項。 因此,如果在部署 VM 期間啟用安全開機(也就是 [安全性類型 ] 字段設定為 [受信任的啟動虛擬機],當您嘗試在 Gen2 VM 映射上使用此 SUSE 核心版本開始時,虛擬機會透過控制台產生安全開機錯誤。

解決方案

若要解決開機錯誤,請遵循下列步驟:

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。 掛接所有必要的文件系統,包括 //boot,然後輸入 chroot 環境。

  2. 在 chroot 環境中執行下列 YaST 命令:

    yast2 bootloader
    
  3. 從 [ 啟用安全開機支援 ] 選項清除 “x”,然後選取 F10 以儲存變更。

    SUSE 控制台中 YaST2 開機載入器設定的螢幕快照。

  4. 請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

其他 GRUB 救援錯誤

下列螢幕快照顯示錯誤訊息:

另一個 grub 救援問題的螢幕快照。

在下列其中一個案例中,會觸發這類錯誤:

  • 缺少 GRUB 組態檔。
  • 使用錯誤的 GRUB 組態。
  • 分割 /boot 區或其內容遺失。

若要解決這個錯誤,請依照下列步驟執行:

  1. 檢查是否已建立救援/修復 VM。 如果未建立,請遵循針對 GRUB 救援問題進行離線疑難解答中的步驟 1,以建立 VM。 掛接所有必要的文件系統,包括 //boot,然後輸入 chroot 環境。

  2. 請確定已設定 /etc/default/grub 組態檔。 背書的 Azure Linux 映像已經有必要的設定。 如需詳細資訊,請參閱下列文章:

  3. 重新安裝 GRUB 並手動重新產生 GRUB 配置檔。

    注意事項

    如果遺漏的檔案是 /boot/grub/menu.lst,此錯誤適用於舊版 OS 版本(RHEL 6.x、Centos 6.x 和 Ubuntu 14.04)。 命令會有所不同,因為 GRUB 第 1 版會改用在這些系統中。 本文未涵蓋 GRUB 第 1 版。

  4. 如果遺失整個/boot分割區,請遵循錯誤:沒有這類分割區中的步驟。

  5. 問題解決之後,請移至針對 GRUB 救援問題進行離線疑難解答中的步驟 3,以交換 OS 磁碟。

下一步

如果特定開機錯誤不是 GRUB 救援問題,請參閱針對 Azure Linux 虛擬機器 開機錯誤進行疑難解答,以取得進一步的疑難解答選項。

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式,提供與這些產品的效能或可靠性有關的擔保。

協力廠商連絡資訊免責聲明

Microsoft 提供協力廠商的連絡資訊,以協助您尋找關於此主題的其他技術支援。 此連絡資訊如有變更,恕不另行通知。 Microsoft 不保證協力廠商聯絡資訊的準確性。

與我們連絡,以取得說明

如果您有問題或需要相關協助,請建立支援要求,或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。