Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Mit UEFI statt BIOS booten

11 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von glasen am Di, 18. August 2015 um 14:38 #

... 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.

  • 1
    Von 1ras am Di, 18. August 2015 um 19:33 #

    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.:

      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.

    • 0
      Von glasen am Di, 18. August 2015 um 19:57 #

      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

      So kompliziert muss man es gar nicht erst machen. Es reicht vollkommen "grub-install" aufzurufen Dadurch wird der fehlende Eintrag wieder erstellt.

      Zumindest fast - denn der zwingend erforderliche NVRAM-Eintrag trübt das Gesamtbild.
      Das ist leider wirklich ein Nachteil. Aber wie schon geschrieben, mit einer UEFI-Shell und "grub-install" ist das System ruckzuck wieder hergestellt.

      • 0
        Von 1ras am Di, 18. August 2015 um 21:20 #

        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.

        • 0
          Von glasen am Mi, 19. August 2015 um 12:53 #

          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.

          • 0
            Von 1ras am Fr, 21. August 2015 um 19:06 #

            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...

      0
      Von wtf!? am Mi, 19. August 2015 um 18:58 #

      @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...

    0
    Von blubbermal am Mi, 19. August 2015 um 10:34 #

    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...

1
Von Cincinatus am Di, 18. August 2015 um 15:29 #

Am besten jedes Betriebssystem auf seine eigene Festplatte, SSD oder USB-Datenträger installieren, dann kommen die sich nicht ins Gehege.

1
Von haha am Di, 18. August 2015 um 15:47 #

Das Optische Laufwerk muss auch in den UEFI Modus gesetzt werden, sonst macht man nur eine "Schatten-Installation" *g*

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung