Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen (Gelesen 1032 mal)
|
|
Sebastian
Sr. Member
 Offline
Einträge: 371
|
 |
Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« am: 27. August 2022, 07:07:05 »
|
|
Hallo liebe Suletuxe,
nur eine kleine Information, falls ihr nach dem 2022-08-25 noch nicht euer EndevourOS aktualisiert habt.
Das grub Paket grub 2:2.06.r322.gd9b4638c5-1 verursacht bei einigen UEFI System ein Fehler, dass nach der Installation der PC nicht mehr das Betriebssystem startet und stattdessen ihr in einer EFI Shell landet. Alle, die noch nicht upgedatet haben, wird empfohlen nach dem Installieren des Updates grub gleich neu zu installieren bevor man neu startet. Für alle bei denen es bereits zu spät ist und der PC schon nicht mehr startet, müssen ein Live ISO booten und grub neu installieren.
Achtung:
Gemeint ist die Neuinstallation von grub in die EFI Partition, nicht des grub Packages
Anleitungen dazu entnimmt bitte hier aus den News.
Wer an technische Details interessiert ist, wie dieser Fehler zustande kam, und wie in Zukunft damit umgegangen wird, ist dieser transparency Report von EndevourOS ans Herz gelegt.
Wer seine Updates künstlich verzögert, wie ich hier einmal beschrieben habe, bekommt das Problem erst später und hat jetzt noch genügend Zeit zum Reagieren.
Soll nicht heißen, dass eine Verzögerung von Updates grundsätzlich eine gute Idee ist, dafür gibt es wieder andere Probleme, bzw. andere Dinge zu beachten, sodass dies je nach Anwendungsfall unterschiedlich Sinn macht.
|
| « Letzte Änderung: 27. August 2022, 09:08:36 von Sebastian » |
 Gespeichert
|
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 371
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #1 am: 31. August 2022, 15:48:04 »
|
|
Es gab noch ein Update vom Grub Bootloader am 2022-08-30 (2:2.06.r322.gd9b4638c5-3) das je nach Hardware und Konfiguration ein boot verhindern kann.
Laut den Arch News wird auch hier nach dem Update des Grub Paktes, eine Neuinstallation vom Grub vor dem Neustarten empfohlen.
Eine Erinnerung stütze wie Grub installiert wird, ist aus dem News-Beitrag von Arch zu entnehmen, eine genauere Anleitung mit allen technischen Einzelheiten entnimmt bitte dem Arch Wiki
|
|
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #2 am: 01. September 2022, 04:47:24 »
|
|
Ich nutze nach wie vor kein EFI, und auch auf meinen Installationen verwende ich stets "Legacy Boot". Daher dürfte keiner meiner Installationen von dem Bug betroffen sein. Außer diesem Fehler sind bei EFI-Installationen in den unterschiedlichen EFI-Implementationen der Gerätehersteller eine Unmenge unterschiedlicher Bugs eingebaut, so dass ich EFI lediglich als einen Versuch Microsofts einstufe eine Installation von irgendwas anderem als Windows zu verhindern oder mindestens zu erschweren. Irgendwelche echten Vorteile sehe ich durch EFI nicht.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 371
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #3 am: 01. September 2022, 07:23:09 »
|
|
Zu den Bugs der unterschiedlichen EFI Implementierung der Gerätehersteller gebe ich dir recht. Leider halten sich viele Gerätehersteller nicht an den UEFI Standard
Aber inwiefern behindert bzw. erschwert der UEFI Standard eine Installation eines anderen Betriebssystems außer vom Microsoft Windows?
UEFI macht es doch grade einfacher, dass verschiedene Betriebssysteme koexistieren können. Bzw. genauer gesagt deren Bootloader. Mit dem klassischen MBR ist es doch nur möglich einen Bootloader zu haben, der dann die Unterstützung mitbringen muss die verschiedenen Betriebssysteme starten zu können. Auf einer EFI Partition hingegen kann man eine beliebe Anzahl von Bootloader liegen haben, die alle miteinander nichts zu tun haben müssen, und die man alle Einzelt im UEFI zum Starten zur Auswahl hat.
Damit ist auch das Problem per se, dass bei einer Multiinstallation (Linux, Windows) Windows den Linux Bootloader überschreibt, falls man Windows nach Linux installiert. Man stellt im UEFI einfach die Bootreihenfolge zurück auf den Linux Bootloader und fertig ist die Geschichte.
Kritisch sehe ich das ganze nur zusammen mit SecureBoot, das dem UEFI Standard mit angehört. Sollte dieses durch den Standard mal verpflichtend aktiviert bleiben müssen, so könnten nur noch signierte EFI Applikationen gestartet werden. Und Signieren darf bis jetzt, soweit ich weiß, nur Microsoft.
Ansonsten, solange SecureBoot eine Freiwillige Entscheidung bleibt, finde ich SecureBoot in manchen Umgebungen, wo eine Bootloader Manipulation ausgeschlossen werden muss, auch berechtigt.
Eine weitere Möglichkeit das UEFI bietet ist, dass dafür EFI Applikationen geschrieben werden können, die unabhängig eines Betriebssystems ausgeführt werden. Dies ist wahrscheinlich einer der Gründe, warum SecureBoot mit im UEFI Standard ist. Damit keine schädlichen EFI Applikationen ausgeführt werden.
Hier ein paar Beispiele, die es so gibt:
gdisk EFI application: Zum Partitionieren
Memtest86: Zum Arbeitsspeicher Testen
As MemTest86 V9 supports only the newer UEFI platform, older PCs without UEFI support would be unable to boot MemTest86. In order to run MemTest86, PCs with legacy BIOS platform must use the older V4 release of MemTest86. The download links for the V4 downloads are still provided for those that prefer to work with the V4 bootable images.
|
|
hier geht die Entwicklung klar Richtung EFI
Arch Linux Netboot:
Hier wäre vorstellbar, Netboot auf seine EFI Partition mit draufzulegen, um Arch über das Netzwerk neuinstallieren zu können.
Wer schlussendlich was davon brauch, steht natürlich wieder auf einem ganz anderen Blatt. Das ist je nach Fall wieder einmal unterschiedlich.
Ich persönlich benutze bei meinen Installationen nach Möglichkeit immer das EFI Partitionsschema, da eine nachträgliche Änderung der Partitionierung mit einem weiteren Aufwand verbunden ist. Bzw. da ich zusätzlich noch volle Festplatten Verschlüsslung einsetzte (samt Bootpartition mit Linux Kernel) wäre für mich ein nachträgliches Ändern mit noch mehr Aufwand verbunden. Und um nicht den Vorteil eines Rolling Release Distribution zu verspielen (nicht neu installieren zu müssen, wenn ich es mir einfach machen möchte) sorge ich da lieber vor.
Denn auf lange Sicht werden die Legacy Methoden irgendwann abgeschaltet werden. Bzw. es gibt, glaube ich, jetzt schon erste Mainboards ohne Legacy Mode, die nur noch im UEFI Mode laufen.
Es ist aber wie bei allem eine Sache des Bedarfs. Meine Motivation ist, den neuen Standard zu nutzen, um mich mit seinen Fallstricken und Tücken jetzt auseinander zu setzten. Ganz nach dem Motto, weil man es machen kann. 
Dabei spreche ich aber auch nur für mich. Beweggründe beim Lagacy Mode zu bleiben versuche ich natürlich auch nachzuvollziehen und stehe denen offen gegenüber.
|
| « Letzte Änderung: 01. September 2022, 07:45:48 von Sebastian » |
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #4 am: 01. September 2022, 18:02:15 »
|
|
Eben genau diese fehlerhaften (absichtlich - ich vermute "im Auftrag von Microsoft") Implementierungen lassen mich Abstand von (U)EFI nehmen. Sie sind ein Dorn im Auge der Nachhaltigkeit. Für viele dieser fehlerhaften Implementierungen hat es niemals Fixes im BIOS dafür gegeben. Diese Geräte sind alle topfit - bis auf die EFI-Fehler. BIOS-Updates gibt es nicht mehr. Wegschmeißen - wegen eines BIOS-Bugs, den man ganz einfach umgehen kann? Für mich ein "no-go". Schade dass memtest sich dem Mainstream anschließt. Aber die Version v4 tut auch was sie soll und war/ist ausgereift. Also bleibe ich bei der v4  .
Ich lasse mich von niemandem - egal wer - zum ignorieren von Nachhaltigkeit verführen - mit welchem Argument auch immer...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 371
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #5 am: 01. September 2022, 20:09:41 »
|
|
Die alten BIOS Geräte waren bzw. sind aber auch nicht immer fehlerfrei, und BIOS Updates haben die Mainboards auch höchstens 2-3 Jahre gesehen. Das Problem mit dem schlechten Update Versorgung ist leider nicht neu, das hat sich auch mit EFI nicht gebessert. Zum Glück hatte ich bis jetzt aber noch kein Board gehabt, wo das EFI so verbugt war, dass ich es nicht nutzen, bzw. es deswegen entsorgen musste.
Momentan habe ich sogar ein Notebook, wo mir das BIOS ein paar Problemchen macht. Dieses Notebook hat von mir eine SSD spendiert bekommen, und kann damit anscheint nicht so richtig mit umgehen. Nach einem Neustart findet das BIOS die SSD nicht mehr, nach einem kompletten Shutdown (power off) ist diese wieder da. Mit GPT kommt das BIOS auch nicht zurecht, selbst nicht mit zur Hilfenahme einer BIOS Boot Partition für GRUB. Es kommt wirklich nur mit dem Legacy MBR zurecht. Das BIOS ist von 2011, ist also schon ein paar Jährchen alt. Die Hardware ist aber allemal noch zu gebrauchen, da es früher ein Gaming Notebook war.
- 8 GB RAM
- 4 Kern CPU
- 2 Grafikkarten
- etc.
Also für Office noch vollkommen ausreichend. Gut dafür kann jetzt das BIOS nichts, das ich ihm Hardware, gebe die, es wahrscheinlich zu der damaligen Zeit vielleicht noch nicht mal gab.
Auf lange Sicht wird wohl keiner an EFI dran vorbeikommen. Hoffentlich macht in der Zwischenzeit auch hier die Open Source Szene fortschritte, so dass wir in Zukunft hoffentlich mit freien UEFIs versorgt sind
|
|
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #6 am: 02. September 2022, 04:26:29 »
|
|
Mit UEFI sieht es schlecht aus mit Open Source. UEFI ist gemacht worden damit nur "lizensierte" Betriebssysteme gebootet werden können. Deren "Lizenz" (Schlüssel) sind im Betriebssystemkern hinterlegt. Wenn die öffentlichen Schlüssel in diesen Betriebssystemen nicht zu einem der im UEFI fest hinterlegten privaten passen wird das Booten verweigert. Welche privaten Schlüssel ins UEFI kommen bestimmen und entscheiden die Hersteller. Es ist Teil des "Sicherherheitskonzeptes" dass niemand einfach so neue Schlüssel ins UEFI befördern kann. Dann könnten ja auch "unautorisierte" Betriebssysteme gebootet werden. Alles was nicht im UEFI hinterlegt ist kann damit ausgesperrt werden.
Ich kenne keine Malware die "von Null an bootet". Die setzen alle auf ein vorhandenes BS auf (vorrangig Windows). Damit ist dieses "Sicherheitsfeature" ein "Linux-und-BSE-Verhinderungsmechanismus". Es gibt auch etliche Geräte (ich hatte schon viele in meiner Werkstatt) bei denen konnte man das "U" (secured boot) nicht abschalten. Auf denen konnte man dann bestenfalls Ubuntu nutzen. Das kommt ja inzwischen aus dem Hause Microsoft und hat natürlich einen eigenen Schlüssel im UEFI. Die meisten anderen Distros haben das nicht und ein selbstgebauter Kernel schon gar nicht. Die meisten Tablets z.B. können nur "secured boot". Schade. So kann man höchstns Ubuntu nutzen - um das mache ich aber gerade einen großen Bogen (wegen der für mich unerwünschten Einflüsse).
Und klar gibt es auch in BIOsen Bugs! Aber die in UEFI-Systemen sind massiv weiter verbreitet und stören häufig nur Linux. Ich sehe solche Geräte praktisch täglich in meiner Werkstatt, und ich besitze auch zwei - beide (zufälligerweise) aus dem Hause "ASUS". Mir ist es mit hohem Aufwand gelungen diese Geräte auf Legacy umzustellen obwohl sie keine Möglichkeit in der Oberfläche des BIOS haben. Der Trick erfordert ein teilweises Recerse Engineering der Firmware mit setzen eines Bits an einer ganz bestimmten Stelle. Gilt nur für dieses eine BIOS und diese eine Version.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 371
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #7 am: 10. September 2022, 20:50:36 »
|
|
Das SecureBoot Dilemma
Microsoft nutzt seine Marktmacht im Bereich von UEFI SecureBoot aus. Es wird Zeit für eine alternative Implementierung. Lesezeit: 3 Minuten
|
|
@Andreas der Artikel hätte von dir kommen können
Hier ein kleiner Auszug aus dem Artikel
Dies führte unter anderem dazu, dass auf aktuellen Geräten, beispielsweise von Lenovo, seit einiger Zeit standardmässig nur noch, die Microsoft Signaturen akzeptiert werden und im UEFI-BIOS zunächst sogenannte 3rd-Party-Zertifikate zugelassen werden müssen. Dabei handelt es sich um eine weitere Einschränkung, die ausschliesslich dazu dient, die Marktmacht von Microsoft weiter zu stärken und die Installation von alternativen Betriebssystemen wie GNU/Linux zu erschweren; unter dem Deckmantel der Sicherheit
|
|
Hoffentlich kommt es nie dazu, dass man selbst keine eigenen Zertifikate mehr hinterlegen kann. Solange einem die Freiheit noch bleibt, finde ich Secureboot nicht schlecht, um die Sicherheitskette einer vollständigen Festplattenverschlüsselung auf dem Bootloader auszudehnen.
|
|
Gespeichert
|
|
|
|
Andreas
Administrator
Offline
Einträge: 1140
Linux von Innen
|
|
Re:Grub-Update verursacht nicht bootfähiges Betriebssystem auf UEFI-Systemen
« Antwort #8 am: 11. September 2022, 05:42:03 »
|
|
Das ist aber das Ziel von Microsoft Sebastian. Sie haben Zeit. Erst müssen die Leute murrend hinnehmen dass Neugeräte immer seltener den Legacy-Boot unterstützen. Wenn dann überall EFI eingeführt ist kann man nach und nach den Secure-Boot nicht mehr abschalten und dann wird auch die Möglichkeit beseitigt dass man eigene Zertifikate hinterlegen kann. Das Argument kann ich Dir jetzt schon sagen: "Wir haben eine wichtige Sicherheitslücke beseitigt: Bis dato konnten Schadprogramme Zertifikate ins Gerät schmuggeln und so konnte dann unbemerkt Schadsoftware gebootet werden. Diese schwere Sicherheitslücke ist nun geschlossen." Und die Windows-Welt wird applaudieren...
Dass Microsoft mit der "Übernahme" von Canonical einen erheblichen Einfluss auf die Linux-Welt bekommen hat (in Form von Ubuntu und all seinen Ablegern wie Linux Mint mit Nummer) ist auch kein Zufall. Die Vergangenheit gezeigt dass kommerzielle Unternehmen aggressiv und expansiv sind. Das ist aber auch kein Zufall und natürlich: unsere Wirtschaft baut auf Wachstum und Steigerung.
Linux mit seinen Möglichkeiten steht in einer Vorreiterposition / Aussenseiterposition und kann und wird attackiert werden. Durch Fakenews, aber auch durch Firmware und Hardware.
Trotzdem ist die Linux-Gemeinde produktiv ohne Ende. Ich habe jetzt auf einem "Microsoft Surface Tablet" ein voll funktionsfähiges Arch (Endeavour) installiert und alles funktioniert. WIFI, Bluetooth, Sound, HDMI-Ausgabe, Full-HD-Support, beide Kameras, der Touchscreen und das LTE-Modem. Da haben viele Leute viel Reverse Engineering betrieben. Und der der installiert muss auch viel Handarbeit machen. Aber mit einer guten Vorwissen über die Zusammenhänge geht sogar die automatische Bildschirmausrichtung und das Onscreen-Keyboard - unter der Plasma Oberfläche...
LG
Andreas
|
| « Letzte Änderung: 11. September 2022, 05:45:29 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
