Diskussion:Efibootmgr

GRUB2

ToDo: Woher weiss der GRUB-Bootloader 'grubx64.efi' (also der erste Teil im EFI-Binärformat), dass die GRUB-Konfiguration auf '/dev/sda5' liegt? --Gehrke 07:38, 30. Apr. 2015 (CEST)

der Teil der von Grub2 auf die UEFI-Partition gesetzt wird und von dort aus von UEFI gestartet wird, muss ein paar Module beinhalten. zB. muss er das Dateisystem-Modul (eventuell auch noch weitere wie Raid LV usw) beinhalten, um überhaupt auf die jeweilige /boot Parition zugreifen zu können, da UEFI von sich aus nur FAT Lesen kann. Deshalb muss dieser Grub2 Teil beim Installieren desselben auch immer neu gebunden und in das Binärformat übersetzt werden, das UEFI versteht. Ich gehe davon aus das bei dieser Gelegenheit dann auch der Hardwarepath zur /boot Partition dort mit eingebunden wird. Den Rest findet dann Grub2 von sich aus. Robi 22:46, 4. Mai 2015 (CEST)

Revision Artikel

Vorschlag für einen anderen Einleitungsteil

Im Gegensatz zum herkömmlichen BIOS bietet UEFI eine eindeutig spezifizierte Schnittstelle, wie der Bootvorgang eines Systems stattfindet. Diese Schnittstelle kann von den Firmware-Herstellern auf unterschiedlichste Art und Weise implementiert werden, insbesondere unterscheiden sich die einzelnen Implementierungen in Funktionsumfang, dem User Interface (UI) und auch dem Aktualisierungsprozess. Die Lösungen der einzelnen Hersteller gehen in diesen Punkten weit auseinander und es scheint unmöglich, zu diesem Themenbereich eine Übersicht oder gar eine umfassende Dokumentation zu generieren.

Dies kann insbesondere im Supportfall eine große Hürde darstellen, wenn ein User ein Problem mit der Boot-Konfiguration hat. Im Falle eines Support-Forums müsste er zunächst mal jemanden finden, der diese spezielle Firmware-Implementierung kennt und kämpft zusätzlich noch mit dem Problem, dass in dieser frühen Phase kaum die notwendigen Werkzeuge zur Analyse und Kommunikation (OS, Netzwerk, Browser, Password-Safe...) zur Verfügung stehen. In der Regel bleibt hier dann nur der beschwerliche Weg über echte Fotos von den UEFI-Settings und Zugriff auf ein Support-Forum über externe Systeme.

Eine effizientere Vorgehensweise sollte der Zugriff auf diese standardisierten Funktionalitäten über die Werkzeuge des Betriebssystems sein. Sowohl Linux als auch andere Betriebssysteme bieten hier entsprechende Tools, welche nicht unter den oben genannten Einschränkungen leiden. Wenn beispielsweise im Falle eines Boot-Problemes eine Live-Distribution von USB-Stick gestartet werden kann, dann steht eine mächtige Arbeitsumgebung für Analyse und Kommunikation bereit und bietet mit efibootmgr ein standardisiertes Werkzeug, um die Boot-Konfiguration von UEFI zu verändern.

UEFI bietet eine spezifizierte Schnittstelle für die Bootauswahl. Diese ist wie vieles andere auch in UEFI-Variablen gespeichert.
In Variablen mit dem Namen Bootxxxx (wobei xxxx eine eindeutige Hexadezimalzahl ist die UEFI beim Anlagen dieser Variablen automatisch vergibt) wird jeweils genau eine Bootoption eines Gerätes oder Bootloaders und eventuell zusätzlichen Bootoptionen hinterlegt. Jede diese Bootvariablen enhält die Informationen für einen speziellen Bootvorgang, zB für einen bestimmten Bootloader.
Von diesen Variablen gibt es typischer Weise mehrere, und UEFI stellt von sich aus schon einige auf bootbare Devices wie zB Floppy CD/DVD zur Verfügung. Weitere dieser Variablen können automatisch während der Installation eines Bootloaderns oder manuell angelegt werden, nicht benötigte Variablen können gegebenenfalls auch manuell gelöscht werden.
Neben den "Bootxxxx" Variablen gibt es noch eine weitere Variable "BootOrder". In dieser Variable ist die Reihenfolge hinterlegt mit denen UEFI die "Bootxxxx" Variablen ausprobieren soll, um den Rechner zu booten. Der Inhalt dieser Variable enthält dann mehrere (komma-getrennte) hexadezimale Werte die sich auf die Bootxxxx Variablen beziehen. Die Variable kann entsprechend angepasst werden, um damit die Bootreihenfolge genau zu bestimmen. Daneben gibt es noch eine weitere Variable ("BootNext") die gesetzt werden könnte, um einmalig beim nächsten Bootvorgang mit dem darin gespeicherten hexadezimal Wert und der damit festgelegten Bootxxxx Variable den Vorrang beim booten einzuräumen, noch bevor die normale Bootreihenfolge aus "BootOrder" zum Zuge kommt.

Änderungen an diesen Variablen können sowohl aus dem UEFI-BIOS-Setup, aus Tools und Befehlen heraus die im UEFI Umfeld gestartet werden, als auch aus dem Betriebssystem heraus vorgenommen werden. Das UEFI-BIOS-Setup ist nicht standardisiert und jeder Hersteller gestaltet es vom Umfang, Funktion und Aussehen anders, so dass man die Vorgehensweise hier nicht allgemeingültig beschreiben kann. Es sollte aber mindestens aus der jeweils mitgelieferten Doku zum Rechner oder Mainboard entnommen werden können. Linux wird bei der UEFI-Installation oder dem UEFI-Start einer Live-DVD ein Tool namens "efibootmgr" zur Verfügung stellen, mit dessen Hilfe es möglich ist, diese UEFI-Variabeln zu bearbeiten und somit die Bootauswahl des Rechners eindeutig zu konfigurieren.

shim: Aussage stimmt so nicht

shim ist ein einfacher Pre-Boot-Loader, dessen Aufgabe es ist, den nächsten in der Bootreihenfolge stehenden Bootloader unter Berücksichtigung der Zertifikatskette (SecureBoot) zu starten. In diesem Beispiel ist der nächste Eintrag 'Boot0006* opensuse', welcher ebenfalls ein signierter Bootloader ist. dieses würde bedeuten, ich kann mit umändern der Bootreihenfolge bestimmen was shim laden soll, dieses habe ich auch irgendwo fälschlicherweise im Wiki oder im Forum auch irgendwo geschrieben, das stimmt aber so nicht, Shim läd nicht den nächsten Bootloader in der Bootreihenfolge, sondern eine Datei im selben Verzeichnis die einen bestimmten Dateinamen (eventuell sind auch mehrere Dateinamen möglich die dann der Reihe nach durchprobiert werden) besitzt. Dieser Dateinamen wird während des kompilieren von Shim festgelegt. Typischer Weise ist dieser Dateiname der grub.efi . Wird ein andere Bootloader auf den Namen grub.efi umbenannt und befindet sich im selben Verzeichnis wie shim, dann wird dieser gestartet. Ursprünglich sind bei shim wohl grub refind und elilo als nachfolgende Dateiloader vorgesehen, also diese Bootloadernamen dafür sollten bei der Kompilation theoretisch alle, oder einzeln in Shim einzubinden sein. Robi 00:19, 5. Mai 2015 (CEST)

Dank für das Review. Obigen Text habe ich tatsächlich mehr oder weniger unreflektiert von hier übernommen: [1]

Ich kann das hier im Wiki ändern, würde aber dafür plädieren, dies ebenfalls im Forum richtig zu stellen. Im Forum kannst aber nur Du als Autor dies tun...

--Gehrke 07:44, 5. Mai 2015 (CEST)