UEFI/Bootloader - Versionsgeschichte

Gehrke: /* GRUB2 */ interne Verlinkung korrigiert (Secure Boot)

2015-09-02T09:19:48Z

‎GRUB2: interne Verlinkung korrigiert (Secure Boot)

Gehrke: /* GRUB2 */ formelle Kleinigkeiten, interne Verlinkung

2015-09-01T06:02:56Z

‎GRUB2: formelle Kleinigkeiten, interne Verlinkung

Robi: Freigabe

2015-08-31T23:18:00Z

Freigabe

Robi: /* SHIM */

2015-08-31T23:16:04Z

‎SHIM

Robi: /* rEFInd */

2015-08-31T23:12:50Z

‎rEFInd

Robi: /* ELILO */

2015-08-31T23:10:54Z

‎ELILO

Robi am 31. August 2015 um 23:08 Uhr

2015-08-31T23:08:47Z

Robi: gummiboot -> systemd.boot

2015-08-31T22:35:21Z

gummiboot -> systemd.boot

Robi am 31. August 2015 um 18:47 Uhr

2015-08-31T18:47:52Z

Änderungen zeigen

Robi: Syslinux und kleine Änderungen

2015-08-30T23:27:39Z

Syslinux und kleine Änderungen

Änderungen zeigen

@@ Zeile 80: / Zeile 80: @@
 [[Datei:Grub2-0.png|200px|thumb|left|Grub2 bei UEFI oft Standard]]
-[[GRUB2]] ist schon seit einigen Jahren im Umfeld des Bootens vom BIOS bekannt. Für die Funktionalität auch im UEFI Umfeld zu arbeiten werden GRUB2-Binaries auf der [[ESP]] hinterlegt, mit denen der Bootvorgang dann analog angestoßen wird. Es sind 2 Binaries zu unterscheiden '''grub.efi''' und '''grubx64.efi'''. Der Unterschied liegt hier in der Anzahl und Auswahl der Module die mit in das binary gepackt sind. Ohne [[SecureBoot]] könnte von beiden gestartet werden, bei SecureBoot wird '''grub.efi''' benötigt und auch automatisch von Shim aufgerufen.<br>
+[[GRUB2]] ist schon seit einigen Jahren im Umfeld des Bootens vom BIOS bekannt. Für die Funktionalität auch im UEFI Umfeld zu arbeiten werden GRUB2-Binaries auf der [[ESP]] hinterlegt, mit denen der Bootvorgang dann analog angestoßen wird. Es sind 2 Binaries zu unterscheiden '''grub.efi''' und '''grubx64.efi'''. Der Unterschied liegt hier in der Anzahl und Auswahl der Module die mit in das binary gepackt sind. Ohne [[Secure Boot]] könnte von beiden gestartet werden, bei SecureBoot wird '''grub.efi''' benötigt und auch automatisch von Shim aufgerufen.<br>
 Neben diesen beiden GRUB-Binaries gibt es dort noch eine '''grub.cfg''', sie enthält nur wenige Zeilen und beinhaltet das Laufwerk und die Bezeichnung der richtigen '''grub.cfg''' mit der Grub Konfiguration für das booten.<br>
 Die Dateien am Beispiel OpenSUSE:

@@ Zeile 80: / Zeile 80: @@
 [[Datei:Grub2-0.png|200px|thumb|left|Grub2 bei UEFI oft Standard]]
-[[GRUB_2]] ist schon seit einigen Jahren im Umfeld des Bootens vom BIOS bekannt. Für die Funktionalität auch im UEFI Umfeld zu arbeiten werden Grub2-Binaries auf der [[ESP]] hinterlegt, mit denen der Bootvorgang dann analog angestoßen wird. Es sind 2 Binaries zu unterscheiden '''grub.efi''' und '''grubx64.efi'''. Der Unterschied liegt hier in der Anzahl und Auswahl der Module die mit in das binary gepackt sind. Ohne Secureboot könnte von beiden gestartet werden, bei Secureboot wird '''grub.efi''' benötigt und auch automatisch von Shim aufgerufen.<br>
+[[GRUB2]] ist schon seit einigen Jahren im Umfeld des Bootens vom BIOS bekannt. Für die Funktionalität auch im UEFI Umfeld zu arbeiten werden GRUB2-Binaries auf der [[ESP]] hinterlegt, mit denen der Bootvorgang dann analog angestoßen wird. Es sind 2 Binaries zu unterscheiden '''grub.efi''' und '''grubx64.efi'''. Der Unterschied liegt hier in der Anzahl und Auswahl der Module die mit in das binary gepackt sind. Ohne [[SecureBoot]] könnte von beiden gestartet werden, bei SecureBoot wird '''grub.efi''' benötigt und auch automatisch von Shim aufgerufen.<br>
-Neben diesen beiden Grub-Binary gibt es dort noch eine '''grub.cfg''', sie enthält nur wenige Zeilen und beinhaltet das Laufwerk und die Bezeichnung der richtigen '''grub.cfg''' mit der Grub Konfiguration für das booten.<br>
+Neben diesen beiden GRUB-Binaries gibt es dort noch eine '''grub.cfg''', sie enthält nur wenige Zeilen und beinhaltet das Laufwerk und die Bezeichnung der richtigen '''grub.cfg''' mit der Grub Konfiguration für das booten.<br>
-Die Dateien am Beispiel OpenSuse:
+Die Dateien am Beispiel OpenSUSE:
 <pre>
 # ls -l EFI/opensuse/gru*
@@ Zeile 93: / Zeile 93: @@
 configfile $prefix/grub.cfg
 </pre>
-Grub2 wird von den meisten Distributionen derzeit als Standard für UEFI Boot verwendet, dementsprechend gut ist auch die Unterstützung mit Konfigurationstools (zB YAST) und bei der Installation, so das in diesem Zusammenhang in aller Regel nichts manuell konfiguriert werden muss.
+GRUB2 wird von den meisten Distributionen derzeit als Standard für UEFI Boot verwendet, dementsprechend gut ist auch die Unterstützung mit Konfigurationstools (z.B. [[YaST]]) und bei der Installation, so das in diesem Zusammenhang in aller Regel nichts manuell konfiguriert werden muss.
 ===ELILO===

@@ Zeile 1: / Zeile 1: @@
 [[Kategorie:UEFI]]
 ==UEFI geeignete Bootloader==
@@ Zeile 177: / Zeile 176: @@
 elilo kann mit shim im Secure Boot betrieben werden. Das Binary aus opensuse und shim aus opensuse sowie die orginal von opensuse signierten Kernel booten ohne Problem auch im Secure boot. (Allerdings ist im Opensuse shim "grub.efi" als einziger möglicher Bootloadernamen im shim binary fest hinterlegt. Die Datei elilo.efi müsste also für diesen Zweck in grub.efi umbenannt werden damit das funktioniert.) Andere oder eigene Kernel müssten signiert werden und das Zertifikat im MOK eingetragen werden. (siehe dazu shim)
 ===rEFInd===
@@ Zeile 209: / Zeile 213: @@
 refind kann problemlos hinter shim verwendet werden, in dem das Zertifikat mit die Binardateien von refind signiert sind im MOK eingetragen werden. Das Zertifikat (sowie eine ganze Reihe weiterer gebräuchlicher public Zertifikate sind im Binärpaket mit enthalten.)
 SHIM von Opensuse verlangt allerdings grub.efi als Bootloadernamen den er aufruft. Die refind Binärdatei müsste also in diesen Namen umbenannt werden. Weitere Lizenzen müssten gegebenfalls für die einzelnen zu startenden Bootloader, Kernel und UEFI-Applikationen im MOK eingetragen werden, soweit sie in der Datenbank vom UEFI in Shim oder MOK nicht schon vorhanden sind.
 ===Gummiboot SD-Boot Systemd-boot===

@@ Zeile 239: / Zeile 239: @@
 Bei [http://mjg59.dreamwidth.org/20303.html shim] handelt es sich nicht um einen Bootloader im eigentlichem Sinn, welcher ein Operatingsystem direkt booten kann. Vielmehr kann man sich shim vorstellen wie eine Unterlegscheibe unter einem Bootloader der die Kompatibilität des Bootloaders mit [[Secure Boot]] herstellt.<br>
-Beim Secure Boot können nur Treiber, Applikationen, Bootloader und Kernel geladen und gestartet werden, wenn sie mit einem Zertifikat signiert sind, das sich in der Secure Datenbank des UEFI befindet. Diese Tools signieren kann nur der, der den privaten Schlüsses eines dieser Zertifikate hat.  Die Datenbank wird schon währende des Herstellungsprozesses angelegt und weitere Einträge in diese Datenbank kann nur jemand machen, der private Schlüssel zu dieser Datenbank hat. Praktisch kann also nur der HW-Hersteller und Microsoft dort Einträge machen, und auch nur diese sind damit in der Lage, mit ihrem Schlüssel einen Bootloader, UEFI-Treiber oder Kernel zu signieren, damit dieser im Secure Boot funktioniert. Dieses stellt ein Problem für Linux, da nicht nur die Bootloader sondern z.B. auch die Kernel welcher der Bootloader über UEFI laden will beim Booten gegen diese Datenbank überprüft werden.<br>
+Beim Secure Boot können nur Treiber, Applikationen, Bootloader und Kernel geladen und gestartet werden, wenn sie mit einem Zertifikat signiert sind, das sich in der Secure Datenbank des UEFI befindet. Diese Tools signieren kann nur der, der den privaten Schlüssel eines dieser Zertifikate hat.  Die Datenbank wird schon währende des Herstellungsprozesses angelegt und weitere Einträge in diese Datenbank kann nur jemand machen, der private Schlüssel zu dieser Datenbank hat. Praktisch kann also nur der HW-Hersteller und Microsoft dort Einträge machen, und auch nur diese sind damit in der Lage, mit ihrem Schlüssel einen Bootloader, UEFI-Treiber oder Kernel zu signieren, damit dieser im Secure Boot funktioniert. Dieses stellt ein Problem für Linux, da nicht nur die Bootloader sondern z.B. auch die Kernel welcher der Bootloader über UEFI laden will beim Booten gegen diese Datenbank überprüft werden.<br>
-Opensuse und viele andere Distributionen haben sich derzeit bei Secure Boot für den "Umweg" über shim entschieden.
+OpenSuse und viele andere Distributionen haben sich derzeit bei Secure Boot für den "Umweg" über shim entschieden.
@@ Zeile 247: / Zeile 247: @@
 Shim bietet eine Art Erweiterung der UEFI-Datenbank. Shim selbst wird von den Distributionen eingereicht zum signieren mit einem der Microsoft Keys, bzw. es kann auch signiert von der [http://www.codon.org.uk/~mjg59/shim-signed/ Entwicklerseite downgeloadet] werden.  Shim kann mit diesem Schlüssel somit erst einmal im Secure Boot Modus starten. Die Aufgabe von Shim ist es, dann einen "richtigen" Bootloader zu laden und zu starten und zu überwachen, welchen Kernel dieser lädt. Der Bootloader, den shim aufruft, muss mit einem Zertifikat signiert sein, welches entweder die UEFI-Datenbank kennt (dann bräuchten wir shim auch nicht), oder welches shim bekannt ist. Das gleiche trifft dann auch auf den Kernel zu, der vom Bootloader geladen werden soll. Dieser muss ebenfalls signiert sein.<br>
 Hier liegt jetzt der Unterschied, Bootloader und Kernel müssen von Microsoft signiert werden, sondern es reicht wenn sie eine Signatur tragen die wir Shim bekannt geben.
-In der Praxis wird ein shim-binary, welchem intern das Zertifikat des Build-Services der Distribution schon eingepflanzt ist, bei Microsoft zur Signierung eingereicht. Mit diesem signierten shim binary lassen sich dann der von der Distribution signierte Bootloader und auch alle von der Distribution signiert Kernel im Secure Boot Modus starten. Die Distribution kann Kernel und Bootloader patchen und braucht nur diese neuen Binaries mit ihrem eigenem Zertifikat zu signieren, und alles funktioniert im Secure Boot, auch ohne dass hierzu irgendwas wieder neu bei Micosoft signiert werden muß.
+In der Praxis wird ein shim-binary, welchem intern das Zertifikat des Build-Services der Distribution schon eingepflanzt ist, bei Microsoft zur Signierung eingereicht. Mit diesem signierten shim binary lassen sich dann der von der Distribution signierte Bootloader und auch alle von der Distribution signiert Kernel im Secure Boot Modus starten. Die Distribution kann Kernel und Bootloader patchen und braucht nur diese neuen Binaries mit ihrem eigenem Zertifikat zu signieren, und alles funktioniert im Secure Boot, auch ohne dass hierzu irgendwas wieder neu bei Microsoft signiert werden muß.
 Was damit so erst einmal noch nicht geht, z.B. dem Bootloader einer andere Linuxdistribution starten oder eigene Kernel starten. Diese sind entweder nicht oder mit einem für die UEFI-Datenbank und ebenfalls für shim unbekanntem Zertifikat signiert.<br>
@@ Zeile 253: / Zeile 253: @@
 ====Die MOK-Liste====
-Um auch andere Bootloader verwenden zu können, UEFI-Treiber oder andere UEFI-Tools die nicht von einem vom shim bekannten Zertifikat signiert sind, bzw. auch andere Kernel im Secure Boot starten zu können, gibt es mit shim eine Art Erweiterung der Secure UEFI-Datenbank. Diese Erweiterung funktioniert analog der WhiteList aus der UEFI-Secure Datenbank. In ihr können Zertifikate und Hash-Werte von Binaries hinterlegt werden, die shim akzeptieren soll. Diese shim eigene Erweiterung nennt sich MOK Liste (MOK '''M'''achine '''O'''wner '''K'''ey). Eintragungen in diese Liste können mehr oder weniger nur vom einem physikalisch am Rechner befindlichen User vor dem Booten des Rechners vorgenommen werden. Die UEFI-Variable, welche diese Wert speichert, ist zwar bei jedem Start von UEFI bekannt, hat aber nur eine Lebenszeit bis der Bootloader den Start des Betriebssystems an den UEFI meldet, ist also später auf Betriebssystem-Ebene nicht mehr vorhanden und kann desshalb auch z.B. von Malware nicht manipuliert werden.<br>
+Um auch andere Bootloader verwenden zu können, UEFI-Treiber oder andere UEFI-Tools die nicht von einem vom shim bekannten Zertifikat signiert sind, bzw. auch andere Kernel im Secure Boot starten zu können, gibt es mit shim eine Art Erweiterung der Secure UEFI-Datenbank. Diese Erweiterung funktioniert analog der WhiteList aus der UEFI-Secure Datenbank. In ihr können Zertifikate und Hash-Werte von Binaries hinterlegt werden, die shim akzeptieren soll. Diese shim eigene Erweiterung nennt sich MOK Liste (MOK '''M'''achine '''O'''wner '''K'''ey). Eintragungen in diese Liste können mehr oder weniger nur vom einem physikalisch am Rechner befindlichen User vor dem Booten des Rechners vorgenommen werden. Die UEFI-Variable, welche diese Wert speichert, ist zwar bei jedem Start von UEFI bekannt, hat aber nur eine Lebenszeit bis der Bootloader den Start des Betriebssystems an den UEFI meldet, ist also später auf Betriebssystem-Ebene nicht mehr vorhanden und kann deshalb auch z.B. von Malware nicht manipuliert werden.<br>
 Das Programm, mit dem solche Eintragungen vom User bei Bedarf selbst vorgenommen werden können, trägt den Namen '''MokManager.efi''' und ist Bestandteil des shim-Paketes. Das Binary befindet sich im gleichem Verzeichnis wie shim auf der UEFI-Partition.
@@ Zeile 270: / Zeile 270: @@
 Bei den Hash ist es analog, dieses ist z.B. geeignet für UEFI-Programme, die nicht signiert sind und die man auch nicht mit einem eigenem Zertifikat signieren möchte.
-Sollte man anstatt '''Grub2''' hinter '''shim''' einen anderen Bootloader wünschen, ist dieses auch möglich z.B. für '''rEFInd''' oder '''ELILO'''. Die Konfiguration des gewünschten  anderen Bootloaders bei ausgeschalteten Secure Boot komplett fertig machen und testen. Das Bootloaderbinary überprüfen mit welchem Key es signiert ist, bzw diese selbst signieren und das entsprechende Zertifikat auf ein FAT-Dateisystem für den Import in die MOK-List vorbereiten. Danach shim.efi und MokManger.efi in das Verzeichnis dieses Bootloaders kopieren. Das Binärprogramm des Bootloaders muss umbenannt werden, da '''shim''' wahrscheinlich von den Distributionen so konfiguriert wurde, dass es nur den Namen '''grub.efi''' als Bootmanager akzeptiert. Also eine Kopie dieses Bootloader Binary als grub.efi dort im Verzeichnis anlegen. Danach muss nur ein Booteintrag für den Shim neu erstellt werden. Ist das alles so richtig, dann sollte das System mit ausgeschalteten Secure Boot jetzt auch schon über shim booten.<br>
+Sollte man anstatt '''Grub2''' hinter '''shim''' einen anderen Bootloader wünschen, ist dieses auch möglich z.B. für '''rEFInd''' oder '''ELILO'''. Die Konfiguration des gewünschten  anderen Bootloaders bei ausgeschalteten Secure Boot komplett fertig machen und testen. Das Bootloaderbinary überprüfen mit welchem Key es signiert ist, bzw diese selbst signieren und das entsprechende Zertifikat auf ein VFAT-Dateisystem für den Import in die MOK-List vorbereiten. Danach shim.efi und MokManger.efi in das Verzeichnis dieses Bootloaders kopieren. Das Binärprogramm des Bootloaders muss umbenannt werden, da '''shim''' wahrscheinlich von den Distributionen so konfiguriert wurde, dass es nur den Namen '''grub.efi''' als Bootmanager akzeptiert. Also eine Kopie dieses Bootloader Binary als grub.efi dort im Verzeichnis anlegen. Danach muss nur ein Booteintrag für den Shim neu erstellt werden. Ist das alles so richtig, dann sollte das System mit ausgeschalteten Secure Boot jetzt auch schon über shim booten.<br>
-Nach dem Einschalten von Secure Boot wird shim dann aber gegenenfalls feststellen, dass der neue Bootloader mit einem anderem Zertifikat signiert ist, und wird von sich aus gleich den MokManager starten. Hat man das Zertifikat jetzt schon im richtigen Format auf einer FAT-Partition im System, kann man es sofort hier in die MOK-List eintragen. Und nach einem Neustart im Secure Mode schauen, ob der Rechner jetzt über shim und dem anderem Bootloader sauber bootet.
+Nach dem Einschalten von Secure Boot wird shim dann aber gegebenenfalls feststellen, dass der neue Bootloader mit einem anderem Zertifikat signiert ist, und wird von sich aus gleich den MokManager starten. Hat man das Zertifikat jetzt schon im richtigen Format auf einer FAT-Partition im System, kann man es sofort hier in die MOK-List eintragen. Und nach einem Neustart im Secure Mode schauen, ob der Rechner jetzt über shim und dem anderem Bootloader sauber bootet.
 Siehe hierfür auch [[Secure Boot]].

@@ Zeile 184: / Zeile 184: @@
 [http://www.rodsbooks.com/refind/ rEFInd] kommt ursprünglich aus der Mac OS X Welt, ist aber für Linux genauso gut geeignet. rEFInd sucht alles mögliche bootbare ob EFI oder MBR basierend, Bootmanager, Linux-Kernel, Windows-Bootloader und auch sonstigen UEFI-Applikatione die es finden kann. Dabei werden auch per default einige nützliche UEFI Tools gesucht und wenn vorhanden ebenfalls angezeigt, wie EFI-Shell MokManager Speichertest .....<br>
-Das alles wird dann im Bootmanager schön mit passenden Icons angezeigt und kann von dort gestartet werden. Es werden so alle möglichen Bootmanager angezeigt, die sich derzeit auf dem Rechner befinden, ob nun auf einer CD/DVD irgendwo in einem der MBR einer Platte oder alle gefunden UEFI-Bootloader sowie auch Kernel die er irgendwo finden kann und das alles automatich ohne all dieses vorher zu konfigurieren. Es ist ein (schwarzer) Bildschirmschoner möglich, Icons für Reboot, Ausschalten und BIOS-Setup .... Ein echter Überflieger, wenn man viele Bootloader im System hat, oder sonst wie mit all seinen Bootmöglichkeiten den Überblick verloren hat.
+Das alles wird dann im Bootmanager schön mit passenden Icons angezeigt und kann von dort gestartet werden. Es werden so alle möglichen Bootmanager angezeigt, die sich derzeit auf dem Rechner befinden, ob nun auf einer CD/DVD irgendwo in einem der MBR einer Platte oder alle gefunden UEFI-Bootloader sowie auch Kernel die er irgendwo finden kann und das alles automatisch ohne all dieses vorher zu konfigurieren. Es ist ein (schwarzer) Bildschirmschoner möglich, Icons für Reboot, Ausschalten und BIOS-Setup .... Ein echter Überflieger, wenn man viele Bootloader im System hat, oder sonst wie mit all seinen Bootmöglichkeiten den Überblick verloren hat.
 rEFInd bringt eine ganze Reihe von UEFI-Treibern (read only) für unterschiedliche Dateisysteme mit (ext2 ext4 btrfs hfs iso9660 ntfs reiserfs)<br>
-Damit können auch Kernel und Bootloader gefunden werden, die sich nicht auf der UEFI-Partition oder in einem FAT Dateisystem befinden.
+Damit können auch Kernel und Bootloader gefunden werden, die sich nicht auf der UEFI-Partition oder in einem VFAT Dateisystem befinden.
 ====Installation und Konfiguration====
 Einige Distributionen unterstützen rEFInd als default Bootloader, bei allen anderen kann man aber das Binär Paket von der Projektseite problemlos benutzen.
-Bei Opensuse gibt es default keine Pakete. Es reicht das [http://www.rodsbooks.com/refind/getting.html Standard-binär-paket] als zip (eventuell geht auch das rpm Paket, welches das Install-Script bei der Installation gleich mit ausführen würde). Aktuelle Version 0.8.7 downloaden, entpacken und in das Verzeichnis wechseln. Benötigt wird zum Installieren nur das '''install.sh''' Script. die beiden anderen Scripte (eines zum Konfigurieren des aktuellen Systems und eines zum Verschieben der rEFInd-Dateien auf die UEFI-Partition) werden automatisch dabei mit ausgeführt.<br>
+Bei Opensuse gibt es default keine Pakete. Es reicht das [http://www.rodsbooks.com/refind/getting.html Standard-binär-Paket] als zip (eventuell geht auch das rpm Paket, welches das Install-Script bei der Installation gleich mit ausführen würde). Aktuelle Version 0.8.7 downloaden, entpacken und in das Verzeichnis wechseln. Benötigt wird zum Installieren nur das '''install.sh''' Script. die beiden anderen Scripte (eines zum Konfigurieren des aktuellen Systems und eines zum Verschieben der rEFInd-Dateien auf die UEFI-Partition) werden automatisch dabei mit ausgeführt.<br>
 '''install.sh''' ausführen, und fertig. rebooten und staunen.
@@ Zeile 207: / Zeile 207: @@
 ====Secure Boot====
-refind kann problemlos hinter shim verwendet werden, in dem das Zertifikat mit die Binardateien von refind signiert sind im MOK eingetragen werden. Das Zertifikat (sowie eine ganze Reihe weiterer gebäuchlicher public Zertifikate sind im Binärpaket mit enthalten.)
+refind kann problemlos hinter shim verwendet werden, in dem das Zertifikat mit die Binardateien von refind signiert sind im MOK eingetragen werden. Das Zertifikat (sowie eine ganze Reihe weiterer gebräuchlicher public Zertifikate sind im Binärpaket mit enthalten.)
 SHIM von Opensuse verlangt allerdings grub.efi als Bootloadernamen den er aufruft. Die refind Binärdatei müsste also in diesen Namen umbenannt werden. Weitere Lizenzen müssten gegebenfalls für die einzelnen zu startenden Bootloader, Kernel und UEFI-Applikationen im MOK eingetragen werden, soweit sie in der Datenbank vom UEFI in Shim oder MOK nicht schon vorhanden sind.
 ===Gummiboot SD-Boot Systemd-boot===

@@ Zeile 104: / Zeile 104: @@
 [[Datei:Elilo-1.png|200px|thumb|left|ELILO im Textmenu]]
-'''[http://elilo.sourceforge.net/ elilo]''' ist ein einfacher UEFI Bootloader der nicht nur mit dem Namen an LILO erinnert. Er ermöglicht nur das booten von Linux und hat ähnliche Möglichkeiten wie viele Bootloader die wir in den letzten Jahren als Bootloader auf Install DVDs gesehen haben. Er kann beim Booten einen Defaulteintrag booten, (auch Netzwerkboot ist möglich) und kann mit einem Fallback Booteintrag konfiguriert werde, der dann bootet, wenn der Defaulteintrag fehl schlägt.<br>
+'''[http://elilo.sourceforge.net/ elilo]''' ist ein einfacher UEFI Bootloader der nicht nur mit dem Namen an LILO erinnert. Er ermöglicht nur das booten von Linux und hat ähnliche Möglichkeiten wie viele Bootloader die wir in den letzten Jahren als Bootloader auf Install-DVDs gesehen haben. Er kann beim Booten einen Defaulteintrag booten, (auch Netzwerkboot ist möglich) und kann mit einem Fallback Booteintrag konfiguriert werde, der dann bootet, wenn der Defaulteintrag fehl schlägt.<br>
 Darüber hinaus kann er so konfiguriert werden, dass beim booten aus mehreren Booteinträgen mittels Textmenü ein Eintrag ausgewählt werden kann, und auch diesen Eintrag ändern zu können.<br>
 Derzeit wird elilo noch von einigen Distributionen als Paket angeboten, doch da sich die meisten großen Distributionen auf andere UEFI-Bootloader eingeschossen haben, ruht die Entwicklung von elilo derzeit [http://sourceforge.net/projects/elilo/ eingestellt].
@@ Zeile 168: / Zeile 168: @@
 Bei der [[UEFI Boot Konfiguration|Konfiguration des Bootloaders]] ist dann im UEFI-Syntax die Datei "'''\EFI\opensuse\elilo.efi'''" als Bootloadervariable anzulegen.<br>
 elilo startet den default-Eintrag oder den ersten Eintrag aus der Konfiguration nach Ablauf des timeout automatisch. Beim Betätigen einer Taste vom dem Ablauf des timeout wird der interaktive Mode gestartet. (welcher Mode entscheidet die Chooser-Option) Der Interaktive Mode kann aber durch die prompt Option entweder innerhalb der Konfiguration oder beim Start von elilo forciert werden<br>
-Ist die Option Chooser Textmenu konfiguriert mit den entsprechenden Konfigurationsdateien, dann wird die Menuauswahl gestartet, ansonsten ohne Chooser Konfiguration das interne "Simple", welches eine etwas gewöhnungsbedürftige Textbasierende Auswahl- und Konfgurationsmöglichkeit darstellt.
+Ist die Option Chooser Textmenu konfiguriert mit den entsprechenden Konfigurationsdateien, dann wird die Menuauswahl gestartet, ansonsten ohne Chooser Konfiguration das interne "Simple", welches eine etwas gewöhnungsbedürftige Text-basierende Auswahl- und Konfigurationsmöglichkeit darstellt.
 elilo kann auch mit Optionen direkt aus der EFI-Shell gestartet werden, oder dort mit Hilfe von elilo ein mit Optionen spezifizierter Bootvorgang eingeleitet werden, der nicht in der Konfiguration steht.<br>
@@ Zeile 177: / Zeile 177: @@
 elilo kann mit shim im Secure Boot betrieben werden. Das Binary aus opensuse und shim aus opensuse sowie die orginal von opensuse signierten Kernel booten ohne Problem auch im Secure boot. (Allerdings ist im Opensuse shim "grub.efi" als einziger möglicher Bootloadernamen im shim binary fest hinterlegt. Die Datei elilo.efi müsste also für diesen Zweck in grub.efi umbenannt werden damit das funktioniert.) Andere oder eigene Kernel müssten signiert werden und das Zertifikat im MOK eingetragen werden. (siehe dazu shim)
 ===rEFInd===

@@ Zeile 22: / Zeile 22: @@
 ====Nachteile====
-Da UEFI per default nur FAT Dateisysteme lesen kann, müsste der Kernel in einem solchem abgelegt werden, typischerweise auf der UEFI-Partiton. FAT kennt keine UNIX Dateirechte, die Dateirechte von solchen Dateisystemen müssen für Linux immer simuliert werden und sind nicht wirklich kompatibel, womit für den Kernel und die initrd keine sicheren Zugriffsrechte vorhanden sind.
+Da UEFI per default nur VFAT Dateisysteme lesen kann, müsste der Kernel in einem solchem abgelegt werden, typischerweise auf der UEFI-Partiton. VFAT kennt keine UNIX Dateirechte, die Dateirechte von solchen Dateisystemen müssen für Linux immer simuliert werden und sind nicht wirklich kompatibel, womit für den Kernel und die initrd keine sicheren Zugriffsrechte vorhanden sind.
 Der Kernel und die initrd sind auch oftmals große Dateien und das dort typischerweise angelegte Dateisystem nicht sehr groß. Für Linux ist /boot als Kernelverzeichnis typisch und wird von allen Scripten und Programmen auch dort gesucht. Unter /boot/efi wird das UEFI-Dateisystem zusätzlich gemountet.  Der Kernel und die initrd müssten also irgendwie immer zusätzlich umbenannt und noch in das UEFI Filesystem zusätzlich hinein kopiert werden, damit existieren dann aber auch immer 2 eigentlich gleiche Dateien. Für Kernel Updates, Erzeugen von initrd und ähnlichem ist dieses sehr unpraktisch.
 Auch ist der Kernel und die initrd dort in dieser UEFI-Partition nicht wirklich sicher vor Manipulationen.
@@ Zeile 43: / Zeile 43: @@
 Da die Binary von Bootloadern vollkommen unabhängig vom Betriebssystem funktionieren, ist es aber möglich diese Dateien auch aus Paketen einer anderen Distribution auf seinem eigenen Rechner einzusetzen. Möglich ist z.B. die 2 Pakete [ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/17/Everything/x86_64/os/Packages/g/grub-0.97-93.fc17.x86_64.rpm grub] und [ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/17/Everything/x86_64/os/Packages/g/grub-efi-0.97-93.fc17.x86_64.rpm grub-efi] von Fedora17 dafür zu verwenden.
-Möglich, dass die eine oder andere Distibution derzeit noch einen UEFI fähigen grub legacy anbietet, eine Zukunft dafür gibt es sicher nicht mehr. Es ist leider an der Zeit, uns von unserem guten alten GRUB endgültig zu verabschieden. Es ist noch mit einiger Handarbeit möglich, Grub unter UEFI einzusetzten - es wird aber dringend davon abgeraten. Der QuellCode von Grub ist zu alt und größtenteils explizit für 32 Bit CPUs geschrieben, schlecht gewartet und nur elementar an die Erfordernisse und Gegebenheiten von UEFI angepasst.
+Möglich, dass die eine oder andere Distribution derzeit noch einen UEFI fähigen grub legacy anbietet, eine Zukunft dafür gibt es sicher nicht mehr. Es ist leider an der Zeit, uns von unserem guten alten GRUB endgültig zu verabschieden. Es ist noch mit einiger Handarbeit möglich, Grub unter UEFI einzusetzen - es wird aber dringend davon abgeraten. Der Quell-Code von Grub ist zu alt und größtenteils explizit für 32 Bit CPUs geschrieben, schlecht gewartet und nur elementar an die Erfordernisse und Gegebenheiten von UEFI angepasst.
-====Experimeneller Test====
+====Experimenteller Test====
 * Voraussetzung /boot ist auf ext2 ext3 oder ext4 und nicht etwa btrfs
@@ Zeile 111: / Zeile 111: @@
 ====Nutzungsmöglichkeiten====
-Bei elilo müssen sowohl das Bootloaderbinary sowie eine Konfigurartionsdatei, und ebenfalls Kernel und initrd vom UEFI lesbar sein, also entweder sich auf der UEFI-Partition oder eines anderen FAT-Dateisystems befinden. Alternativ müssten im UEFI erst Treiber für andere Dateisysteme geladen werden um zB Kernel und initrd aus den Linuxdateisystemen direket heraus nutzen zu können. Dieses beschränkt die praktikable Nutzbarkeit von elilo ein, da in einem aktiven Linux System zB nach Kernelupdates oder nach dem Erstellen einer neuen initrd die elilo-Konfiguration erst wieder angepasst werden müsste, dazu sind entweder intelligente Scripte notwendig oder dieses per Hand erledigt werden müsste<br>
+Bei elilo müssen sowohl das Bootloaderbinary sowie eine Konfigurationsdatei, und ebenfalls Kernel und initrd vom UEFI lesbar sein, also entweder sich auf der UEFI-Partition oder eines anderen VFAT-Dateisystems befinden. Alternativ müssten im UEFI erst Treiber für andere Dateisysteme geladen werden um zB Kernel und initrd aus den Linuxdateisystemen direkt heraus nutzen zu können. Dieses beschränkt die praktikable Nutzbarkeit von elilo ein, da in einem aktiven Linux System zB nach Kernelupdates oder nach dem Erstellen einer neuen initrd die elilo-Konfiguration erst wieder angepasst werden müsste, dazu sind entweder intelligente Scripte notwendig oder dieses per Hand erledigt werden müsste<br>
 Ideal ließe sich elilo überall einsetzen, wo es keine solchen Kernel Updates geben wird, oder geben kann. zB auf bootbaren DVDs und ähnlichen. Praktisch auch gut einsetzbar bei einem System welches remote administriert wird und normalerweise über das Netz gebootet werden soll. Sollte der Netzboot einmal nicht funktionieren, würde elilo einen für solche Fälle konfigurierbaren Alternativen Booteintrag booten, somit das System danach remote hoffentlich trotzdem wieder erreichbar sein.

@@ Zeile 220: / Zeile 220: @@
-===Gummiboot===
+===Gummiboot SD-Boot Systemd-boot===
 [[Datei:Gummiboot-0.png|200px|thumb|left|UEFI Bootloader Gummiboot]]
-[https://en.wikipedia.org/wiki/Gummiboot_%28software%29 Gummiboot] ist, bzw. war ein minimalistischer UEFI Bootloader. Als optionales Paket in vielen Distributionen enthalten, wurde jedoch wenig genutzt. Ebenso wie ELILO ist auch er angewiesen darauf, das der Kernel und die Initrd im [[ESP]] abgelegt ist, bzw. die UEFI Funktionalität mit Filesystemtreibern erweitert wurde. Installation des Bootloaders einfach mit dem  Befehl
+[https://en.wikipedia.org/wiki/Gummiboot_%28software%29 Gummiboot] ist, bzw. war ein minimalistischer UEFI Bootloader. Als optionales Paket in vielen Distributionen enthalten, wurde jedoch wenig genutzt. Ebenso wie ELILO ist auch er angewiesen darauf, das der Kernel und die Initrd im [[ESP]] oder auf einer weiteren VFAT Partition abgelegt ist, bzw. (aber nicht vorgesehen) die UEFI Funktionalität mit UEFI-Treibern auf andere Filesystemtypen erweitert wurde. Installation des Bootloaders einfach mit dem  Befehl
   gummiboot install
-Weitere Optionen wie '''update''', '''status''' und '''remove'''. Die Bootoptionen sind unterhalb von loader/entries auf der EFI-Partition abgelegt und werden in der Regel mit Scripten erstellt. Gummiboot kann hinter shim auch beim Secureboot verwendet werden. Anders als zB. bei Grub2 könnte auch durch die andere [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License Lizenzierung] der Software eventuell auch eine direkte Signierung für UEFI Secureboot angestrebt werden.<br>
+Weitere Optionen wie '''update''', '''status''' und '''remove'''. Die Bootoptionen sind unterhalb von loader/entries/ auf der EFI-Partition oder einer weiteren VFAT Partition abgelegt und werden in der Regel mit Scripten erstellt. Diese Partitionen sind von Linux zu mounten. Die einzelnen Booteinträge haben im Namen die Maschinen-ID und die OS-ID, sowie die Endung "conf". Die Einträge innerhalb einer solchen Bootkonfiguration sind teilweise angelehnt an die grub-legacy Schreibweise. Gummiboot könnte auch hinter shim beim Secureboot verwendet werden. Eine komplette Übersicht über die Bootspezifikation von  [http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/  Gummiboot].
 In der Zwischenzeit wurde das Projekt eingestampft. Alle Pakete wurden aus dem Git Repository für Gummiboot gelöscht und das Paket wurde als obsolet erklärt. <br>
-Allerdings bedeutet dieses noch nicht das Ende von Gummiboot, denn der Code wurde mit der fadenscheinigen Begründung, mehr Kontrolle über den UEFI Bootvorgang zu benötigen, in [[Systemd]] aufgenommen und die Funktion nennt sich jetzt [https://github.com/systemd/systemd/tree/master/src/boot/efi SD-Boot] oder systemd-Boot. Man darf durchaus gespannt sein, wann und wer diese durchgeknallte Entwicklung mit samt seinem Hauptentwickler hin zu einem undurchsichtigen und alles kontrollieren wollenden Riesenmonster Namens systemd endlich Einhalt gebieten will.
+Allerdings bedeutet dieses noch nicht das Ende von Gummiboot, denn der Code wurde mit der fadenscheinigen Begründung, mehr Kontrolle über den UEFI Bootvorgang zu benötigen, in [[Systemd]] aufgenommen und die Funktion nennt sich jetzt [https://github.com/systemd/systemd/tree/master/src/boot/efi SD-Boot] oder nach einer weiteren Namensänderung '''systemd-boot'''. Um zu begründen warum systemd jetzt auch noch einen integrierten eigenen Bootloader braucht, wurde ein [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface/ BootLoaderInterface] erfunden mit dem ein paar Zeitinformationen an systemd übermittelt werden können. Na gut, wer's braucht. Interessanter dürfte sein, was man sich auf systemd Seite noch einfallen lassen wird, um die Distributionen zu zwingen/überreden auf grub2 zu verzichten und statt dessen per default auf systemd-boot zu setzen. Man darf durchaus gespannt sein, wann und wer diese durchgeknallte Entwicklung mit samt seinem Hauptentwickler hin zu einem undurchsichtigen und alles kontrollieren wollenden Riesenmonster Namens systemd endlich Einhalt gebieten will.