Warum ist die efi-Partition gemountet?

10

In Ubuntu und mehreren anderen Distributionen ist die EFI-Partition unter gemountet /boot/efi.

Soweit ich weiß, wird die EFI-Partition vor dem Betriebssystem rootfs ( /) gelesen . /Wofür benötigen wir nach dem Laden und Mounten des Kernels noch die EFI-Partition? Theoretisch benötigen Sie nach der Erstinstallation keinen Zugriff /boot/efimehr, da es nur die .efi-Binärdatei enthält ...

Warum ist es montiert? Es scheint, dass das automatische Bereitstellen einer Partition mit vertraulichen Dateien, auf die Sie nicht sehr oft zugreifen, aus gestalterischer Sicht keine sehr kluge Sache ist ...


BEARBEITEN:

Einige neuere Systeme können die grub.cfgauf ihrer Efi-Partition enthalten. Siehe diesen Fehlerbericht , obwohl dies bei meinem 16.04LTS nicht der Fall ist. Für Systeme mit der Konfigurationsdatei auf dem ESP ist es daher sinnvoller, sie zu mounten. Doch wie oft müssen Benutzer ausgeführt werden update-grub, und konnte das Skript es dann nicht bereitstellen und nach der Aktualisierung erneut bereitstellen?

Jiggunjer
quelle

Antworten:

9

Es gibt mehrere Gründe, warum auf das ESP unter verschiedenen Umständen zugegriffen werden muss:

  • /boot/efi/EFI/ubuntu/grubx64.efi - Dies ist die EFI GRUB 2-Binärdatei, die ersetzt werden muss, wenn das GRUB-Paket aktualisiert wird.
  • /boot/efi/EFI/ubuntu/grub.cfg- Dies ist eine GRUB-Konfigurationsdatei, die sehr wenig bewirkt. hauptsächlich lädt es /boot/grub/grub.cfg. Diese Umleitung wird durchgeführt, um einen "Hook" für Secure Boot-Systeme zu aktivieren. Ohne Secure Boot kann die grubx64.efiBinärdatei lokal erstellt werden und zeigt direkt auf /boot/grub/grub.cfg. Da der Speicherort von /boot/grub/grub.cfg(von ESP aus gesehen) von System zu System unterschiedlich grub.cfgist, muss für Secure Boot eine Datei auf dem ESP abgelegt werden, die nicht grubx64.efilokal erstellt werden kann. Meiner Meinung nach wäre es sinnvoller, die Haupt- grub.cfgund andere GRUB-Unterstützungsdateien auf dem ESP abzulegen, aber die dafür verantwortlichen Entwickler haben sich für einen konservativeren Ansatz entschieden, verglichen mit dem, was ein BIOS-basiertes System tut. In jedem Fall ist diegrub.cfgauf dem ESP wird selten, wenn überhaupt, aktualisiert; Dies kann jedoch irgendwann erforderlich sein, insbesondere wenn das GRUB Debian-Paket aktualisiert wird.
  • /boot/efi/EFI/ubuntu/shimx64.efi- Dies ist die Shim-Binärdatei, die erforderlich ist, damit Secure Boot funktioniert. Wie die GRUB 2-Binärdatei wird sie möglicherweise durch ein Debian-Paket-Update aktualisiert, jedoch durch das shim-signedPaket.
  • /boot/efi/EFI/ubuntu/MokManager.efi- Dies ist die MokManager-Binärdatei, die ein Shim-Support-Tool ist. Wie Shim wird es möglicherweise in einem Paketupdate aktualisiert.
  • /boot/efi/EFI/ubuntu/fwupx64.efi- Dies ist ein Tool zur Automatisierung des Firmware-Updates auf einem EFI-basierten Computer. Wie bei den vorhergehenden EFI-Binärdateien kann es durch ein Debian-Paket-Update aktualisiert werden.
  • EFI-Firmware-Dateien - Für die Aktualisierung der Firmware müssen wahrscheinlich Firmware-Dateien auf das ESP kopiert werden. Dies kann ein manueller Prozess sein oder etwas, das zumindest teilweise mithilfe der Linux- fwupdateBinärdatei und der passenden fwupx64.efiEFI-Binärdatei automatisiert wird . (Ich bin mir jedoch nicht zu 100% sicher, dass für letzteres das Schreiben von Dateien in das ESP erforderlich ist. Es ist ziemlich neu und verfügt derzeit nur über minimale Dokumentation.)
  • Andere EFI-bezogene Tools - Programme wie mein rEFInd-Boot-Manager und andere nicht standardmäßige EFI-Boot-Manager und -Tools müssen möglicherweise auf dem ESP installiert werden. Die schiere Anzahl der Tools, die möglicherweise installiert werden müssen, ist erheblich, aber die meisten von ihnen sind exotisch, sodass die Anzahl der betroffenen Systeme gering ist.
  • Manuelle Anpassungen der Konfigurationsdatei - Wenn Sie einen Bootloader neu konfigurieren möchten, müssen Sie möglicherweise seine Konfigurationsdatei auf dem ESP lesen, bearbeiten und die bearbeitete Datei wieder speichern. Was das betrifft, einfach die Prüfung erfordert die Konfiguration , dass das ESP montiert werden (obwohl es eine schreibgeschützte montieren sein könnte).
  • Systeminformationstools - Tools wie das Boot-Info-Skript lesen Konfigurationsdateien auf dem ESP, um einen Bericht über die Konfiguration des Systems zu erstellen. Das Boot-Info-Skript stellt das ESP wahrscheinlich bereit, auch wenn es für seine Arbeit nicht bereitgestellt ist, aber ich bin mir nicht 100% sicher. Möglicherweise gibt es andere Tools, die davon ausgehen, dass das ESP bereits bereitgestellt ist, und deren Funktionalität würde beeinträchtigt, wenn diese Annahme nicht erfüllt würde.

Insgesamt gibt es einige Gründe, aus denen das Betriebssystem selbst oder Sie möglicherweise vom ESP lesen oder schreiben möchten oder müssen. Diese Gründe sind jedoch so gering, dass ein Mechanismus zum vorübergehenden Bereitstellen des ESP und zum anschließenden Entfernen des ESP von Vorteil sein kann. Sicherlich könnte beispielsweise ein Debian-Paketinstallationsskript die Aufgabe übernehmen, ebenso wie automatisierte Tools, die Konfigurationsdateien auf dem ESP ändern. AFAIK, eine Änderung des Mount-Status des ESP ist jedoch nicht in Sicht.

Beachten Sie, dass das ESP standardmäßig mit recht restriktiven Berechtigungen bereitgestellt wird. Kürzlich (ab 15.10 oder 16.04 vielleicht - ich weiß nicht genau wann) wurden die Mount-Berechtigungen geändert, sodass nur von rootgelesen werden kann /boot/efi. Schon vorher konnte nur rootin das ESP geschrieben werden, obwohl die Leseberechtigungen geringer waren. Da rootPartitionen gemountet werden können, bietet es nur einen minimalen Sicherheitsvorteil, wenn das ESP zu diesem Zeitpunkt nicht gemountet wird. Dies hätte jedoch den Vorteil, dass das Risiko einer Beschädigung des ESP durch das Dateisystem aufgrund eines Fehlers, eines Stromausfalls usw. geringer ist.

Rod Smith
quelle
Ist es nur ein Zufall, dass mehrere Distributionen diese Montagerichtlinie haben? Oder könnte es mit POSIX oder einem anderen Standard zusammenhängen? Alle Debian + Derivate, Arch + Derivate, OpenSUSE. Vielleicht Fedora ...
Jiggunjer
Bei einer Standardinstallation am 17.04 habe ich keine Einschränkungen /boot/efi(in der obigen Antwort wird nur Root- rwfstabUUID=1234-5678 /boot/efi vfat defaults 0 1
Zugriff
2

Sie haben Recht: Es ist nicht erforderlich, das ESP /boot/efiim Standard-Setup zu mounten (auch bekannt als mit Grub 2 ).

update-grub- Updates grub.cfg, die darin liegen, /boot/grubdass die Konfiguration von grub problemlos aktualisiert wird, wenn das ESP nicht gemountet ist.

Ich hatte es für ein paar Jahre bei meiner vorherigen Installation ohne Probleme nicht montiert.

Sie können während des Startvorgangs einige Mikrosekunden gewinnen, indem Sie es nicht montieren, wenn Sie möchten ;-)

Sonnenwende
quelle
Es scheint mir dummes Design. Aus Versehen löschen = alle Bootloader verlieren. Das openSuse-Installationsprogramm warnt mich aktiv, wenn ich es nicht zu dem hinzufüge fstab, aber das Aushängen hat bisher noch keine Kernschmelze verursacht.
Jiggunjer
1
Sie können Systemdateien nicht versehentlich löschen. Es gibt viele andere Dateien, die Ihr System ruinieren können. Und das kann sowieso leicht wiederhergestellt werden.
Pilot6
1
@ Pilot6 1) können Sie. 2) irrelevant. 3) hängt davon ab, wie das System konfiguriert wurde.
Jiggunjer