Nicht Ubuntu, sondern UEFI. Erst seit dem es diesen Dreck gibt, gibt es solche Probleme. BIOS war da eine readonly Geschichte, die das System hochgezogen hat (OK, mit ganz wenigen Ausnahmen). Bei UEFI gibt es heftigstes Interaktionen, wo das OS ins UEFI schreiben soll. Wenn das System crasht, dann geht der Dump ins UEFI, die Platte könnte ja schon abgehängt sein.
Alles schön und gut. Das Problem ist, es ist ein Misthaufen und es gibt auch nicht die geringste Motivation, daran etwas zu ändern. Ich schiebe eine DVD, die nicht irgendwelche Exploids ausnutzt, in den Rechner und der Rechner ist fertig. So etwas kann einfach nicht sein. Wenn das alles ist, was Intel gebacken bekommt. Sorry, in dem Bereich muss eine Alternative her.
Und die Windowskloppertruppe ist auch schon wieder aktiv. Hei danket Linux. Dank Linux wurde dieser Misthaufen erst sichtbar.
Ein Dual-BIOS sollte Pflicht sein für jeden, der seinen Rechner ernsthaft braucht. Wer das nicht anbietet, kommt mir nicht mehr ins Haus. Wo war jetzt gleich noch mal der Vorteil von UEFI? Ich kenne keinen. Man sagte damals, man braucht es, für Festplatten größer 4TB oder sowas. Weil da kein gpt geht. Das bezog sich aber nur auf Windows. Linux konnte gpt mit BIOS. Aber gibt ja nur noch Boards mit UEFI.
Von schmidicom am Fr, 22. Dezember 2017 um 08:29 #
Nur zur Info: Dieses Problem ist ein kein UEFI spezifisches Problem. Hier hat anscheinend der MTD-Treiber "intel-spi" nicht richtig funktioniert, oder er hat richtig funktionier dafür aber die Hardware nicht, und so wurde der Speicherbereich wo das UEFI liegt "verändert". Das hätte auch ein klassisches BIOS nicht überlebt.
Es gibt gute Gründe UEFI (oder eher das was Microsoft mit seinem Einfluss bei www.uefi.org draus gemacht hat) zu kritisieren aber das hier ist keiner.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 22. Dez 2017 um 08:36.
Bei einem brauchbaren BIOS/UEFI darf so ein Fall erst gar nicht auftreten, dass beliebige Software das UEFI irreparabel schrotten kann. Wer so was per Design erlaubt, der hat einfach nur Mist gebaut. Und zu Zeiten von BIOS, also vor UEFI, habe ich nicht einmal von so einem Problem gehört, dass das Starten einer Software, die nicht explizit als Schadschoftware gedacht war, ein System geschrottet hat. Früher gab es ja mal so was wie Jumper, mit denen man das BIOS schreibschützen konnte. Aber wer braucht schon Sicherheit?
Wenn man über so einen Treiber das UEFI beliebig manipulieren kann, dann hat man da doch traumhaft einen Virus unterbringen. Ja, ein System, welches das per Design erlaubt, das nenne ich einen geisteskranken Haufen Scheiße.
Von schmidicom am Fr, 22. Dezember 2017 um 12:01 #
Mag ja alles stimmen, ändert aber nichts daran das zumindest in diesem speziellen Fall UEFI keine Schuld trifft. Wenn bereits die Hardware eine kaputte Hintertür hat (bei dessen normalen Benutzung gleich das halbe Haus einstürzt), spielt es keine Rolle mehr ob das ganze mit einem BIOS oder UEFI ausgestattet ist.
Nicht Ubuntu, sondern UEFI. Erst seit dem es diesen Dreck gibt, gibt es solche Probleme. BIOS war da eine readonly Geschichte, die das System hochgezogen hat (OK, mit ganz wenigen Ausnahmen). Bei UEFI gibt es heftigstes Interaktionen, wo das OS ins UEFI schreiben soll. Wenn das System crasht, dann geht der Dump ins UEFI, die Platte könnte ja schon abgehängt sein.
Alles schön und gut. Das Problem ist, es ist ein Misthaufen und es gibt auch nicht die geringste Motivation, daran etwas zu ändern. Ich schiebe eine DVD, die nicht irgendwelche Exploids ausnutzt, in den Rechner und der Rechner ist fertig. So etwas kann einfach nicht sein. Wenn das alles ist, was Intel gebacken bekommt. Sorry, in dem Bereich muss eine Alternative her.
Und die Windowskloppertruppe ist auch schon wieder aktiv. Hei danket Linux. Dank Linux wurde dieser Misthaufen erst sichtbar.
Ein Dual-BIOS sollte Pflicht sein für jeden, der seinen Rechner ernsthaft braucht. Wer das nicht anbietet, kommt mir nicht mehr ins Haus. Wo war jetzt gleich noch mal der Vorteil von UEFI? Ich kenne keinen. Man sagte damals, man braucht es, für Festplatten größer 4TB oder sowas. Weil da kein gpt geht. Das bezog sich aber nur auf Windows. Linux konnte gpt mit BIOS. Aber gibt ja nur noch Boards mit UEFI.
Nur zur Info: Dieses Problem ist ein kein UEFI spezifisches Problem.
Hier hat anscheinend der MTD-Treiber "intel-spi" nicht richtig funktioniert, oder er hat richtig funktionier dafür aber die Hardware nicht, und so wurde der Speicherbereich wo das UEFI liegt "verändert". Das hätte auch ein klassisches BIOS nicht überlebt.
Es gibt gute Gründe UEFI (oder eher das was Microsoft mit seinem Einfluss bei www.uefi.org draus gemacht hat) zu kritisieren aber das hier ist keiner.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 22. Dez 2017 um 08:36.Bei einem brauchbaren BIOS/UEFI darf so ein Fall erst gar nicht auftreten, dass beliebige Software das UEFI irreparabel schrotten kann. Wer so was per Design erlaubt, der hat einfach nur Mist gebaut. Und zu Zeiten von BIOS, also vor UEFI, habe ich nicht einmal von so einem Problem gehört, dass das Starten einer Software, die nicht explizit als Schadschoftware gedacht war, ein System geschrottet hat. Früher gab es ja mal so was wie Jumper, mit denen man das BIOS schreibschützen konnte. Aber wer braucht schon Sicherheit?
Wenn man über so einen Treiber das UEFI beliebig manipulieren kann, dann hat man da doch traumhaft einen Virus unterbringen. Ja, ein System, welches das per Design erlaubt, das nenne ich einen geisteskranken Haufen Scheiße.
Mag ja alles stimmen, ändert aber nichts daran das zumindest in diesem speziellen Fall UEFI keine Schuld trifft. Wenn bereits die Hardware eine kaputte Hintertür hat (bei dessen normalen Benutzung gleich das halbe Haus einstürzt), spielt es keine Rolle mehr ob das ganze mit einem BIOS oder UEFI ausgestattet ist.
Ach vergiss es. Es freut mich, dass es Personen gibt, die sich kaputte Systeme wünschen. Mehr fällt mir dazu nicht mehr ein.
Ach vergiss es. Es freut mich, dass es Personen gibt, die sich kaputte Systeme wünschen. Mehr fällt mir dazu nicht mehr ein.