EFI System Partition

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page EFI System Partition and the translation is 49% complete.
Outdated translations are marked like this.
Other languages:
Resources

Die EFI-Systempartition (ESP) ist eine FAT-formatierte Partition, auf der sich die primären EFI-Bootloader installierter Betriebssysteme befinden.

Kernel

Advanced partition selection (CONFIG_PARTITION_ADVANCED) und EFI GUID Partition support (CONFIG_EFI_PARTITION) müssen aktiviert sein:

KERNEL Aktivieren Sie die Unterstützung der GUID-Partitionstabelle (GPT) bei der Kernel-Konfiguration
-*- Enable the block layer --->
   Partition Types --->
      [*] Advanced partition selection
      [*] EFI GUID Partition support

Auch muss Zeichentabelle (engl. codepage) ISO8859-1 zur Verfügung stehen, damit das FAT-Dateisystem der EFI-Partition eingehängt werden kann:

KERNEL Aktivieren der Zeichentabelle ISO8859-1 und der Dateisystemerweiterung VFAT
-*- File Systems --->
   DOS/FAT/EXFAT/NT Filesystems  --->
      <*> VFAT (Windows-95) fs support
      (437) Default codepage for FAT
      (iso8859-1) Default iocharset for FAT
   Native Language support --->
      [*] NLS ISO 8859-1  (Latin 1; Western European Languages)

Merkmale

Für die Erstellung der Partition lesen Sie bitte das Handbuch.

parted (sys-block/parted) listet die EFI-Systempartition (ESP) mit den Flags boot, esp:

root #parted /dev/sda print
Model: ATA SAMSUNG SSD SM84 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 
 
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  99.6MB  98.6MB  fat32        EFI System Partition          boot, esp

gdisk (sys-apps/gptfdisk) listet die ESP mit ihrem Partitionstyp EF00:

root #gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
 
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
 
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1B59C2C8-8795-4625-9718-4D636B005AC1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          194559   94.0 MiB    EF00  EFI System Partition

Ihr Dateisystem kann mit dem Kommando mkfs.fat erstellt werden:

root #mkfs.fat -F 32 /dev/sda1

Partitionsgröße

Das Gentoo-Handbuch empfiehlt eine Größe von 1 GiB für die ESP, was für diverse Bootloader inklusive EFI-Stub-Kernel oder Windows ausreichend bemessen sein sollte.

Einhängepunkt

Es wird empfohlen die ESP nicht, wie es traditionell gemacht wurde, unter /boot/efi/ einzuhängen. Ein ineinander verschachtelter Aufbau verkompliziert bewährte Methoden der Implementierung mit automatischem Einhängen, weil das Einhängen als autofs eines darunterliegenden Verzeichnisses automatisch die darüberliegende Verzeichnis-Einbindung auslöst. Es ist die empfohlene Vorgehensweise diese Partitionen als autofs einzurichten (und dadurch, wann immer möglich, die Einbindung der Verzeichnisse im System zu unterlassen), nicht zuletzt aus Gründen der Datenintegrität und Datensicherheit bzw. deren Fehlen als zentrale Dateisystem-Charakteristika von FAT.

Wo Unterstützung für die Bootloader-Spezifikation verfügbar ist, nutzen Sie bitte /boot für die XBOOTLDR-Partition und /efi für die ESP. Wo das nicht möglich oder nicht der Fall ist, sollte eine monolithische ESP unter /boot verwendet werden; Einbindungen per autofs sollten jedenfalls genutzt werden.

Hinweis
systemd kann, wenn die Partitionen gemäß der Discoverable Partitions Specification erstellt wurden, automatisch die ESP des gestarteten Systems unter /boot oder /efi einbinden, wenn dort nicht bereits ein anderes Volume eingebunden ist [möglicherweise per /etc/fstab] oder wenn das Verzeichnis nicht leer ist. Wenn sowohl eine ESP als auch eine XBOOTLDR-Partition existieren, wird /efi als automatischer Einhängepunkt der ESP verwendet.

Für systemd (wenn nicht der GPT auto generator verwendet wird):

DATEI /etc/fstabKonfiguration des ESP-Einhängepunkts für systemd
UUID=56FE-81E0        /efi       vfat    defaults,noatime,uid=0,gid=0,umask=0077,x-systemd.automount,x-systemd.idle-timeout=600 0 2

Bei Nutzung von OpenRC können Sie ebenfalls AutoFS zum Einhängen bei Bedarf verwenden:

root #emerge --ask net-fs/autofs

Erstellen Sie einen direkten AutoFS-Einhängepunkt für die ESP.

DATEI /etc/autofs/auto.masterKonfiguration für autofs zum Lesen der 'boot'-Datei
/- /etc/autofs/auto.boot --timeout=600,sync,nodev

Konfigurieren Sie AutoFS so, dass es den Zugriff auf die Pfade /boot und /efi überwacht und gegebenenfalls mit Optionen (engl. mount options) des Geräts (engl. device, bspw. einer UUID) einhängt.

DATEI /etc/autofs/auto.bootAutoFS-Konfiguration für die ESP- und XBOOTLDR-Einhängepunkte
/boot    -fstype=vfat,uid=0,gid=0,umask=0077     UUID=AB12-CD34
/efi     -fstype=vfat,uid=0,gid=0,umask=0077     UUID=EF00-000A

AutoFS muss beim Systemstart geladen werden, um die konfigurierten Verzeichnisse als automatische Einhängepunkte überwachen zu können:

root #rc-update add autofs default

Um die automatische Einbindung der Verzeichnisse vor dem ersten Neustart zu erhalten, starten Sie AutoFS nach der Konfiguration manuell:

root #/etc/init.d/autofs start

Die so konfigurierten Partitionen müssen und sollen nicht in /etc/fstab eingetragen werden.

Standard-Layout

Das Layout der EFI-Systempartition (ESP) ist standardisiert. Hersteller und Distributoren sind aufgefordert, ihre Dateien in spezifischen Verzeichnissen abzulegen.

user $tree -L 3 /efi
 /efi
 └── EFI
     ├── BOOT
     │   └── BOOTX64.EFI
     ├── Gentoo
     │   ├── grubx64.efi
     │   ├── initramfs-x.y.z.img
     │   ├── kernel-x.y.z.efi
     │   ├── mmx64.efi
     │   └── shimx64.efi
     ├── Linux
     │   └── gentoo-x.y.z.efi
     ├── Microsoft
     │   ├── Boot
     │   └── Recovery
     ├── refind
     │   └── refind_x64.efi
     └── systemd
         └── systemd-bootx64.efi

Hier gezeigt ist der Microsoft-Verzeichnisbaum – und auch der allgemeine Boot-Verzeichnisbaum für Wechselmedien[1] – wie er zuvor bei der Installation von Windows 10 erstellt wurde. Der Wechselmedien-Pfad ist ein Rückfall-Bootloader-Verzeichnis (engl. Fallback): findet UEFI keine spezifischen Bootloader-Verzeichnisse, so startet es von hier. Auf einem Multi-Boot-System mit korrekt konfigurierten spezifischen Bootloadern ist gemäß Spezifikation der allgemeine Boot-Verzeichnisbaum nicht erforderlich.

UEFI-Boot-Elemente

Computer mit UEFI als Systemfirmware bringen üblicherweise ein Startmenü bzw. Boot-Menü (vormals auch engl. BIOS Boot Selection, kurz BBS) mit und ein Konfigurationsprogramm zum Erstellen, Sortieren und Löschen von Boot-Einträgen. Der Inhalt der ESP ist für dieses Konfigurationsprogramm sichtbar, und das Erstellen von EFI-Booteinträgen ist vergleichbar mit der Auswahl aus einer Liste vorhandener Startoptionen, dem Durchsuchen valider Bootloader auf der ESP und der anschließenden Auswahl eines solchen, beispielsweise bzImage-4.9.76-r1-gentoo.efi.

An installation tool will not only manage the bootloader and other required files on the ESP, it will also manage the addition of an "EFI boot entry". EFI boot entries, stored in NVRAM, are like the registration of the bootloader to the firmware. EFI will normally only list bootloaders with a boot entry in the boot menu, therefore it is not sufficient to only copy a bootloader or EFI executable to the ESP. Linux bootloaders will normally automatically add an EFI boot entry on installation of an (U)EFI bootloader, like e.g. GRUB with grub-install.

Oder efibootmgr kann zur Erstellung von UEFI-Einträgen für einen EFI-Bootloader verwendet werden.

In case a bootloader is deleted from the ESP, UEFI will normally delete the EFI boot entry as well on startup, and the bootloader will no longer be available from the boot menu, even when the file is afterwards restored, i.e. copied to the same path on the ESP.

One single exception, where no EFI boot entry is required, is the removable media boot path. On internal (fixed) media, such as the internal HDD or SDD, it is also used as the fallback boot path on most UEFI systems.

Removable media

EFI bootloaders on removable media are not configured as boot entries, so tools like efibootmgr are not required. Instead the computer firmware identifies removable boot options by looking for a predefined file name unique to the system architecture in use, in a predefined path.[2]

Most (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[3] Even though this is against specification, most systems use it as a fallback and it may even be the only usable bootloader on a system with a buggy (U)EFI. Only one such fallback bootloader is possible on a specific system (i.e. architecture), due to the standardized boot path and file names.

Architecture Abbreviation File name PE executable machine type
x86 32-bit IA-32 \efi\boot\bootia32.efi 0x14c
x86-64 (amd64) x64 \efi\boot\bootx64.efi 0x8664
Itanium IA-64 \efi\boot\bootia64.efi 0x200
ARM 32-bit AArch32 \efi\boot\bootarm.efi 0x01c2
ARM 64-bit AArch64 \efi\boot\bootaa64.efi 0xAA64
RISC-V 32-bit \efi\boot\bootriscv32.efi 0x5032
RISC-V 64-bit \efi\boot\bootriscv64.efi 0x5064
RISC-V 128-bit \efi\boot\bootriscv128.efi 0x5128
Loongson 32-bit LoongArch32 \efi\boot\bootloongarch32.efi 0x6232
Loongson 64-bit LoongArch64 \efi\boot\bootloongarch64.efi 0x6264
Hinweis
To boot from removable media, the firmware has to look for compatible bootloaders on supported devices, which can be configured in the firmware setup. Like most firmwares, (U)EFI provides a hotkey to show a boot selection (formally known as "BIOS Boot Specification" or BBS), otherwise (U)EFI will use the configured default boot entry. However, a buggy (U)EFI may default to the removable media boot path even on internal drives.

To use the removable media boot path it is sufficient to copy the EFI bootloader to the required path and file name. Should the firmware make use of this fallback, this may also remove the ability to select between configured boot entries, meaning that boot options (as listed with efibootmgr) through (U)EFI will not work. Even though every EFI bootloader can be used as fallback, it may be advisable to use a boot manager that itself has the ability to select between boot options, such as GRUB. From the above example for x64 (amd64):

root #cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
Hinweis
The FAT file system of the EFI System Partition (ESP) is not case-sensitive, but case-preserving (VFAT), while Unix is traditionally strictly case-sensitive. In the Linux kernel, vfat defaults to treating names case-insensitive (mount option check=r for relaxed),[4] so the above command on the ESP will always work. Only when VFAT has been mounted with strict case checking, check=s, the path /efi/EFI/boot/bootx64.efi may not work, as the existing files and directories could be using capital letters, e.g. /efi/EFI/BOOT or /efi/EFI/Boot (which would be different directories with strict case-sensitivity); the same goes for bootx64.efi. Running tree -L 3 /efi (when the ESP is mounted under /efi) will show the names in use on the individual system, to which the above command has to be changed accordingly.
Wichtig
The fallback bootloader is not automatically updated! Every time e.g. GRUB is re-installed (like after a version update, which may contain security fixes), it has to be copied to the fallback boot path again, overwriting (updating) the previous version!

The boot manager included in systemd, systemd-boot (formally Gummiboot), will automatically install to the removable media boot path. When sys-apps/systemd with the boot USE flag is updated, it is necessary to run bootctl again in order to update both bootloader files.

root #bootctl update

Siehe auch

Referenzen

  1. ↑ https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
  2. ↑ UEFI 2.10 Specification, 3.5.1.1 Removable Media Boot Behavior
  3. ↑ Debian Wiki – UEFI: Force grub-efi installation to the removable media path
  4. ↑ https://www.kernel.org/doc/html/v6.0/filesystems/vfat.html
Retrieved from "https://wiki.gentoo.org/index.php?title=EFI_System_Partition/de&oldid=1295178"