假設我有一個閃存驅動器，並且我希望它可啟動。假設我還有一個基本的 EFI 文件，它可以完成某些任務。那麼，ESP 的最小尺寸是多少呢？我讀到它是 100MB，但這似乎是專門針對 Windows 的。 EFI 分割區必須達到一定大小才能被系統辨識嗎？還是只是因為現代作業系統使用了這麼多而建議使用 100？
答案1
之所以推薦 100，是因為現代作業系統使用了這麼多嗎？
請注意，100 MB 的分割區大小是最小的。雖然 UEFI 沒有設定最小尺寸的規範，但是微軟建議其作業系統使用 100 MB 的大小。
假設我們需要使用 FAT32 檔案系統對 EFI 分割區進行格式化。 FAT32 磁碟機的最小分割區大小計算如下sector_size x 65527。
在進階格式 4K 本機磁碟機中，每個磁區有 4 KB。在這種情況下，FAT32 磁碟機的最小分割區大小計算如下4 KB x 65527 = 256 MB。這就是為什麼 4K 驅動器的建議最小大小為 260 MB。
但在進階格式 512e 磁碟機中，類比磁區大小為 512 位元組。在這種情況下，FAT32 磁碟機的最小分割區大小計算如下512 bytes x 65527 = 32 MB，小於該分割區的 100 MB 最小大小。
EFI 分割區必須達到一定大小才能被系統辨識嗎？
儘管 Microsoft 建議其作業系統使用 100 MB，但 Linux 論壇建議基於 Linux 的作業系統或任何雙啟動或多啟動情況使用更多記憶體。
這作者gdisk 建議為 550 MiB。
根據 Arch Linux論壇，為了避免某些 EFI 出現潛在問題，ESP 大小應至少為 512 MiB。建議使用 550 MiB，以避免 MiB/MB 混淆和意外創建 FAT16。
因此，EFI 系統分割區最常見的大小準則是 100 MB 到 550 MB 之間。背後的原因之一是以後很難調整大小，因為它是磁碟機上的第一個分割區。 EFI 分割區可能包含語言、字體、BIOS 韌體以及其他與韌體相關的內容。有些韌體/軟體安裝在 EFI 分割區而不是資料磁碟機中。有些人希望將來能夠將一些東西添加到 ESP 中。
由於日後需要式可能很難擴大大小，而且現在的硬碟大小較大，因此建議 ESP 使用較大的大小，例如 100 MB 或 550 MB。但在一般情況下，它只會使用一些千字節的空間。
假設我有一個閃存驅動器，並且我希望它可啟動。
儘管從您的聲明中尚不清楚，但如果您嘗試使您的筆式驅動器可作為 UEFI 相容驅動器啟動以進行 Windows 安裝，則無需在筆式驅動器中建立額外的 ESP。使用魯弗斯或類似的工具，負責將其轉換為支援 UEFI 的驅動器。但是，在將 Windows 安裝到該磁碟機時，您的硬碟中需要 ESP。
答案2
您可以逃脫的絕對最小大小涉及使用 fat12 檔案系統（因此32KB），並且在實踐中需要使用一些最小的引導管理器，其中包含用於讀取主分區的檔案系統驅動程式以及其中包含的內核，這意味著 grub 或 rEFInd。典型的 grub 安裝映像約為 200KB，這仍然不錯。
我已經用 2MB fat12 ESP 正常啟動有一段時間了，所以顯然這是可以完成的！
我不太確定使用 512MB 的常見建議來自哪裡，但是拱門維基最近由...我...修改以引用 fat12 的可能性。
http://www.rodsbooks.com/linux-uefi/似乎表明至少 fat16 應該可以正常工作，除了混淆 Windows 安裝程式，恕我直言，這其實不相關。 Arch Wiki 似乎就是基於這個建議，但我沒有足夠的勇氣完全重寫它。
正如我在 Wiki 中提到的，UEFI 規範強制要求 fat12 驅動程式。我聽說過「只強制要求可移動磁碟機」的論點，這使得某人在某個地方擁有或將編寫包含那些fat12 檔案系統驅動程式的UEFI 實現，但以某種方式禁止它們用於安裝UEFI 系統分區，但我個人認為這種可能性不大。
答案3
對於 Linux，在終端機中運行sudo fdisk -l以找出儲存磁碟機的磁區大小。
由於 EFI 分割區格式化為 FAT32，因此 FAT32 磁碟機的最小分割區大小計算為sector_size x 65527。對於現代存儲，512 位元組 x 65527 = 32 MiB。 EFI 啟動管理器可執行檔大約為 125 KiB，因此 32 MiB 的最小值對於 EFI 分割區大小來說已經超出了所需。對於更大的尺寸還有其他爭論，但除非您在這些特定情況下運行，否則不需要更大的尺寸。
答案4
@原海報：您想知道 EFI 分割區所需的最小大小，但您未能說明您想要的作業系統。沒有單一的要求。在網路上閱讀資訊時，有些人說「2 mb」（上圖），而有些人則建議是 TB 空間。我建議每個人都寫下自己系統的最低要求，然後我們就會有一個包含所有作業系統要求的漂亮清單。那麼讓我回答您有關 Debian 作業系統的問題：
uname -r
5.10.0-6-amd64
uname -a
Linux localhost 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux
和 Windows 10：
ver
Microsoft Windows [Version 10.0.19042.804]
現在，在安裝 Debian 時，我想知道 EFI 分割區所需的大小。這就是我找到此頁面的方式，但此處提供的資訊沒有幫助。所以我想，5mb 夠嗎？結果 Debian 安裝程式的最低要求為 35mb。
請注意，如果您先使用 fdisk 對 EFI 分割區進行分割區，然後嘗試安裝 Debian，它將拒絕並顯示一則神秘的錯誤訊息：
The attempt to mount a file system with type vfat in SCSII (0,0,0), partition #1 (sda) at /boot/efi failed.
如果您比較 fdisk 和 Debian 安裝程式設定的標誌（如果您允許它分割區）：
fdisk -> "B K"
Debian -> "B f"
重新選擇 Debian 安裝程式中的 EFI 分割區以修復標誌。愚蠢的德班。
另外，在 Hyper-V 中使用 fdisk 時，您無法顯示該死的分割區十六進位代碼列表，因為增強模式（VmConnect）不起作用，未安裝 SSH，因此 fdisk 輸出的十六進位代碼列表只是飛翔，且無法向上捲動VmConnect 視窗。在 VMWare Workstation 中，可以透過 SHIFT+PageUp 來實現此操作，但我不知道如何在 Hyper-V 中執行此操作，事實上，甚至沒有人提出這個問題！所以我終於發現，EFI分割區在fdisk中是「1」。
無論如何，Debian 安裝程式真的需要這麼多空間嗎？安裝Debian後，我檢查了實際需要的空間：
mount /dev/sda1 /mnt
cd /mnt
du -hs
/efi/debian
-rwx------ 1 root root 1K 27. Apr 00:11 BOOTX64.CSV
-rwx------ 1 root root 1180K 27. Apr 00:11 fbx64.efi
-rwx------ 1 root root 1K 27. Apr 00:11 grub.cfg
-rwx------ 1 root root 1634K 27. Apr 00:11 grubx64.efi
-rwx------ 1 root root 1233K 27. Apr 00:11 mmx64.efi
-rwx------ 1 root root 1292K 27. Apr 00:11 shimx64.efi
5,3M
5.3M！你還好意思建議550mb、1GB、10TB，還有更多的出價嗎？有些人會說，grub 引導程式位於 EFI 分割區上，其他人說「update-initramfs」將寫入此分割區，這就是為什麼需要這麼多空間。廢話，全都是！
但是，唉，傷害已經造成，現在我必須處理它。
mount /dev/sda1 /mnt
cp -r /mnt/EFI /work
umount /dev/sda1
blkid
/dev/sda1: UUID="6995-68F6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a7196942-ec1b-e64a-9182-009a28d2cc44"
gdisk /dev/sda
d 1
n 1
+5466KB
EF00
w
umount /dev/sda1
mkfs.fat /dev/sda1
mount /dev/sda1 /mnt
mv /work/EFI /mnt
umount /dev/sda1
修復 PARTUUID：
partprobe /dev/sda
blkid
gdisk /dev/sda
x
c (1) -> set the old PARTUUID (a7196942-ec1b-e64a-9182-009a28d2cc44 in my example)
修復 fstab 中的 UUID：
nano /etc/fstab -> set the new UUID
為什麼是“mkfs.fat”（上圖），而不是“mkfs.fat -F32”？這就是為什麼：
https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c
According to Microsoft FAT specification (fatgen103.doc) disk with 65525 clusters (or more) is FAT32
define MIN_CLUST_32 65525
diskpart 也會拒絕格式化為 fat32：
format fs=fat32 quick
Volume too small
因此，節省了 30mb 的空間，但尚未分配。怎麼分配？執行 fdisk、刪除 ext4 分割區並重新建立它（包括未分配的空間（dn，一切預設））會導致系統無法啟動。在網路上，他們會告訴您，在該分區之前通過未分配的空間擴展分區是不可能的，需要將原始空間移動到硬碟的末尾，然後進行擴展。如何將未分配的空間移動到末端？不知道。嘗試過 fdisk、gdisk、parted、MS diskpart。查不出來。所以我最終下載了「gparted-live-1.2.0-1-amd64.iso」。 gParted 能夠透過未分配的空間擴展 ext4 分區，只不過它在硬碟末端留下了 1mb 的空間。在網路上，他們會告訴你，這是按照規範完成的。真的嗎？有趣的是，fdisk 不會在末尾留下這個兆字節，微軟的 diskpart 在擴展分區時也不會。網路上有人說：“只有1兆字節，你不想違反規範來保存它。”即使我必須踐踏現有的所有規格，我也會節省這可憐的兆位元組！別擔心，可憐的被忽視的兆字節，我會救你的！
所以我就騙了gParted，呵呵。我將未分配的空間移至磁碟末尾，但沒有分配它。然後我關閉 gParted 並使用 fdisk 來擴展 ext4 分區，它為它分配了所有空間，包括可憐的兆位元組：
fdisk /dev/sda
F
Start End Sectors Size
14336 73727 59392 29M
d 2
n 2 14336
fdisk -l
Device Start End Sectors Size Type
/dev/sda1 2048 12979 10932 5,3M EFI System
/dev/sda2 14336 20971486 20957151 10G Linux filesystem
關於Windows。所以 MS 說，100 MB efi + 16 mb msr。當然，臭名昭著的複製貼上者總是在不檢查的情況下複製貼上訊息，並將這些錯誤訊息傳播到整個網路上。但這麼大的空間真的有必要嗎？我們來看看EFI分割區裡都有什麼：
Verzeichnis von B:\efi\boot
1.558.344 bootx64.efi
Verzeichnis von B:\efi\microsoft\boot
28.672 bcd
Verzeichnis von B:\efi\microsoft\boot\fonts
48.992 wgl4_boot.ttf
Anzahl der angezeigten Dateien:
3 Datei(en), 1.636.008 Bytes
我專門為您列印了列表，我知道那裡有什麼，因為當我將 Windows 映像恢復到 EFI 電腦時（該映像是由 MBR 計算機上的 dism 創建的），我自己將文件放在那裡。幾乎不可能找出實際需要哪些文件。透過反覆試驗，我發現，你只需要 3 個（上面）
diskpart
select disk 0
select partition 1
assign letter b
mkdir b:\efi
mkdir b:\efi\boot
mkdir b:\efi\microsoft
mkdir b:\efi\microsoft\boot
mkdir b:\efi\microsoft\boot\fonts
copy c:\windows\boot\efi\bootmgfw.efi b:\efi\boot\bootx64.efi
copy c:\windows\boot\fonts\wgl4_boot.ttf b:\efi\microsoft\boot\fonts
bcd商店你得自己創建，這裡就不贅述了，然後：
copy X:\bcd b:\efi\microsoft\boot
所以 1.636.008！微軟說，116mb？這些資訊被複製並貼上到網路上。我首先按照這些說明進行操作，我真是個白痴，但現在我想看看 MS 所需的大小是否確實需要（例如使 Windows 無法啟動）：
dism /Capture-Image /ImageFile:c:\copy\efi.wim /CaptureDir:b:\ /Name:efi /Compress:fast
diskpart
select disk 0
select partition 0
delete partition override
efi killed
select partition 1
delete partition override
msr killed
create partition efi size=2
format fs=fat quick
assign letter b
dism /Apply-Image /ImageFile:c:\copy\efi.wim /Index:1 /ApplyDir:b:\
交叉手指，我要重啟！休斯頓，報告 Windows 火箭成功起飛！ ...休斯頓，報告 Windows 啟動和帳戶登錄成功！休士頓、微軟都是一群該死的騙子！
所以我們省了 114 mb，但這個空間是未分配的。
磁碟部分？
哈哈哈！
磁碟管理器
哈哈哈哈哈哈！
然後呢？我想，又分手了。使用 Linux 程式來破壞 NTFS 分割區並不是一個好主意，但讓我們試試看。所以我把未分配的空間移到了硬碟的末端。作品。再次從 DVD 重新啟動 Windows（在我的情況下是安裝了 ISO 的虛擬 DVD，因為我正在 Hyper-V 中執行此操作），然後：
diskpart
select disk 0
select partition 1
extend
完畢。
list partition
Partition ### Typ Größe Offset
------------- ---------------- ------- -------
Partition 1 System 2048 KB 1024 KB
Partition 2 Primär 39 GB 3072 KB
select partition 1
detail partition
Volume ### Bst Bezeichnung DS Typ Größe Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 1 FAT Partition 2048 KB Fehlerfre System
但是如果你想透過linux工具刪除EFI和MSR分割區怎麼辦？我不知道為什麼，但這樣做會導致 Windows 系統無法啟動。我向 gdisk/fdisk/parted 傳遞了與向 diskpart 傳遞完全相同的參數，但所有這些工具都破壞了一些東西！刪除diskpart中的MSR分割區：
select partition 1
delete partition override
重新啟動，Windows 啟動。
gdisk 中同樣該死的東西！
gdisk /dev/sda
d (select msr partition)
w
重新啟動後，我的臉上出現了該死的 Hyper-V 徽標，永遠坐在那裡，系統無法啟動。原因？