Beim klassischen BIOS-Boot kann ein Fehler in der MBR das System unbenutzbar machen. Man muss dann erst umständlich per Rettungsmedium den MBR wiederherstellen.
Bei UEFI ist das kein Problem:
Solange die Firmware eine UEFI-Shell eingebaut hat, kann man die Bootloader direkt darüber starten.
Ein zweiter Vorteil ist, dass sich die einzelnen Betriebssysteme nicht mehr ins Gehege kommen. Leider überschreibt Windows standardmäßig immer den Standardloader im UEFI-Bootmenü (Sprich es mogelt sich immer zum Standard). Wer Grub2 zum Standard erheben will, muss unter Windows in einer Admin-Shell folgendes Kommando eingeben:
bcdedit /set {bootmgr} "\EFI\ubuntu\shimx64.efi" (Für SecureBoot unter Ubuntu)
bcdedit /set {bootmgr} "\EFI\ubuntu\grubx64.efi" (Ohne Secureboot unter Ubuntu)
Andere Distributionen müssen nur den Pfad anpassen.
Der Artikel ist aber etwas durcheinander geraten oder habe nur ich den Eindruck?
So bootet der PC durch UEFI nicht automatisch merkbar schneller, das ist allenfalls der Implementierung des Mainboards geschuldet, aber nicht die Regel.
Der Hinweis "es ist einfacher, Systeme parallel zu installieren" macht nur bei internen Datenträgern Sinn, dann passt aber "Aus historischen Gründen nutzen Linux-Distributionen für den BIOS-Boot den Bootloader Isolinux/Syslinux." nicht, was sich nur auf externe Datenträger beziehen kann.
Auch den Hinweis mit dem Boot-Flag halte ich für ein Gerücht, das war allenfalls ein Fehler in der einen oder anderen BIOS-Implementierung.
"Startfähige USB-Sticks oder Speicherkarten für den UEFI-Boot sind deshalb auch ohne spezielle Werkzeuge schnell erstellt:" dd fällt wohl kaum unter spezielles Werkzeug, zumindest nicht mehr als mc oder cp Und mehr braucht es nicht um eine Linux-Installations-CD auf einen USB-Stick zu kopieren, egal ob BIOS oder UEFI-Boot.
Aber warum ich eigentlich auf deinen Beitrag geantwortet habe:
Beim klassischen BIOS-Boot kann ein Fehler in der MBR das System unbenutzbar machen. Man muss dann erst umständlich per Rettungsmedium den MBR wiederherstellen.
Bei UEFI ist das kein Problem:
Solange die Firmware eine UEFI-Shell eingebaut hat, kann man die Bootloader direkt darüber starten.
Ja, aber auch nur dann. Ansonsten ist man nämlich wieder mit einem Rettungssystem beschäftigt, um den NVRAM-Eintrag im UEFI zu reparieren. IMHO ziemlich doof und nicht zu Ende gedacht, dass UEFI zwar vorhandene EFI-Bootloader auf externen Datenträgern automatisch erkennt und zum Booten anbietet, aber bei internen Datenträgern versagt.
Bei ASRock-Boards befindet sich beispielsweise keine EFI-Shell in der UEFI-Firmware. Diese muss man manuell in die EFI-System Partition installieren, um sie nutzen zu können. Die EFI-Shell kann man sich hier herunterladen und unter dem Namen shellx64.efi nach /boot/efi/ ablegen. Dann kann man von der ASRock UEFI-Firmware aus über "Exit > Launch EFI Shell from filesystem device" auch die Shell starten. In der EFI-Shell angekommen, kann man Grub folgendermassen starten:
fs0: cd \EFI\debian grubx64.efi
Um dann den NVRAM-Eintrag zu reparieren, kann man unter Linux efibootmgr verwenden, z.B.:
Man muss im Vorfeld schon richtig Arbeit investieren, um im Fehlerfall einen Vorteil durch UEFI zu haben und ohne Rettungssystem auszukommen. Ob letztlich der Vorteil wirklich noch überwiegt, kann dann schon fraglich sein.
Für mich liegt der Vorteil von UEFI deshalb eher darin, eine klar strukturierte Bootstruktur zu haben (die mit alten Zöpfen und zerhackten, wild verteilten Bootloader-Teilen aufräumt), wo der Bootloader vollständig in einer Datei steckt und sich somit einfach in einem Backup abbilden lässt. Zumindest fast - denn der zwingend erforderliche NVRAM-Eintrag trübt das Gesamtbild.
Wenn man die EFI-Shell vorher installiert hat, sicher. Das wird nur oftmals nicht der Fall sein. Und dann schadet es nicht, vom efibootmgr gehört zu haben.
bcfg braucht eine v2 Shell, also bei mir funktioniert die nicht, trotz nagelneuem ASRock B85M Pro4 Mainboard welches wohl UEFI 2.3 unterstützen muss, da es auch Secure Boot kann.
Die modifizierte v2 Shell welche auch auf der Seite verlinkt ist, funktioniert hingegen. Die Frage ist nur, ob ich ein unbekanntes Binary aus der Dropbox auf meiner EFI-Systempartition haben möchte...
@Ein-Byte-Boot-Flag ich vermute es ist der 55aa marker in jedem bootsektor gemeint, um vom bios als gültig bootsektor erkannt zu werden.
ausserdem haben etliche (alle?) distributionen von cdrecord/mkisofs wg. lizenz-streitigkeiten mit jörg schilling auf cdrkit/genisoimage bzw. dvd+rw-tools/growisofs umgestellt.
"Aus historischen Gründen nutzen Linux-Distributionen für den BIOS-Boot den Bootloader Isolinux/Syslinux." pffff.... was für historische gründe? ich vermute die aussage bezieht sich darauf, dass "boot-select" menü im uefi etliche bootloader überflüssigt macht. w98 hats auch nicht anderes gemacht: emuliertes floppy-image, bei w2k hatte schon "no emulation" IIRC.
der artikel wirft mit machen dingen wild um sich...
Umständlich? Ein einfaches dd des gesichterten MBR-Images zurück auf den Datenträger. Suse hatte mal soetwas per default bei der Installation erstellt...
... hat das Booten damit einen Riesenvorteil:
Beim klassischen BIOS-Boot kann ein Fehler in der MBR das System unbenutzbar machen. Man muss dann erst umständlich per Rettungsmedium den MBR wiederherstellen.
Bei UEFI ist das kein Problem:
Solange die Firmware eine UEFI-Shell eingebaut hat, kann man die Bootloader direkt darüber starten.
Ein zweiter Vorteil ist, dass sich die einzelnen Betriebssysteme nicht mehr ins Gehege kommen. Leider überschreibt Windows standardmäßig immer den Standardloader im UEFI-Bootmenü (Sprich es mogelt sich immer zum Standard). Wer Grub2 zum Standard erheben will, muss unter Windows in einer Admin-Shell folgendes Kommando eingeben:
bcdedit /set {bootmgr} "\EFI\ubuntu\shimx64.efi" (Für SecureBoot unter Ubuntu)
bcdedit /set {bootmgr} "\EFI\ubuntu\grubx64.efi" (Ohne Secureboot unter Ubuntu)
Andere Distributionen müssen nur den Pfad anpassen.
Der Artikel ist aber etwas durcheinander geraten oder habe nur ich den Eindruck?
So bootet der PC durch UEFI nicht automatisch merkbar schneller, das ist allenfalls der Implementierung des Mainboards geschuldet, aber nicht die Regel.
Der Hinweis "es ist einfacher, Systeme parallel zu installieren" macht nur bei internen Datenträgern Sinn, dann passt aber "Aus historischen Gründen nutzen Linux-Distributionen für den BIOS-Boot den Bootloader Isolinux/Syslinux." nicht, was sich nur auf externe Datenträger beziehen kann.
Auch den Hinweis mit dem Boot-Flag halte ich für ein Gerücht, das war allenfalls ein Fehler in der einen oder anderen BIOS-Implementierung.
"Startfähige USB-Sticks oder Speicherkarten für den UEFI-Boot sind deshalb auch ohne spezielle Werkzeuge schnell erstellt:" dd fällt wohl kaum unter spezielles Werkzeug, zumindest nicht mehr als mc oder cp Und mehr braucht es nicht um eine Linux-Installations-CD auf einen USB-Stick zu kopieren, egal ob BIOS oder UEFI-Boot.
Aber warum ich eigentlich auf deinen Beitrag geantwortet habe:
Ja, aber auch nur dann. Ansonsten ist man nämlich wieder mit einem Rettungssystem beschäftigt, um den NVRAM-Eintrag im UEFI zu reparieren. IMHO ziemlich doof und nicht zu Ende gedacht, dass UEFI zwar vorhandene EFI-Bootloader auf externen Datenträgern automatisch erkennt und zum Booten anbietet, aber bei internen Datenträgern versagt.
Bei ASRock-Boards befindet sich beispielsweise keine EFI-Shell in der UEFI-Firmware. Diese muss man manuell in die EFI-System Partition installieren, um sie nutzen zu können. Die EFI-Shell kann man sich hier herunterladen und unter dem Namen shellx64.efi nach /boot/efi/ ablegen. Dann kann man von der ASRock UEFI-Firmware aus über "Exit > Launch EFI Shell from filesystem device" auch die Shell starten. In der EFI-Shell angekommen, kann man Grub folgendermassen starten:
fs0:
cd \EFI\debian
grubx64.efi
Um dann den NVRAM-Eintrag zu reparieren, kann man unter Linux efibootmgr verwenden, z.B.:
efibootmgr --create --disk /dev/sda --part 1 --label debian --loader \\EFI\\debian\\grubx64.efi
Man muss im Vorfeld schon richtig Arbeit investieren, um im Fehlerfall einen Vorteil durch UEFI zu haben und ohne Rettungssystem auszukommen. Ob letztlich der Vorteil wirklich noch überwiegt, kann dann schon fraglich sein.
Für mich liegt der Vorteil von UEFI deshalb eher darin, eine klar strukturierte Bootstruktur zu haben (die mit alten Zöpfen und zerhackten, wild verteilten Bootloader-Teilen aufräumt), wo der Bootloader vollständig in einer Datei steckt und sich somit einfach in einem Backup abbilden lässt. Zumindest fast - denn der zwingend erforderliche NVRAM-Eintrag trübt das Gesamtbild.
Wenn man die EFI-Shell vorher installiert hat, sicher. Das wird nur oftmals nicht der Fall sein. Und dann schadet es nicht, vom efibootmgr gehört zu haben.
Da hast du auch wieder recht.
Ich habe beim Suchen nach einer aktuelleren UEFI-Shell als meiner vorinstallierten einen netten Wiki-Eintrag bei ArchLinux gefunden:
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#bcfg
Man kann über das Kommando "bcfg" direkt in der Shell die Bootmenüeinträge hinzufügen. Ein Booten von Linux ist nicht notwendig.
bcfg braucht eine v2 Shell, also bei mir funktioniert die nicht, trotz nagelneuem ASRock B85M Pro4 Mainboard welches wohl UEFI 2.3 unterstützen muss, da es auch Secure Boot kann.
Die modifizierte v2 Shell welche auch auf der Seite verlinkt ist, funktioniert hingegen. Die Frage ist nur, ob ich ein unbekanntes Binary aus der Dropbox auf meiner EFI-Systempartition haben möchte...
@Ein-Byte-Boot-Flag
ich vermute es ist der 55aa marker in jedem bootsektor gemeint, um vom bios als gültig bootsektor erkannt zu werden.
ausserdem haben etliche (alle?) distributionen von cdrecord/mkisofs wg. lizenz-streitigkeiten mit jörg schilling auf cdrkit/genisoimage bzw. dvd+rw-tools/growisofs umgestellt.
"Aus historischen Gründen nutzen Linux-Distributionen für den BIOS-Boot den Bootloader Isolinux/Syslinux." pffff.... was für historische gründe?
ich vermute die aussage bezieht sich darauf, dass "boot-select" menü im uefi etliche bootloader überflüssigt macht. w98 hats auch nicht anderes gemacht: emuliertes floppy-image, bei w2k hatte schon "no emulation" IIRC.
der artikel wirft mit machen dingen wild um sich...
Umständlich? Ein einfaches dd des gesichterten MBR-Images zurück auf den Datenträger.
Suse hatte mal soetwas per default bei der Installation erstellt...
Am besten jedes Betriebssystem auf seine eigene Festplatte, SSD oder USB-Datenträger installieren, dann kommen die sich nicht ins Gehege.
Das Optische Laufwerk muss auch in den UEFI Modus gesetzt werden, sonst macht man nur eine "Schatten-Installation" *g*
Ja, das merkt man dann wenn man 1 Stunde für die Katz installierte und sich dann dumm fragt, warum der erste Reboot nicht anläuft