apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
Ali_As schrieb: Konkret geht es um "CSM", bzw. die Gleichsetzung von CSM und BIOS.
Ja, es ist nicht richtig, wenn man CSM und BIOS gleichsetzt.
Meiner Erfahrung mit etlichen Set-Ups/UEFIs nach, stellt die Option CSM (oft/meist) verschiedene Bootmodi zur Verfügung auf einem UEFI-Board. Das kann neben Legacy aber eben auch UEFI-Boot in der einen oder anderen Priorität sein!
Nein, CSM stellt keine Bootmodi zur Verfügung. Um BIOS-Systeme zu booten, verwendet das UEFI einen zusätzlichen Layer, nämlich das CSM. Der WIKI-Artikel beinhaltet dies aber nicht bzw. ist auch schon etwas veraltet. So findet sich hier die Formulierung Im CSM-Modus verhält sich das System - was Start und Installation anbelangt - dann so, wie man es von einem reinen BIOS-System gewohnt ist.
Was ist daran falsch? Aus den genannten Gründen stimmt das so eben nicht (mehr). Selbst der nebenstehende Screenshot zur Dokumentation verrät dies schon, da die nicht geöffnete Option "Boot Option Filter" schon UEFI und Legacy unter CSM bereit hält.
Du interpretierst den Screenshot falsch. "Launch CSM" bedeutet meiner Meinung nach, dass beim Firmwarestart auch das CSM geladen werden soll. "Boot option filter" stellt ein, ob neben den UEFI- auch BIOS-Installationen bei den auswählbaren Bootmedien erscheinen sollen (Funktionalität von UEFI). Des Weiteren muss zwingend die Formulierung
Unter den Systemherstellern herrscht bisher keine Einigkeit in Bezug auf das Boot-Verhalten von UEFI-Firmware. Viele Systeme werden deshalb im Nicht-UEFI-Modus ausgeliefert, laden also grundsätzlich das Compatibility Support Module. Das sollte man vor einer Installation immer abklären.
aktualisiert werden, da mittlerweile so gut wie keine Systeme mehr mit Legacy ausgeliefert werden, aus den bekannten Gründen.
Ob die Änderung wirklich zwingend ist, weiss ich nicht, aber ja, das könnte man aktualisieren. Man könnte auch noch darüber diskutieren, ob hier ein Hinweis bzgl. der (CSM)Bootoptionen "both" und "first" angebracht ist, diese möglichst zu meiden/abzustellen, da sie meiner Erfahrung nach nur Unheil anrichten (z.B. bei einem nicht für UEFI eingerichteten Installationsstick).
Vorschlag?
|
Ali_As
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4665
|
Hallo!
Nein, CSM stellt keine Bootmodi zur Verfügung. Um BIOS-Systeme zu booten, verwendet das UEFI einen zusätzlichen Layer, nämlich das CSM.
D'accord, aber letztlich meinen wir das Gleiche!
Was ist daran falsch?
Das hatte ich weiter vorne erklärt oder siehe folgende!
Du interpretierst den Screenshot falsch. "Launch CSM" bedeutet meiner Meinung nach, dass beim Firmwarestart auch das CSM geladen werden soll.
Ja und? Fakt ist, dass CSM neben Legacy auch oft UEFI und hybride Modi bereit hält. Und somit CSM nicht gleich Legacy. bzw. MBR/BIOS-Booting zu setzen ist. Ich hab sogar schon Rechner gehabt, die Legacy nicht als Modus unter CSM hatten, sondern daneben. Meiner Erfahrung nach kann CSM alles beinhalten außer UEFI mit Secureboot. Zur Verdeutlichung weiter unten Screenshots von einem gebräuchlichen Asus UEFI (PC).
Ob die Änderung wirklich zwingend ist, weiss ich nicht,
So so, du weißt also nicht, dass seit etwa 6 Jahren (fast) nur noch Rechner mit UEFI-Boot-Modus ausgeliefert werden....!? Wobei natürlich zu klären wäre, was Laura seinerzeit mit "viele Systeme" gemeint hat. Noch mal! Es geht letztlich nur darum dem Leser klar zu machen, dass "CSM" kein einheitlicher Begriff ist, sondern vielfältig verwendet wird/werden kann. Und wenn man sich auf unser WIKI beruft, sollte das imho schon entsprechend dargestellt sein.
Vorschlag?
Ein Bsp. hatte ich genannt. Es geht mir um Pro oder Contra der hybriden Modi. Meine Meinung siehe oben! Deine Meinung? L.G.
- Bilder
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
Ali_As schrieb: Hallo!
Nein, CSM stellt keine Bootmodi zur Verfügung. Um BIOS-Systeme zu booten, verwendet das UEFI einen zusätzlichen Layer, nämlich das CSM.
D'accord, aber letztlich meinen wir das Gleiche!
Nein, meinen wir nicht. Ich meine mit CSM das Compatibility Support Module. Du meinst mit CSM "irgendetwas". Was ist daran falsch?
Das hatte ich weiter vorne erklärt oder siehe folgende!
Ich verstehe die Erklärungen nicht. Weder weiter vorne noch die folgende. Du interpretierst den Screenshot falsch. "Launch CSM" bedeutet meiner Meinung nach, dass beim Firmwarestart auch das CSM geladen werden soll.
Ja und? Fakt ist, dass CSM neben Legacy auch oft UEFI und hybride Modi bereit hält.
Nein, das ist kein Fakt. CSM hält keine Bootmodi bereit. Das UEFI ist fürs Booten der Betriebssysteme verantwortlich. Und die meisten UEFIs haben CSM eingebaut, um auch Betriebssysteme im BIOS-Modus booten zu können. Ich weiss auch nicht, was du mit "hybridem Modus" meinst. Du kannst kein BIOS-System im UEFI-Modus booten. Und auch das UEFI-System kann nicht im BIOS-Modus gebootet werden. Entweder wird ein System im BIOS- oder im UEFI-Modus gebootet. Ich hab sogar schon Rechner gehabt, die Legacy nicht als Modus unter CSM hatten, sondern daneben.
Was wo grafisch wie dargestellt wird, spielt keine Rolle. Und wie willst du CSM optisch darstellen? Meiner Erfahrung nach kann CSM alles beinhalten außer UEFI mit Secureboot. Zur Verdeutlichung weiter unten Screenshots von einem gebräuchlichen Asus UEFI (PC).
CSM ist ein Layer, ein Modul im UEFI. Ob die Änderung wirklich zwingend ist, weiss ich nicht,
So so, du weißt also nicht, dass seit etwa 6 Jahren (fast) nur noch Rechner mit UEFI-Boot-Modus ausgeliefert werden....!?
Was hat das damit zu tun, dass du die Änderung für zwingend hältst? Von mir aus kannst du das entsprechend anpassen, aber ich sehe hier keinen gesetzlichen oder moralischen Zwang, es anzupassen. Wobei natürlich zu klären wäre, was Laura seinerzeit mit "viele Systeme" gemeint hat.
Und es wäre zu klären, wer Laura ist. Noch mal! Es geht letztlich nur darum dem Leser klar zu machen, dass "CSM" kein einheitlicher Begriff ist, sondern vielfältig verwendet wird/werden kann.
Für mich ist der Begriff CSM ziemlich eindeutig und meiner Meinung nach wird der Begriff auch relativ einheitlich in den verschiedenen UEFI-Implementationen eingesetzt. Ich sehe keinen Bedarf, hier irgendetwas zu ändern, was meiner Meinung nach den Artikel verschlechtert.
|
Ali_As
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4665
|
Lieber apt-ghetto, nur damit du es auch noch mal verstehst. Es geht nicht darum, dem Leser der Bedarf an dem WIKI hat, zu erklären, was im Getriebe und im Motor passiert, wenn man einen Gang einlegt, sondern was passiert wenn man dann los fährt.
Nein, meinen wir nicht. Ich meine mit CSM das Compatibility Support Module. Du meinst mit CSM "irgendetwas".
Tja, wenn man nicht verstehn will, dann wird das halt nix.
Ich verstehe die Erklärungen nicht. Weder weiter vorne noch die folgende.
Dann streng dein Hirn gefälligst an!
Nein, das ist kein Fakt. CSM hält keine Bootmodi bereit.
Aha, und die Modi UEFI, Legacy both und first sind genau was?
Ich weiss auch nicht, was du mit "hybridem Modus" meinst. Du kannst kein BIOS-System im UEFI-Modus booten. Und auch das UEFI-System kann nicht im BIOS-Modus gebootet werden. Entweder wird ein System im BIOS- oder im UEFI-Modus gebootet.
Hat niemand was anderes behauptet, aber CSM stellt mit both oder first Modi bereit, die auf beides zugreifen können. Ist ja nicht so, dass du das nicht wüsstest.
Was wo grafisch wie dargestellt wird, spielt keine Rolle. Und wie willst du CSM optisch darstellen?
Darum geht es doch gar nicht! Sondern darum, was dem Nutzer zur Auswahl angeboten wird. Und wenn darüber CSM prangert, dann ist es für ihn eine optische Darstellung zur Auswahl.
Was hat das damit zu tun, dass du die Änderung für zwingend hältst? Von mir aus kannst du das entsprechend anpassen, aber ich sehe hier keinen gesetzlichen oder moralischen Zwang, es anzupassen.
Du hältst also die Formulierung "Viele Systeme werden deshalb im Nicht-UEFI-Modus ausgeliefert, laden also grundsätzlich das Compatibility Support Module." im Jahr 2018 für richtig? Einfach mal sagen, ja, das ist nicht mehr so, ist wohl nicht möglich!
Und es wäre zu klären, wer Laura ist.
Na dann schau mal, auf den Ersteller dieses Threads und der ganzen Artikelserie. Aber auch das dürfte dir bekannt sein. Bedauerlich, dass sie nicht mehr hier ist! Im Gegensatz zu dir, war sie in der Lage einen Sachverhalt zu erörtern, ohne dem Partner ständig zu vermitteln, dass man ihn für einen kompletten Idioten hält.
Für mich ist der Begriff CSM ziemlich eindeutig und meiner Meinung nach wird der Begriff auch relativ einheitlich in den verschiedenen UEFI-Implementationen eingesetzt. Ich sehe keinen Bedarf, hier irgendetwas zu ändern, was meiner Meinung nach den Artikel verschlechtert.
Wenn er für dich eindeutig ist, heißt das noch lange nicht, dass es auch jedem Nutzer so geht. Und die Behauptung, dass er relativ einheitlich umgesetzt ist, zeugt offensichtlich von kompletter Praxisferne. Ein Artikel ist dann gut, wenn er den Zweck erfüllt dem Leser geholfen zu haben. Seit der Zeit, als der Artikel entstanden ist, hat sich viel getan, gerade in der Vielfalt der UEFI-Firmwares. Dem Leser eine Orientierung zu geben, wie sich die Auswahl der verschiedenen Optionen auswirkt ist sinnvoll. Ob das ein Layer oder sonst was ist, ist im Bedarfsfall gerade mal völlig wurscht. Ansonsten bin ich nicht mehr bereit, mich hier weiter rum zu ärgern. Dafür ist mir meine nur noch knapp bemessene Lebenszeit zu schade. Ich habe einen Vorschlag gemacht, den ich imho gut begründet habe und gemäß meiner eigenen Erfahrungen mit ziemlich vielen UEFIs, für sinnvoll halte. Wenn das nicht erwünscht ist, so ist es denn so. L.G.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo,
Es geht nicht darum, dem Leser der Bedarf an dem WIKI hat, zu erklären, was im Getriebe und im Motor passiert, wenn man einen Gang einlegt, sondern was passiert wenn man dann los fährt.
Das ist korrekt. @Ali_As: Dann streng dein Hirn gefälligst an!
Es ist gut, dass du auf mögliche Fehler / Ungenauigkeit im Wiki hingewiesen hast - nur wenn du in der Diskussion nach zwei Posts ausfällig / beleidigend gegenüber dem Diskussionspartner wirst, dann ist das nicht zielführend.
Wenn das nicht erwünscht ist, so ist es denn so.
Klar, ist es - siehe oben. Manchmal muss man halt länger diskutieren und / oder - was auch hier sinnvoll ist - auf ein paar weitere Meinungen warten. Es ist ja nicht so apt-ghetto der einzige ist, der hier was sagen darf ☺ Bei "größeren" Änderung dauert's halt manchmal auch Tage, eh' man einen Konsens hat. Es muss nicht alles in Stunden passieren. Gruß, noisefloor Bearbeitet von BillMaier: habe mir erlaubt einen Tippfehler/Grammatik zu korrigieren, damit der Satz gleich beim ersten Lesen klar wird.
|
Ali_As
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4665
|
Hallo noisefloor! Es kommt immer darauf an wer was sagt. Wenn jemand meint, sich rhetorisch dumm stellen zu müssen, obwohl er genau weiß, was gemeint ist, um andere in die Vollpfostenecke zu stellen, dann gibt es eben die passende Antwort. Offensichtlich bist du nicht mit etlichen Postings dieser Art des Kollegen vertraut. Es nervt! Klar dauert so was. Wenn du aber von vorne herein angeblafft wirst, als hättest du nicht die geringste Ahnung von dem was du schreibst, dann motiviert das nicht eben. Eine sachliche Diskussion impliziert gegenseitigen Respekt und Verstehen wollen der Argumentation des Anderen. Beides ist hier nicht vorhanden, von daher verzichte ich auf weitere unergiebige Erörterungen dieser Art. Es gibt wichtigeres im Leben, als einige Sätze (von größeren Änderungen war hier nie die Rede) in einem WIKI abzuändern. Es würde mich freuen, wenn der Unterartikel zeitgemäß angepasst würde (was ausdrücklich nicht als Kritik an der Autorin zu verstehen ist), es ist ja nicht weiter schwer, einige Begriffe näher zu erläutern, wenn man denn will, aber ich bin hier raus und verabschiede mich mit... L.G.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6389
|
Ali_As schrieb: aber ich bin hier raus
Schade.
|
apt-ghetto
Anmeldungsdatum: 3. Juni 2014
Beiträge: 2943
|
Ali_As schrieb: Lieber apt-ghetto, nur damit du es auch noch mal verstehst. Es geht nicht darum, dem Leser der Bedarf an dem WIKI hat, zu erklären, was im Getriebe und im Motor passiert, wenn man einen Gang einlegt, sondern was passiert wenn man dann los fährt.
Dann wäre es gut, wenn man es auch richtig erklärt und nicht Sachen miteinander vermischt, die so nichts miteinander zu tun haben. Das wäre in etwa so, wie wenn du jemanden erklärst, dass der Motor Benzin braucht, aber wenn man rückwärts fährt, dann gibt der Motor wieder Benzin zurück. Das mag logisch tönen, ist aber trotzdem falsch. Nein, meinen wir nicht. Ich meine mit CSM das Compatibility Support Module. Du meinst mit CSM "irgendetwas".
Tja, wenn man nicht verstehn will, dann wird das halt nix.
Ja, stimmt, dann wird das halt nix. Dann bleibt das Wiki eben etwas veraltet. Hat bis heute ja auch niemanden gestört. Nein, das ist kein Fakt. CSM hält keine Bootmodi bereit.
Aha, und die Modi UEFI, Legacy both und first sind genau was?
UEFI und BIOS sind zwei verschiedene Arten von Firmware. Um Betriebssysteme zu booten gibt es den UEFI-Modus und den BIOS-Modus. Abhängig vom Modus sind die Bootloader an anderen Stellen zu suchen und die Schnittstellen mit der Firmware sind verschieden. Das was du mit "both" und "first" etc meinst, sind im Prinzip nur Filter. Mit "both" sucht die Firmware (UEFI) sowohl Betriebssysteme, die im UEFI-Modus, als auch im BIOS-Modus installiert sind. Mit "first" kann man angeben, dass beispielsweise Betriebssysteme im UEFI-Modus zuerst aufgelistet werden oder eben am Schluss. Die Benennung und Implementierung dieser Komfortfunktionen sind herstellerabhängig und haben im eigentlichen Sinne nichts mit CSM zu tun. Wenn kein CSM implementiert ist, dann wäre ein Filter "both" ziemlich unnötig, weil ja "gefundene" Betriebssysteme nicht gebootet werden können. Trotzdem, ist es die Firmware und nicht das CSM, das diese Funktionen anbietet. Ich weiss auch nicht, was du mit "hybridem Modus" meinst. Du kannst kein BIOS-System im UEFI-Modus booten. Und auch das UEFI-System kann nicht im BIOS-Modus gebootet werden. Entweder wird ein System im BIOS- oder im UEFI-Modus gebootet.
Hat niemand was anderes behauptet, aber CSM stellt mit both oder first Modi bereit, die auf beides zugreifen können. Ist ja nicht so, dass du das nicht wüsstest.
Doch, du hast etwas anderes behauptet. Und auch hier behauptest du wieder, dass es "CSM" sei, das diese "Modi" bereitstellt. Und es stimmt immer noch nicht. Es ist UEFI, abhängig von der Implementation, das solche Optionen anbieten kann, aber nicht muss.
Was wo grafisch wie dargestellt wird, spielt keine Rolle. Und wie willst du CSM optisch darstellen?
Darum geht es doch gar nicht! Sondern darum, was dem Nutzer zur Auswahl angeboten wird. Und wenn darüber CSM prangert, dann ist es für ihn eine optische Darstellung zur Auswahl.
Dass auf der gleichen Seite CSM und die Bootoptionen stehen, hat schon seinen Sinn. Zu behaupten, dass die Bootoptionen vom CSM bereitgestellt werden, ist allerdings falsch und gehört nicht ins Wiki. Was hat das damit zu tun, dass du die Änderung für zwingend hältst? Von mir aus kannst du das entsprechend anpassen, aber ich sehe hier keinen gesetzlichen oder moralischen Zwang, es anzupassen.
Du hältst also die Formulierung "Viele Systeme werden deshalb im Nicht-UEFI-Modus ausgeliefert, laden also grundsätzlich das Compatibility Support Module." im Jahr 2018 für richtig? Einfach mal sagen, ja, das ist nicht mehr so, ist wohl nicht möglich!
Ja, du hast Recht. Ich hätte direkt sagen können, dass du das ändern kannst, falls du willst. Und es wäre zu klären, wer Laura ist.
Na dann schau mal, auf den Ersteller dieses Threads und der ganzen Artikelserie. Aber auch das dürfte dir bekannt sein. Bedauerlich, dass sie nicht mehr hier ist! Im Gegensatz zu dir, war sie in der Lage einen Sachverhalt zu erörtern, ohne dem Partner ständig zu vermitteln, dass man ihn für einen kompletten Idioten hält.
Ich "kenne" syscon-hh noch, aber ich weiss nicht, wie du darauf kommst, dass der Name von syscon-hh Laura ist. Es hätte ja sein können, dass du syscon-hh tatsächlich kennst, aber auch hier vermutest du wohl einfach mal ins Blaue hinaus (das ist übrigens eine Vermutung von mir), dass syscon-hh Laura heisst und weiblich ist. Für mich ist der Begriff CSM ziemlich eindeutig und meiner Meinung nach wird der Begriff auch relativ einheitlich in den verschiedenen UEFI-Implementationen eingesetzt. Ich sehe keinen Bedarf, hier irgendetwas zu ändern, was meiner Meinung nach den Artikel verschlechtert.
Wenn er für dich eindeutig ist, heißt das noch lange nicht, dass es auch jedem Nutzer so geht.
Ja, zum Beispiel dir geht es so. Und die Behauptung, dass er relativ einheitlich umgesetzt ist, zeugt offensichtlich von kompletter Praxisferne.
Woher willst du das wissen? Bei welchem UEFI macht CSM etwas anderes, als allfällige Betriebssysteme im BIOS-Modus zu booten?
Ein Artikel ist dann gut, wenn er den Zweck erfüllt dem Leser geholfen zu haben. Seit der Zeit, als der Artikel entstanden ist, hat sich viel getan, gerade in der Vielfalt der UEFI-Firmwares. Dem Leser eine Orientierung zu geben, wie sich die Auswahl der verschiedenen Optionen auswirkt ist sinnvoll.
Falsche Informationen helfen dem Leser meiner Meinung nach nicht. Du kannst gerne die verschiedenen Optionen beschreiben. Und nein, diese Optionen werden nicht vom CSM bereitgestellt. Ob das ein Layer oder sonst was ist, ist im Bedarfsfall gerade mal völlig wurscht.
Nein, das ist eben nicht wurscht. Wenn man über Äpfel spricht, dann sollte es auch um Äpfel gehen und nicht um Birnen. Und falls ich es bin, der die Äpfel mit den Birnen verwechselt, dann kann man mir das erklären.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
Ich schlage zu diesem Artikel drei Dinge vor: 1. Für den Moment auf veraltet setzen. Begründung: Nach meiner Erfahrung hat sich die Situation über die Jahre ja doch etwas verändert. Zum Zeitpunkt der Erstellung des Artikels gab es zum einen weniger Informationen, auf die er zurückgreifen konnte. Zum anderen hat man auf CSM noch viel häufiger zurückgreifen müssen. Außerdem hatte man da den Eindruck, dass die Hersteller mit der Implementierung der ganzen Modi auch teilweise überfordert waren. 2. Secure Boot auf Dauer auszulagern. Begründung: Siehe den Umfang der Thematik, z.B.: https://wiki.ubuntu.com/UEFI/SecureBoot https://www.rodsbooks.com/efi-bootloaders/secureboot.html 3. Secure Boot dann überarbeiten Begründung: Zum Zeitpunkt der Erstellung des Artikels war Secure Boot zu schlecht unterstütz, zu schlecht verstanden und es ging primär darum, zu erklären, wie man es abschaltet. Diese Situation hat sich aber über die Jahre gebessert. Dementsprechend ist IMO eine inhaltliche Anpassung angebracht. Zu der hier generell laufenden Diskussion über die Begrifflichkeiten über die Jahre: Ich rate insbesondere in diesem speziellen Fall es einfach ein mal besser zu machen! Das sage ich ganz emotionslos. Theoretisch mögen die Begrifflichkeiten klar sein, wenn man es aber im Artikel dann konkret verständlich niederschreiben und auch mit Bildschirmfotos untermauern muss, wird das ganze viel schwieriger. Schon alleine das Anlegen von Bildschirmfotos ist in diesem Fall viel aufwendiger, als wenn man einfach einen Screenshot einer VM oder aus dem laufenden OS anfertigen kann. Hinzu kommt, dass die eigenen Erfahrungen über "UEFIs in the wild" schlicht nicht ausreichen, um sagen zu können so oder so ist es! Ich kann mich noch gut an die Erstellung der Artikel-Serie erinnern und syscon-hh und ich waren zu diesem Zeitpunkt so ziemlich die beiden einzigen, die etwas aktiv zu dem Thema beigetragen haben. Zu diesem Zeitpunkt hatte ich Zugriff auf gerade mal zwei oder drei Systeme mit UEFI. Bei syscon-hh waren es etwas mehr. Schon allein deswegen konnte der Artikel zu diesem Zeitpunkt überhaupt nicht annähernd "perfekt" sein. Trotzdem musste zu diesem Zeitpunkt das Thema bearbeitet werden, weil es etliche Support-Anfragen dazu gab. Mit mehr konstruktivem Feedback zum Artikel zum Zeitpunkt seines Erstellens, wäre er sehr wahrscheinlich besser gelungen. Aber so geht es hier allen Wiki-Autoren: Du mühst Dich je nach Thema mehr oder weniger ab und inhaltliches Feedback bekommst Du zu dem Zeitpuntk, zu dem es Dir mögliche wäre ausreichen darauf einzugehen schlicht zu wenig. ← Das ist kein Vorwurf an irgend jemanden sondern schlicht nur eine Feststellung. Das soll jetzt hier niemanden davon abhalten, auch weiterhin Kritik am Artikel zu üben, ganz im Gegenteil. Aber dann bitte ab einem gewissen Punkt dann einfach auch mal selbst die eigenen Vorschläge in das Wiki übertragen. Da kommt man nämlich gerade bei diesem Thema sehr schnell ins "Formulierungs-Schleudern". Viele Grüße,
Martin
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28316
|
Hallo, im Prinzip von mir aus alles ok. Bzw. es gibt keine "veraltet" Markierung, aber du kannst gerne die "ausbaufähig" Markierung setzen. Gruß, noisefloor
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10674
|
Hej, dieser Artikel ist (Ubuntu)versionsunabhängig. → geändert Gruß black tencate
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
Ich habe den Abschnitt "Boot-Verzeichnis" überarbeitet. LG,
Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 7816
|
Newubunti schrieb: Ich habe den Abschnitt "Boot-Verzeichnis" überarbeitet.
Danke, aber: In der alten Version des Textes wird bei der Auflistung der Dateien unterschieden zwischen Systemen mit und ohne "Secure Boot". Diese Unterscheidung ist nun weg. Entspricht das dem aktuellen Stand, d.h. werden standardmäßig immer alle für "Secure Boot" erforderlichen Dateien installiert? Trifft das so auch zu für alle aktuellen LTS-Versionen, d.h. aktuell 20.04 und 22.04?
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
kB schrieb: In der alten Version des Textes wird bei der Auflistung der Dateien unterschieden zwischen Systemen mit und ohne "Secure Boot". Diese Unterscheidung ist nun weg. Entspricht das dem aktuellen Stand, d.h. werden standardmäßig immer alle für "Secure Boot" erforderlichen Dateien installiert? Trifft das so auch zu für alle aktuellen LTS-Versionen, d.h. aktuell 20.04 und 22.04?
Genau diese Unterscheidung zwischen Secure Boot und nicht Secure Boot trifft seit mindestens Ubuntu 20.04 nicht mehr zu und war einer der Hauptgründe der Überarbeitung. Ubuntu installiert auf einem UEFI-System standardmäßig immer sowohl Shim als auch die von Canonical signierte Variante der grubx64.efi und nutzt damit auch stets das Verzeichnis /EFI/ubuntu - auch im Falle von Kubuntu ist das so. Der Artikel könnte eigentlich auch eine strukturelle Überarbeitung vertragen. Die Bilder der Installations-Medien sind z.B. für Jammy auch nicht mehr treffend. Die ganze EFI-Artikel-Serie leidet an dem Mangel, dass sie EFI als vom Nutzer erst zu aktivierenden Sonderfall darstellt. Das war halt 2013ff so, hat sich aber mittlerweile umgekehrt. LG,
Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 7816
|
Newubunti schrieb: […] Genau diese Unterscheidung zwischen Secure Boot und nicht Secure Boot trifft seit mindestens Ubuntu 20.04 nicht mehr zu und war einer der Hauptgründe der Überarbeitung.
Ok. Danke. Dann ist ja jetzt gut so, wie es ist.
[…] Der Artikel könnte eigentlich auch eine strukturelle Überarbeitung vertragen. Die Bilder der Installations-Medien sind z.B. für Jammy auch nicht mehr treffend.
Jein. Der Abschnitt zu den Installationsmedien ist fremd in diesem Artikel. Hier geht es um die EFI-Grundlagen, die unabhängig von Ubuntu sind und der Ubuntu-Bezug besteht in der Darstellung, in welcher Weise Ubuntu die ESP benutzt. Das ganze sollte möglichst unabhängig von der Ubuntu-Version sein. Der Abschnitt zu den Installationsmedien wäre also besser an anderer Stelle vorzusehen, die explizit auf den Installationsvorgang eingehen.
Die ganze EFI-Artikel-Serie leidet an dem Mangel, dass sie EFI als vom Nutzer erst zu aktivierenden Sonderfall darstellt. Das war halt 2013ff so, hat sich aber mittlerweile umgekehrt.
Wenn man einen besseren Ort für den Abschnitt zu den Installationsmedien findet und ihn dahin verschiebt, ist die Darstellung der EFi-Grundlagen in diesem Artikel ja durchaus aktuell.
|