Boot

MBR 轉換為基於 GPT 的系統,如何引導 Linux 和 Windows

  • September 5, 2021

如何將基於 GPT 的系統引導至 Linux 和 Windows?這不是從基於 GPT 的新系統開始的問題,而是從轉換為基於 GPT 的系統的 MBR 開始的問題。

我的華碩筆記型電腦初始設置,

  • 我禁用了安全啟動控制,並且
  • 我啟用[Launch CSM](兼容性支持模組)
  • 我使用 MBR 對我的 HD 進行了分區
  • 我在華碩筆記型電腦上的所有系統都是從這種 BIOS/MBR/CSM 模式啟動的,包括 Win8 和我所有的 Linux

但是,我發現我的 USB 僅以 EFI 樣式啟動,並且當我的 USB 以 EFI 樣式啟動時,Windows 10拒絕安裝到我的 BIOS/MBR/CSM 模式系統。

所以我將我的 MBR 磁碟轉換為 GPT,當然,正如 Krunal 警告的那樣,這種做法破壞了我的系統啟動,我需要讓所有東西再次啟動。

好的,現在是我的問題。

  • 在 BIOS/MBR/CSM 模式下,我有一個活動的 MBR 分區,我的所有系統都從它啟動(使用extlinux),包括 Win8 和我所有的 Linux。

  • 然而,在 GPT 模式下,這就是我的問題所在。

所以我基本上不知道該走哪條路,也不想進一步弄亂我已經混亂且無法啟動的系統。

我目前的分區模式(我認為它不相關,但因為有人要求它):

Disk /dev/sda: 698.65 GiB, 750156374016 bytes, 1465149168 sectors
Disk model: HGST HTS541075A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: AA9AB709-8A5D-468D-990E-155BA6A2FBB3

Device         Start        End   Sectors   Size Type
/dev/sda1       2048  129026047 129024000  61.5G Microsoft basic data
/dev/sda2  129026048  169986047  40960000  19.5G EFI System
/dev/sda3  169988096  186372095  16384000   7.8G Linux filesystem
/dev/sda4  186374144  200710143  14336000   6.9G Linux filesystem
/dev/sda5  200712192  215046143  14333952   6.9G Linux filesystem
/dev/sda6  215048192  231432191  16384000   7.8G Linux filesystem
/dev/sda7  231434240  247818239  16384000   7.8G Linux filesystem
/dev/sda8  247820288  264204287  16384000   7.8G Linux filesystem
/dev/sda9  264206336  276494335  12288000   5.9G Linux filesystem
/dev/sda10 276496384  288784383  12288000   5.9G Linux filesystem
/dev/sda11 288786432  329746431  40960000  19.5G Linux filesystem
/dev/sda12 329748480  452628479 122880000  58.6G Microsoft basic data
/dev/sda13 452630528  493590527  40960000  19.5G Linux swap
/dev/sda14 493592576  903192575 409600000 195.3G Linux filesystem
/dev/sda15 903194624 1465147391 561952768   268G Linux filesystem

非常感謝有關如何從此類環境啟動 Linux(和 Windows)的清晰說明。謝謝。

更新/結論:

/dev/sda2之前是我的活動 MBR 分區,如上所述,我將其類型從 更改Linux filesystemEFI System. 但它是ext4格式的,因此不能用作 EFI 系統。

因此,我需要解決的上述問題是:

  • revertsda2的類型回到Linux filesystem,
  • sda13從我的19.5G Linux 交換中分離出一個 FAT32 分區作為 ESP 分區,
  • 將韌體從 CSM 更改為原生 EFI 模式
  • 然後遵循@telcoM 的以下建議

據我所知,一旦轉換完成,Windows 不會將這種轉換後的系統磁碟作為特殊情況處理,因此它應該與“新”基於 GPT 系統中的磁碟完全相同。

特別是,Windows 強加了 GPT 分區系統磁碟必須始終以 UEFI 本機樣式引導 Windows 的限制:即不允許在 GPT 分區磁碟上使用 BIOS 樣式的引導過程。

首先,介紹 MBR 和 GPT 分區之間的差異:

  • 在 GPT 中,沒有像 MBR 分區那樣對主/擴展/邏輯分區進行劃分。所有 GPT 分區都只是分區。
  • 雖然 GPT 分區表中有一個“legacy BIOS bootable”分區屬性位,但在 UEFI 風格引導時根本不使用它
  • MBR 分區磁碟通常在塊#0(實際的主引導記錄)和第一個分區的開頭之間有一個未使用的磁碟塊間隙。在現代系統上,第一個分區通常與磁碟開頭正好對齊 1 MiB,因此如果使用常見的 512 字節塊,則第一個分區將從塊 #2048 開始。MBR 和第一個分區之間的間隙被 GRUB 等引導載入程序使用。在 GPT 分區的磁碟上,該區域被實際的 GPT 分區表佔用,無法使用。
  • 在 MBR 分區磁碟上,分區類型由單個字節標識。在 GPT 分區磁碟上,每個分區的類型由 UUID 標識。
  • MBR 分區磁碟具有 32 位磁碟簽名;GPT 分區磁碟具有 128 位 UUID 用於相同目的。每個 GPT 分區在分區表中也有一個唯一的 UUID:它可以用來唯一標識一個分區,即使其中使用的文件系統是未知的。Linux 將其顯示為PARTUUID; 對於 MBR 分區磁碟,使用 MBR 磁碟簽名和分區號的組合來代替實際分區 UUID。
  • MBR分區表存在於#0塊中;如果使用擴展分區,則每個邏輯分區的開頭都有一個附加分區表。GPT分區表從block#1開始,佔用多個block;在磁碟的最後還有一個備份 GPT 分區表。如果您習慣於通過僅在磁碟開頭將多個塊歸零來擦除磁碟上的分區,這通常會引起意外。

由於分區類型的 UUID 不方便人類使用,因此不同的分區程序使用了各種方法來縮短它們。gdisk將使用四位類型程式碼;Gparted 通過各種標誌表示不同的分區類型 UUID(在我看來,這是一個不幸的選擇)。

原生 UEFI 風格的引導過程也與經典的 BIOS 風格的引導過程有很大不同:

  • BIOS 風格的引導過程首先(通常)將 BIOS 設備 ID 0x80(=第一個 BIOS 硬碟)分配給 BIOS 設置目前選擇為引導驅動器的設備。當以 UEFI 風格引導時,韌體設置(UEFI 系統中的“BIOS 設置”)定義了引導路徑:它可以採用多種形式,但對於已安裝的作業系統,最常見的一種是指定分區 UUID引導文件路徑名
  • 當以 BIOS 風格啟動時,韌體會在所選啟動磁碟的第 0 塊末尾檢查 2 字節的啟動簽名,然後只執行適合 MBR 塊的大約 440 字節機器程式碼,以及實際的分區表。當引導 UEFI 風格時,韌體具有理解某些類型文件系統的內置功能:UEFI 規範規定兼容的 UEFI 韌體必須理解 FAT32,但它也可能理解其他文件系統類型。UEFI“可啟動磁碟”必須包含具有特殊類型 UUID 的分區:這稱為 EFI 系統分區,或簡稱 ESP。韌體將查找唯一 UUID 與引導路徑指定的 UUID 匹配的 ESP 分區,然後嘗試從該分區載入指定的引導文件。
  • 從可移動媒體或以前未配置為韌體設置的磁碟引導 UEFI 樣式時,韌體會查找包含韌體可以讀取的文件系統和具有特定路徑名的文件的 ESP 分區。對於 64 位 x86 硬體,此UEFI 回退/可移動媒體引導路徑將以\EFI\boot\bootx64.efiWindows 樣式或<ESP mount point>/EFI/boot/bootx64.efiLinux 樣式表示。

ESP 分區有一個標準結構:每個安裝的作業系統都必須設置一個子目錄,\EFI\<vendor or distribution name>\並且只將它們的引導載入程序文件放在其中。該\EFI\boot\子目錄為備份/可移動媒體引導載入程序保留,它們遵循Highlander規則:只能有一個(對於每個系統架構)。


通過在非 ESP 分區上設置 GParted “引導標誌”,您有效地將該分區的 UUID 類型更改為 ESP 類型 UUID。這是一個錯誤:現在磁碟有兩個類型為 ESP 的分區。您應該將已更改的分區類型更改回原來的類型。在 GParted 中,這意味著刪除“boot”和“esp”標誌;在 中gdisk,這可能意味著將類型程式碼設置為8300(“Linux filesystem”) 或8304(“Linux x86-64 root”)。

由於您在同一個磁碟上也有 Windows,因此不建議嘗試使用 BIOS-Boot 分區(gdisk類型程式碼ef02):這通常會強制您在每次想要在作業系統之間切換時進入韌體設置並啟用/禁用 CSM . 相反,您可能希望使用實時 Linux 引導媒體將您的磁碟安裝掛載到 eg /mnt,然後 chroot 到它以用本i386-pc機 UEFI 替換目前的 BIOS 樣式引導載入程序(通常是架構類型的 GRUB)(例如具有x86_64-efi架構類型的 GRUB )。基本上(以下所有命令為root):

mount <your root filesystem device> /mnt
mount -o rbind /dev /mnt/dev
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
chroot /mnt /bin/bash

現在你的會話將使用你安裝的 Linux 作業系統的環境,你應該能夠像往常一樣使用包管理器和任何其他工具(警告:如果你有標準系統的一部分,比如/var單獨的分區,現在掛載它們也!)

第一步應該是為 ESP 添加一個掛載點並掛載它。首先執行lsblk -o +UUID找到你的 ESP 分區的 UUID;因為它的文件系統類型很可能是 FAT32,所以它應該是xxxx-yyyy. 用實際的 UUID替換<ESP UUID>以下命令:

mount UUID=<ESP UUID> /boot/efi
echo "UUID=<ESP UUID> /boot/efi vfat umask=0077,shortname=winnt,flush 0 2" >>/etc/fstab 

下一步是切換引導載入程序類型。

不幸的是,您沒有提及您使用的是哪個 Linux 發行版。如果它是 Debian,或 Ubuntu,或從它們派生的某些發行版,則只需使用標準包管理工具刪除grub-pcgrub-pc-bin包並安裝grub-efi-amd64grub-efi-amd64-bin代替它們,然後執行grub-install /dev/sda(或包含您的 ESP 分區的任何磁碟),最後執行update-grub以重建 GRUB 配置。

此時,您可以退出 chroot,撤消安裝,看看您的系統現在是否可以啟動。

(if you had to mount any extra partitions, unmount them now)
exit
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt
reboot

您可能還想安裝該efibootmgr實用程序,因為它允許您在 Linux 執行時查看、備份和修改韌體啟動設置。(Windows 可以用它的bcdedit命令做同樣的事情,但在我看來,這個命令比 . 使用起來更尷尬efibootmgr。)

引用自:https://unix.stackexchange.com/questions/667610