Warum verketten die meisten Distributionen UEFI und Grub?

Die meisten Distributionen installieren einen zusätzlichen Bootloader auf einem UEFI-System. UEFI selbst ist ein Bootloader und bietet ein Menü zur Auswahl verschiedener Betriebssysteme oder einzelner Kernel. Darüber hinaus können die UEFI-Einstellungen leicht mit User-Space-Tools wie geändert werden efibootmgr.

Kernel seit 3.3 unterstützen EFI_STUB, was bedeutet, dass der Kernel direkt von der UEFI geladen werden kann. Aus welchem ​​Grund entscheiden sich Distributionen für die Verwendung eines zusätzlichen Bootloaders? Die meisten Tutorials zu Linux / UEFI befassen sich hauptsächlich mit der Einrichtung des zusätzlichen Bootloaders (rEFInd, grub2, ELILO usw.), anstatt Linux mit EFI_STUB zu booten.

Das einzige, was in den Distributionen fehlt, ist die Unterstützung. Da die meisten Distributionen einen zweiten Bootloader verketten, wird der Kernel weder zum UEFI-Bootmenü hinzugefügt noch in die EFI-Systempartition kopiert.

Drei Skripte reichen aus, um die ganze Magie zu vollbringen. Eine, die die initramfs in den ESP kopiert. Ein zweiter kopiert den Kernel auf den ESP und erstellt einen neuen Eintrag im UEFI-Startmenü. Das dritte Skript entfernt den alten Kernel und initramfs vom ESP und löscht den Eintrag im UEFI-Startmenü. Dies ermöglicht vollautomatisierte Kernel- / Initramfs-Updates / Bereinigungen ohne Benutzerinteraktion. Ich benutze diesen Ansatz seit mehr als einem Jahr und er hat einwandfrei funktioniert.

Warum verwenden die meisten Distributionen grub anstelle von EFI_STUB?

Links:

• Wie erstelle ich eine EFI-Bootpartition neu?

EDIT: Ich spreche nicht davon, die Grub-Unterstützung vollständig zu entfernen, sondern eine Auswahl für diejenigen anzubieten, die sie aus verschiedenen Gründen verwenden möchten. Distributionen könnten ein Paket grub-efifür diejenigen bereitstellen , die UEFI und Grub verketten möchten, sowie ein Paket, efistub-bootdas die oben erwähnten Skripte enthält.

Angesichts der Tatsache, dass UEFI erst 2005 definiert wurde, gibt es eine Reihe älterer Geräte, die die Spezifikation nicht unterstützen. Das Hinzufügen von UEFI zu einer Standarddistribution erfordert das Testen von zwei statt nur einem Codepfad. Der Startcode ist nicht nur notorisch pingelig, sondern auch einer der irritierendsten und zeitaufwändigsten zu testenden Codebits.

Distros verfügen nur über begrenzte Ressourcen, und darüber hinaus gibt es möglicherweise keinerlei Gründe. Es mag einigermaßen einfach und sicher sein, aber egal, was für Wartungsarbeiten erforderlich sind, da die Grub-Option nur für Nicht-UEFI-Systeme beibehalten werden muss.

Ich bin mir sicher, dass jeder eine Liste von Funktionen und Optionen hat, die er gerne von Distributionen übernehmen lassen möchte (ich gebe Ihnen ein paar Seiten, lol), und zweifellos wären viele davon "ganz einfach, kein Ärger, ehrlich. .. ". Es gibt jedoch nicht unendlich viele Arbeitsstunden, um sie umzusetzen. Bei Entscheidungen wie diesen ("Arbeiten wir an dieser Funktion im Vergleich zu anderen?") Sollten die Hauptfragen lauten:

• Ist es nötig? (Die Antwort hier ist nein).
• Wie viele Menschen werden davon profitieren und wie viel? (IMO: ein paar und nicht viel)
• Gibt es eine sinnvolle Alternative, über die sich der Benutzer anpassen kann, ohne dass wir etwas unternehmen? (Anscheinend gibt es.)

Der Grund, warum die Leute Distros überhaupt benutzen, ist, dass jeder mit begrenzten Ressourcen konfrontiert ist (andernfalls stellen Sie einfach ein Team ein, kaufen Sie ihnen Platz und Ausrüstung und lassen Sie alles für Sie tun, genau wie Sie wollen). Die Realität ist also, dass die Distributionen die allgemeinen Bedürfnisse ihrer Benutzer widerspiegeln .

Trotzdem denke ich, dass dies mit der Zeit als Option angenommen wird, und habe die Frage positiv bewertet.

Das gezielte Anvisieren von UEFI-Bootloadern zusätzlich zu Grub würde die Qualitätskontrolle und -unterstützung erschweren. Die Distributionen zielen eher auf Grub als auf die UEFI-Spezifikation ab, da Grub freie Software, hackbar, flexibler und von hoher Qualität ist. Sie können dennoch einen reinen UEFI-Start erhalten, indem Sie einem Lernprogramm folgen und die UEFI-Partition anhängen. Andernfalls /bootliegt die Wartung bei Ihnen.

Das eigentliche Problem ist, dass die Leute nicht verstehen, wie es funktioniert. Zum Beispiel erwähnen Sie in Ihrer Frage, dass nur drei Skripte erforderlich sind, und die meisten Antworten hier beziehen sich auf alle / jede zusätzliche Wartung, die erforderlich wäre, damit es funktioniert - aber die Wahrheit ist, dass Sie diese Skripte nicht benötigen oder zusätzliche Arbeit.

Alles, was Sie brauchen, ist das Binden des ESP - oder wo immer Sie den Kernel behalten möchten - /boot, was Sie mit einer einzelnen Zeile in tun können /etc/fstab. Wenn Sie dies tun, funktionieren alle aktuellen Kernel-Aktualisierungsskripten einfach weiter.

Meine `/ etc / fstab 'sieht so aus:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

Hier wird jedoch ein guter Punkt in Bezug auf herstellerspezifische Einstellungen angesprochen. UEFI gibt die Schnittstelle für ein Startmenü nicht explizit an . Das ist zu gewinnen und wird nicht zwischen Maschinen konsistent sein. Es ist nervig, aber wahr.

Und so, während ein Lader wie grubeigentlich nur für macht mehr Arbeit, ein Menü Anwendung - wie REFind - entzerrt die Unterschiede und vereinfacht alles.

Sie verketten UEFI und GRUB als temporäre Implementierungslösung.

Sobald der UEFI-Support und die damit verbundenen Probleme (z. B. Secure Boot) behoben sind, werden immer mehr Distributionen ihn direkt verwenden. In der Zwischenzeit ist dies noch sehr neu: Google Trends wird nur in begrenztem Umfang übernommen: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = q

Andere haben alle potenziellen Gefahren einer reinen UEFI-Lösung und / oder der gleichzeitigen Unterstützung von Nicht-UEFI- und reinen UEFI-Systemen erwähnt. Ein UEFI-Kernel funktioniert möglicherweise auf einem Nicht-UEFY-System, aber die Kernel-Aktualisierungstools müssen entweder ein GRUB-Menü ODER ein UEFI-Startmenü ODER beides usw. usw. aktualisieren.

Wie bereits erwähnt, geht es hier wirklich um die Qualitätskontrolle: Wichtig ist, dass Probleme mit diesem Code einen großen Einfluss haben: Wenn der Computer neue Benutzer nicht bootet, dh potenzielle Linux-Konverter, wird er als Müll entsorgt und auf etwas "Sicheres" zurückgegriffen.

Aber wie gesagt, wenn die Technologie mehr Akzeptanz findet, wird sie zum Standard.

Zusätzlicher Code ist erforderlich, um Firmware-Fehler zu umgehen

Wenn Sie grub nicht verketten, verlässt sich die Distribution mehr auf die Firmware, um richtig zu booten. Da jede Software Probleme hat, ist auch die Firmware dafür anfällig. Jetzt müssen die Linux-Distributionen auch schreiben, um diese Firmware-Fehler zu umgehen.

Ein realer Fall als Beispiel. Das Asrock H81 Pro BTC P1.80 Motherboard ermöglicht die Erstellung von Bootmenüeinträgen mit efibootmgr. Es können mehrere Startmenüeinträge erstellt werden, und die Startreihenfolge kann mithilfe von geändert efibootmgr --bootorder XXXX,YYYY,ZZZZoder eine temporäre Option für den nächsten Start mithilfe von festgelegt werden efibootmgr --bootnext XXXX. Beide Befehle geben eine Ausgabe zurück, die Ihnen den Eindruck vermittelt, dass sich die Startreihenfolge geändert hat oder der nächste Start beispielsweise ausgeführt wird BootNext: XXXX. Beim Neustart ignoriert die hartnäckige Firmware jedoch nur die neu angeforderte Startoption und führt einen Neustart mit dem vorherigen BootCurrent:Wert durch. Eine dauerhafte Änderung der Startreihenfolge kann nur über das Firmware-Setup-Dienstprogramm vorgenommen werden. Und eine nicht dauerhafte Änderung ist überhaupt nicht verfügbar.

Ich denke, wenn das Booten nur von EFI ausgehändigt wird und wir den Bootloader entfernen, wird es sowohl für HW-Hersteller als auch für Hersteller von Betriebssystemen schwierig sein. HW-Anbieter werden mehr Kernel zum Testen haben, während es für Unternehmen, die Betriebssysteme herstellen, so aussieht, als ob ihr Kernel von einer anderen FW geladen wird.

Außerdem beim direkten Booten des Kernels von EFI, wo im Stack passt der sichere Boot? Im aktuellen Szenario prüft der Bootloader, ob der Kernel korrekt signiert ist, sobald die Steuerung auf den Bootloader des Betriebssystems übergeht. Wenn wir den Kernel direkt von EFI laden, dann denke ich, dass es nur zu Chaos kommt, wenn der gesamte Stapel gestört wird. Nur eine Meinung von welchem ​​Verständnis ich habe.