Angenommen, ich habe ein Flash-Laufwerk und möchte, dass es bootfähig ist. Angenommen, ich habe auch eine einfache EFI-Datei, die etwas bewirkt. Wie groß darf die ESP also mindestens sein? Ich habe gelesen, dass sie 100 MB beträgt, aber das scheint speziell auf Windows zuzutreffen. Muss eine EFI-Partition eine bestimmte Größe haben, damit das System sie erkennt? Oder werden 100 nur empfohlen, weil moderne Betriebssysteme so viel verwenden?
Antwort1
Sind 100 nur deshalb empfehlenswert, weil moderne Betriebssysteme so viel verbrauchen?
Beachten Sie, dass die Partitionsgröße von 100 MB die Mindestgröße ist. Zwar gibt es keine UEFI-Spezifikation für eine Mindestgröße, aberMicrosoftempfiehlt diese Größe von 100 MB für seine Betriebssysteme.
Nehmen wir an, wir müssen die EFI-Partition mit dem FAT32-Dateisystem formatieren. Die Mindestpartitionsgröße des FAT32-Laufwerks wird wie folgt berechnet:sector_size x 65527.
Bei Advanced Format 4K Native-Laufwerken gibt es 4 KB pro Sektor. In diesem Fall wird die Mindestpartitionsgröße für FAT32-Laufwerke wie folgt berechnet:4 KB x 65527 = 256 MBAus diesem Grund beträgt die empfohlene Mindestgröße für 4K-Laufwerke 260 MB.
Bei Advanced Format 512e-Laufwerken beträgt die emulierte Sektorgröße jedoch 512 Byte. In diesem Fall wird die Mindestpartitionsgröße für FAT32-Laufwerke wie folgt berechnet:512 bytes x 65527 = 32 MB, was weniger als die Mindestgröße von 100 MB für diese Partition ist.
Muss eine EFI-Partition eine bestimmte Größe haben, damit das System sie erkennt?
Obwohl Microsoft für seine Betriebssysteme 100 MB empfiehlt, wird in den Linux-Foren für Linux-basierte Betriebssysteme oder für Dual-Boot- oder Multi-Boot-Situationen ein höherer Wert vorgeschlagen.
DerAutorvon gdisk schlägt 550 MiB vor.
Gemäß Arch LinuxForum, um mögliche Probleme mit einigen EFIs zu vermeiden, sollte die ESP-Größe mindestens 512 MiB betragen. 550 MiB werden empfohlen, um eine MiB/MB-Verwechslung und die versehentliche Erstellung von FAT16 zu vermeiden.
Die gängigsten Größenrichtlinien für die EFI-Systempartition liegen zwischen 100 MB und 550 MB. Einer der Gründe dafür ist, dass die Größe später nur schwer geändert werden kann, da es sich um die erste Partition auf dem Laufwerk handelt. Die EFI-Partition kann Sprachen, Schriftarten, BIOS-Firmware und andere Firmware-bezogene Dinge enthalten. Es gibt einige Firmware/Software, die in der EFI-Partition statt im Datenlaufwerk installiert werden. Und es gibt einige, die in Zukunft die Möglichkeit haben möchten, Dinge zu ESP hinzuzufügen.
Da es schwierig sein kann, die Größe zu vergrößern, falls es später benötigt wird, und die Festplattengröße heutzutage größer ist, wird für ESP eine große Größe wie 100 MB oder 550 MB empfohlen. Im Allgemeinen werden jedoch nur einige Kilobyte Speicherplatz benötigt.
Angenommen, ich habe ein Flash-Laufwerk und möchte, dass es bootfähig ist.
Obwohl es aus Ihrer Aussage nicht klar hervorgeht, ist es nicht notwendig, zusätzliche ESP auf dem USB-Stick zu erstellen, wenn Sie versuchen, Ihren USB-Stick als UEFI-kompatibles Laufwerk für die Windows-Installation bootfähig zu machen. Verwenden Sierufusoder ähnliche Tools, die es in ein UEFI-fähiges Laufwerk umwandeln. Aber ESP wird auf Ihrer Festplatte benötigt, wenn Sie Windows auf diesem Laufwerk installieren.
Antwort2
Die absolute Mindestgröße, die Sie erreichen können, ist die Verwendung eines FAT12-Dateisystems (also32 KB) und erfordert in der Praxis die Verwendung eines minimalen Bootmanagers, der Dateisystemtreiber zum Lesen Ihrer primären Partition – und des darin enthaltenen Kernels – enthält, was Grub oder rEFInd impliziert. Ein typisches Grub-Installationsimage ist etwa 200 KB groß, was immer noch nicht schlecht ist.
Ich boote schon seit einiger Zeit problemlos mit einem 2 MB großen FAT12-ESP, es ist also eindeutig möglich!
Ich bin mir nicht ganz sicher, woher der allgemeine Ratschlag kommt, 512 MB zu verwenden, aber dieArch Wikiwurde kürzlich von ... mir ... geändert, um auf die Möglichkeit von Fat12 hinzuweisen.
http://www.rodsbooks.com/linux-uefi/scheint darauf hinzudeuten, dass zumindest fat16 gut funktionieren sollte, außerVerwirrung beim Windows-Installationsprogramm, was meiner Meinung nach nicht wirklich relevant ist. Das Arch Wiki scheint auf diesem Ratschlag zu basieren, aber ich bin nicht mutig genug, es komplett neu zu schreiben.
Wie ich im Wiki erwähnt habe, die UEFI-SpezifikationMandate FAT12-Treiber. Ich habe Argumente gehört, dass „nur Wechseldatenträger vorgeschrieben sind“, was die Möglichkeit offen lässt, dass irgendjemand irgendwo eine UEFI-Implementierung geschrieben hat oder schreiben wird, die diese FAT12-Dateisystemtreiber enthält, aber ihre Verwendung zum Mounten der UEFI-Systempartition irgendwie verbietet, aber ich persönlich halte dies für unwahrscheinlich.
Antwort3
Führen Sie es unter Linux im Terminal aus, sudo fdisk -lum die Sektorgröße Ihres Speicherlaufwerks zu ermitteln.
Da die EFI-Partition als FAT32 formatiert ist, wird die Mindestpartitionsgröße des FAT32-Laufwerks wie folgt berechnet sector_size x 65527. Für moderne Speicher sind das 512 Byte x 65527 = 32 MiB. Die ausführbare Datei des EFI-Bootmanagers ist etwa 125 KiB groß, daher sind die 32 MiB mindestens mehr als nötig für die EFI-Partitionsgröße. Es gibt andere Argumente für größere Größen, aber wenn Sie nicht in diesen besonderen Situationen arbeiten, ist eine größere Größe nicht notwendig.
Antwort4
@Originalposter: Sie möchten die erforderliche Mindestgröße einer EFI-Partition wissen, haben aber nicht angegeben, welches Betriebssystem Sie im Sinn haben. Es gibt keine einheitliche Anforderung. Wenn man Informationen im Internet liest, sagen manche Leute „2 MB“ (siehe oben), während andere Terrabyte an Speicherplatz vorschlagen. Ich schlage vor, dass jeder die Mindestanforderung für sein eigenes System aufschreibt, dann hätten wir eine schöne Liste aller Betriebssystemanforderungen. Lassen Sie mich also Ihre Frage zum Debian-Betriebssystem beantworten:
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
und Windows 10:
ver
Microsoft Windows [Version 10.0.19042.804]
Als ich Debian installierte, wollte ich wissen, wie groß die EFI-Partition sein muss. So fand ich diese Seite, allerdings sind die hier bereitgestellten Informationen nicht hilfreich. Also dachte ich mir, 5 MB reichen? Es stellte sich heraus, dass das Debian-Installationsprogramm eine Mindestanforderung von 35 MB hat.
Beachten Sie: Wenn Sie die EFI-Partition zuerst mit fdisk partitionieren und dann versuchen, Debian zu installieren, wird die Installation mit einer kryptischen Fehlermeldung abgelehnt:
The attempt to mount a file system with type vfat in SCSII (0,0,0), partition #1 (sda) at /boot/efi failed.
Wenn Sie die von fdisk und dem Debian-Installer gesetzten Flags vergleichen (sofern Sie ihm die Partitionierung erlauben):
fdisk -> "B K"
Debian -> "B f"
Wählen Sie die EFI-Partition im Debian-Installationsprogramm erneut aus, um die Flags zu reparieren. Dummes Debian.
Außerdem kann man bei Verwendung von fdisk innerhalb von Hyper-V die verdammte Liste der Hex-Codes der Partitionen nicht anzeigen lassen, weil der erweiterte Modus (VmConnect) nicht funktioniert und SSH nicht installiert ist. Die von fdisk ausgegebene Liste der Hex-Codes fliegt also einfach vorbei und es gibt keine Möglichkeit, das VmConnect-Fenster nach oben zu scrollen. In VMWare Workstation funktioniert dies mit UMSCHALT+BILD-AUF, aber ich kann nicht herausfinden, wie das in Hyper-V geht. Tatsächlich hat niemand diese Frage gestellt! Also habe ich endlich herausgefunden, dass die EFI-Partition in fdisk „1“ ist.
Ist der vom Debian-Installer benötigte Speicherplatz WIRKLICH erforderlich? Nach der Installation von Debian habe ich den tatsächlich benötigten Speicherplatz überprüft:
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! Du hast die Frechheit, 550 MB, ein Gigabyte, 10 Terrabyte vorzuschlagen, noch mehr Angebote?! Manche Leute werden sagen, der Grub-Bootloader befindet sich auf der EFI-Partition, andere sagen, "update-initramfs" schreibt auf diese Partition, deshalb wird so viel Platz benötigt. Alles Blödsinn!
Aber leider ist der Schaden angerichtet, und jetzt muss ich mich darum kümmern.
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
Korrigieren Sie die PARTUUID:
partprobe /dev/sda
blkid
gdisk /dev/sda
x
c (1) -> set the old PARTUUID (a7196942-ec1b-e64a-9182-009a28d2cc44 in my example)
Korrigieren Sie die UUID in fstab:
nano /etc/fstab -> set the new UUID
Warum "mkfs.fat" (oben) und nicht "mkfs.fat -F32"? Aus diesem Grund:
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 lehnt auch die Formatierung als FAT32 ab:
format fs=fat32 quick
Volume too small
Also, 30 MB Speicherplatz gespart, aber noch nicht zugeordnet. Wie zuordnen? Wenn man fdisk ausführt, die ext4-Partition löscht und sie einschließlich des nicht zugeordneten Speicherplatzes (DN, alles Standard) neu erstellt, führt dies zu einem nicht bootfähigen System. Im Internet wird Ihnen gesagt, dass das Erweitern einer Partition um den nicht zugeordneten Speicherplatz VOR dieser Partition nicht möglich ist; der Rohspeicher muss an das Ende der Festplatte verschoben und dann erweitert werden. Wie verschiebt man den nicht zugeordneten Speicherplatz ans Ende? Keine Ahnung. Habe fdisk, gdisk, parted, MS diskpart ausprobiert. Kann es nicht herausfinden. Also habe ich schließlich „gparted-live-1.2.0-1-amd64.iso“ heruntergeladen. gParted konnte die ext4-Partition um den nicht zugeordneten Speicherplatz erweitern, ließ aber 1 MB Speicherplatz am Ende der Festplatte übrig. Im Internet wird Ihnen gesagt, dass dies gemäß den Spezifikationen geschieht. Wirklich? Interessant ist dann, dass fdisk dieses Megabyte NICHT am Ende stehen lässt, ebenso wenig wie Microsofts Diskpart beim Erweitern einer Partition. Jemand im Internet sagte: „Es ist nur 1 Megabyte und Sie möchten die Spezifikationen nicht verletzen, um es zu speichern.“ Ich werde dieses arme Megabyte retten, selbst wenn ich dafür alle Spezifikationen missachten muss! Keine Sorge, armes vernachlässigtes Megabyte, ich werde dich retten!
Also habe ich gParted ausgetrickst, hehe. Ich habe den nicht zugewiesenen Speicherplatz an das Ende der Festplatte verschoben, ohne ihn zuzuweisen. Dann habe ich gParted geschlossen und stattdessen fdisk verwendet, um die ext4-Partition zu erweitern, und es hat ihr DEN GESAMTEN Speicherplatz zugewiesen, einschließlich des armen Megabytes:
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
Über Windows. MS sagt also: 100 MB EFI + 16 MB MSR. Und natürlich verbreiten die berüchtigten Copypaster, die Informationen immer kopieren und einfügen, ohne sie zu überprüfen, diese Fehlinformationen im gesamten Internet. Aber ist dieser Speicherplatz wirklich notwendig? Schauen wir uns an, was sich in der EFI-Partition befindet:
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
Ich drucke die Liste nur für Sie aus. Ich weiß, was da ist, da ich die Dateien selbst dort abgelegt habe, als ich ein Windows-Image per Dism auf einem EFI-Rechner wiederhergestellt habe (das Image wurde per Dism auf einem MBR-Rechner erstellt). Es ist fast unmöglich herauszufinden, welche Dateien tatsächlich benötigt werden. Durch Ausprobieren habe ich herausgefunden, dass Sie nur die 3 (oben) benötigen.
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
Den BCD-Store musst du dir selbst anlegen, auf die Details werde ich hier nicht näher eingehen:
copy X:\bcd b:\efi\microsoft\boot
Also 1.636.008! Microsoft sagte 116 MB? Und diese Information wurde überall im Internet kopiert und eingefügt. Ich bin zuerst diesen Anweisungen gefolgt, der Idiot, der ich bin, aber jetzt wollte ich sehen, ob die von MS geforderten Größen WIRKLICH erforderlich sind (um Windows nicht mehr booten zu können):
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:\
Drückt die Daumen, ich starte neu! Houston, ich melde den erfolgreichen Start der Windows-Rakete! ... Houston, ich melde den erfolgreichen Windows-Start und die Kontoanmeldung! Houston, Microsoft ist ein Haufen verdammter Lügner!
Wir haben also 114 MB gespart, aber dieser Speicherplatz ist nicht zugewiesen.
Datenträgerpart?
Hahaha!
diskmgmt.msc
Hahaha, hahaha!
Und dann? Ich schätze, ich habe wieder gParted. Es ist nicht gerade eine gute Idee, mit einem Linux-Programm eine NTFS-Partition zu manipulieren, aber versuchen wir es. Also habe ich den nicht zugeordneten Speicherplatz ans Ende der Festplatte verschoben. Funktioniert. Habe Windows erneut von der DVD neugestartet (in meinem Fall eine virtuelle DVD mit einem gemounteten ISO, da ich dies in Hyper-V gemacht habe), dann:
diskpart
select disk 0
select partition 1
extend
Erledigt.
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
Aber was, wenn Sie die EFI- und MSR-Partitionen mit Linux-Tools löschen möchten? Ich weiß nicht, warum, aber dies führt dazu, dass das Windows-System nicht mehr booten kann. Ich habe genau dieselben Parameter an gdisk/fdisk/parted übergeben wie an diskpart, aber all diese Tools machen etwas kaputt! Löschen der MSR-Partition in diskpart:
select partition 1
delete partition override
Neustart, Windows bootet.
Dasselbe verdammte Ding in gdisk!:
gdisk /dev/sda
d (select msr partition)
w
Beim Neustart wird mir das verdammte Hyper-V-Logo angezeigt, das dort ewig steht, und das System bootet nicht. Grund?