Nein, der Eintrag wurde erst am 27.10. in OpenCore unter UEFI/Output aufgenommen. Da ich mitbekommen habe, dass LuckyOldMan den OpenCore Configurator einsetzt, hege ich da einen ganz anderen Verdacht. Das wäre mal wieder ein Paradebeispiel dafür, warum man dieses "Hilfstool" nicht verwenden sollte.
OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
Ist mir persönlich sowieso unbegreiflich so ein Tool zu nutzen - welches praktisch dem Progress von OC immer hinterher hinkt - und welches einem User von einen Moment auf den anderen das booten zerschießen kann. Es ist doch so einfach, die jeweilige Sample.plist mit der eigenen config.plist per DiffMerge abzugleichen. Daher verstehe ich auch sehr gut die Abneigung der OC Developer gegen solche Tools.
-
der Eintrag wurde erst am 27.10 ...
Insofern bestätigst Du damit, dass der Eintrag erst seit ein paar Tagen (bei mir) auftauchen konnte - genau das sagte ich, auch wenn meine erste vermutung in eine andere Richtung ging.
Ob Dein gehegter Verdacht belastbar gemacht werden kann, wird sich zeigen ... oder auch nicht.
Ist mir persönlich sowieso unbegreiflich so ein Tool zu nutzen -
Hast Du so auch beim Clover Configurator argumentiert und hast Du den auch nie benutzt? Wohl eher nicht, vermute ich mal, denn den haben Abertausende benutzt und selbiger hinkte auch dem Progress von Clover hinterher.
von einen Moment auf den anderen das booten zerschießen kann
Sollte das tatsächlich mal eintreten (bis jetzt noch nicht), liegt der Backup-Stick schon daneben - so, wie man es grundsätzlich machen sollte, wenn man etwas verändert.
Es ist doch so einfach, die jeweilige Sample.plist mit der eigenen config.plist per DiffMerge abzugleichen.
Na ja - für Dich und Andere bestimmt, für mich noch nicht so wirklich. Hat manchmal gut geklappt, manchmal habe ich mir schon richtige Böcke reingeschoben.
Letzen Endes muss das Jeder für sich entscheiden. Ich überprüfe meist nach dem OCC hinterher via PlistEditor, wenn ich etwas verändere, wenn ich nicht schon wegen einer Kleinigkeit den PlistEditor direkt genommen habe. Ich mache aber da keine Ideologie draus, was ich wann verwende.
Aber was bedeutet jetzt dieser Hinweis - kann mir das Jemand verraten?
-
-
dieser Eintrag kommt einzig davon wenn man sich die EF'I mal so aktualisiert z.b. Paste and Copy und dabei ne alte config beibehält anstatt diese dann händisch (ohne OCC) anzupassen. Dann passiert sowas schonmal.
-
LuckyOldMan Das Problem scheint folgendes zu sein: Du schreibst, dass du OC 0.6.3 schon länger und ich vermute mal schon vor Final Release und bevor der betreffende Eintrag hinzugekommen ist, im Einsatz hast. Wenn du nun deine config.plist mit dem aktualisierten OpenCore Configurator öffnest, sie bearbeitest und anschließend abspeicherst, dann fügt dir der Configurator einfach diesen Eintrag hinzu und dies, obwohl er nicht zu den anderen, älteren OpenCore Dateien (OpenCore.efi und BOOTx64.efi) passt, was dann zu der der Fehlermeldung führt, weil deine älteren OpenCore Files einfach nichts damit anfangen können.
LetsGo Falsch, der Eintrag ist plötzlich drin, aber seine OpenCore Version kann nichts damit anfangen.
EDIT: LetsGo Sorry du hast vielleicht doch recht und es war genau umgekehrt.
-
LuckyOldMan Den Clover Configurator habe ich eigentlich nur ab und an Mal benutzt. Und wenn, dann eigentlich nur um mal ein smbios zu generieren oder Clover zu aktualisieren. Alles andere habe ich schon immer mit PlistEdit Pro erledigt.
badbrain Man kann den OC Configurator in den Einstellungen auch an die jeweilig benutzte Version anpassen. Was immer noch nicht bedeutet, dass das dann alles funktioniert. Wenn man z.b eine Beta Version von OC nutzt und in der Release sich trotzdem noch etwas ändert.
-
Ich weiß karacho und das meine ich ja auch. Wenn du eine OC 0.6.3-Version hast, in welcher der Eintrag noch nicht vorhanden war und du die config.plist mit aktuellem OC Configurator und mit OC-Version 0.6.3 Voreinstellung bearbeitest und abspeicherst, dann kann genau das passieren, worum es hier geht.
-
wenn man sich die EF'I mal so aktualisiert z.b. Paste and Copy und dabei ne alte config beibehält
Das ist seit den Tagen, wo publiziert wurde, dass immer nur Elemente aus der selben Version stammen sollten, für mich tabu. In diese "Falle" sind ja auch Andere getappt, wie nachzulesen ist.
Du schreibst, dass du OC 0.6.3 schon länger und ich vermute mal schon vor Release ...
Soweit ich mich erinnere, hab ich immer die Release genommen - keine Nightlys o. Ä.
Ich denke, dass Deine Darlegung bei mir zumindest nicht mehr auf die letzten Monate seit 060/061 zutrifft, denn wie gesagt nehme ich immer die Dateien aus dem jeweiligen Paket. Ich achte da inzwischen peinlichst drauf, um mir nicht noch mehr Probleme einzuhandeln als ich eh schon haben könnte.
Ist z. Bsp schon eine neue OC-Release ausgerollt und der OCC nicht dafür passend, nehme ich ihn nicht zum Erstellen/Bearbeiten der Config.plist. Dann quäle ich mich lieber durch den PlistEditor.
dann kann genau das passieren, worum es hier geht.
Das habe ich jetzt nicht verstanden.
-
Moinsen, welches SMBios nutze ich am besten für einen Laptop mit einem Intel i5-4210M und einer HD Grafik 4600??
-
LuckyOldMan Mit dem Begriff Release ist das bei OC etwas schwierig. Ich meine natürlich 0.6.3 Final. Jede Version, die man sich selbst kompiliert oder herunterlädt ist ja Release.
-
Mit dem Begriff Release ist das bei OC etwas schwierig
Offensichtlich.
Dan erläutere mir doch bitte mal bzgl. OC den Unterschied zwischen Release & Final, zumal ich noch nirgends eine OCx.x.x Final gefunden habe.
-
Final sind die, die auf der Acidanthera/Releases Seite zum Download zur Verfügung stehen. Die anderen (selbst kompiliert, oder bei Dortania kompiliert heruntergeladen) sind Release Files, aber nicht Final (Release bedeutet nur, dass das keine Debug Version ist).
-
LuckyOldMan Das habe ich dir doch oben geschrieben. OpenCore 0.6.3 ist nun mal nicht = OpenCore 0.6.3, da jeden Tag, jede Stunde oder jede Minute ein neuer Eintrag hinzukommen oder einer verschwinden kann. Final Releases gibt es hier: https://github.com/acidanthera/OpenCorePkg/releases
-
Final sind die, die auf der Acidanthera/Releases Seite zum Download zur Verfügung stehen
& badbrain
Und genau da stammen meine Versionen her - selber kompiliert habe ich nichts.
Dass die Devs emsig sind, weiß ich auch, aber ich ändere ja nicht dauernd etwas. Ich bediene mich bei der Ersterstellung aus dem Paket, das ich heruntergeladen habe, erstelle den Bl und wenn der passt, war's das.
Ich werde erst dann wieder aktiv, wenn eine neue Final in der Tür steht.
War nichtdestotrotz recht informativ, aber ich übersehe jetzt einfach den Hinweis und warte bis zur nächsten Final aus gewohntem Link.
-
Wäre sinnvoll, wenn sich Leute informieren würden, was "Release" und "Debug" bedeutet.
Anstatt sich hier die Begriffe um die Ohren zu hauen.
Debug (entwanzen) besagt, dass ein Programm mit vollständigen symbolischen Debuginformationen und ohne Optimierung kompiliert wird.
Es dient vornehmlich zum Aufspüren von fehlerhaftem Code. Die Informationen können dem Entwickler bereitgestellt werden. Programme aus dem Debug-Build sind aus diesem Grund größer.
Release (Veröffentlichung) besagt, dass die Programme über keine symbolischen Debuginformationen verfügen und sind vollständig optimiert.
Programme aus dem Release-Build sind kleiner, weil sie keine Debuginformationen enthalten.
Da Opencore sich fortlaufend in der Entwicklung befindet, kann es keine Final geben.
-
bluebyte Jau, danke großer Meister. LuckyOldMan Ich habe gerade in diesem Post folgenden Screenshot von dir gesehen - ist das vielleicht der Ursprung deines Problems?
-
Insofern korrekt Steffen, bis auf den Umstand, dass man beim selber kompilieren einer Version die noch nicht released ist, also praktisch eine Nightly, trotzdem eine .zip Datei mit dem Zusatz 'release' bekommt. Ob das bei den Downloads auf Dortania auch so ist, weiß ich nicht, habe dort noch kein OC runtergeladen. Daher weiß ich nicht, ob das nun täglich neu kompilierte Nightly 'releases' sind, oder ob das 'echte releases' sind. Beim KextUpdater weiß man, wenn man OC Nightly zum Download anklickt, dass man eine Nightly bekommt die jeden Morgen um 0400 frisch erstellt wurde, obwohl dort im DL Ordner auch 'release' steht. Es mag an dieser Begriffsverwirrung liegen, dass manche User glauben, sie hätten eine Release Version installiert, dabei ist es im Endeffekt nur eine Nightly mit dem Zusatz 'release'.
-
Official wird nur am ersten Montag jeden Monats, vollständig und auf Herz und Nieren geprüft, soweit es möglich war, von den Entwicklern freigegeben, alles andere zwischendrin ist lockere "beta code" und hängt einfach in der Luft zwischen den release des ersten Montags des derzeitigen Monats und des naechsten ersten Montags des folgenden Monats. Der Einsatz solcher, "zwischen drin code" ist mit grösseren Risiken verbunden wie zum Beispiel die offiziellen Monatlichen releases am ersten Montag jeden Monats.
Ein Release kann man auswählen so das es debug code beinhaltet oder auch nicht. Die debug code
die ein release beinhaltet erleichtert die Fehler Eingrenzung fuer diejenigen die auch wissen wie mit den Ausgaben die diese debug code "ausspuckt", umzugehen ist. Die debug code die in den debug release eingebaut wird/wurde vergrössert natürlich auch den Installation "footprint", beansprucht also mehr Platz auf den Speicher Medium.
Gruesse Henties
-
ist das vielleicht der Ursprung deines Problems?
Da muss ich jetzt selber überlegen. Das ist einen Tag vor dem von Dir genannten Datum 27.10.20 und bis dahin lief Alles noch ohne Hinweis und danach meine ich keine Veränderung mehr am OC gemacht zu haben - es gab ja auch aus meiner Sicht keine Notwendigkeit, weil Alles zur Zufriedenheit lief.
Ein reiner Aufruf der config.plist via OCC, um Bilder für Hilfestellungen machen zu können, dürfte ja nicht das bewerkstelligen, was Du weiter oben beschrieben hast, denn dann wäre das eine von mir nicht vorgenommene Veränderung, die ich zumindest mit einem Speichern hätte bestätigen müssen. Daran kann ich mich nicht erinnern.
Aber Klasse, dass Du dir die Mühe machst.