OpenCore Sammelthread (Hilfe und Diskussion)

Bin gerade am recherchieren...melde mich gleich wieder

Edit: Auf ein neues. iGPU ist noch deaktiviert.

Kleine Anmerkung am Rande....

An alle Mitstreiter, Kumpels etc., die einige der EFI Files aus den vergangenen Dialogen in diesen Thread zwischen mir, al6042 und karacho heruntergeladen haben.. Bitte nutzt unbedingt eure eigenen Seriennummern etc.. oder generiert euch neue. Somit verhindern wir dass unnötig Serials etc misbraucht werden. Schon mal großes Dankeschön an euch alle.!!

Freundliche Grüße und weiterhin gutes Hackin....

sv

karacho

mit der letzten EFI kommt nach der Bootlist:

Großes Verbotszeichen...

Danach eine Zeile:

start image failed.. abortet...

Sonst nichts..

Ps: Kein unterschied ob mit Igpu oder deaktivierter iGpU...

Nvram reset habe ich selbstverständlich auch ausgeführt.

Das richtige Volumen für den Start in der Bootlist war auch korrekt gewählt...

Ich verstehe einfach nicht, warum alles einwandfrei funktioniert mit der OC 0.5.0 und mit der 0.5.3 keine Chance...

Ich kann leider keine OC Beta auf meinem PC erstellen, da anscheinend die passende XCODE Version fehlt.

Unter High Sierra steht die letzte aktuelle Xcode als inkompatibel im AppStore.. Wird verlangt dass man auf Catalina aktualisiert.. was ich aber solange ich mit Nvidia fahre natürlich nicht machen kann/möchte.

Ok, nimm mal in der config.plist bei NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C9F82->boot-args ALLES raus, außer dem -v

Edit: Nvram Reset ist immer gut

karacho

Super !!!! VIELEN DANK bis hierher für deinen und al6042´s Support!

Kollege,... Ich bin drin.! PC läuft geschmeidig hoch.

Glaubst du, ich kann die IGPU wieder unter Devices einpflegen? Brauche das Teil..

Kannst du gerne versuchen. Halte jedoch immer ein Backup deiner jetzt funktionierenden EFI parat.

Melde mich gleich nochmal...

Ok. Sollte die iGPU danach wider erwarten nicht korrekt arbeiten, dann trage wieder shikigva=40 in die boot-args mit ein. Du hattest in der Clover config.plist den Wert 100. Den kannst du versuchen, wenn es mit 40 nicht klappt.

sv0911
Coole Sache...

karacho , al6042

die IGPU ist jetzt auch am laufen.. !! Ihr seit Klasse Kollegen!!!!

In den Systemeinstellungen unter Graphics/Steckplätze erscheinen sie zwar nicht als onboard 1/2 sondern

mit Nummern.. Das ist aber vieleicht nur eine kosmetische Sache.. Oder? (Siehe Anhang)

Ansonsten alles Paletti..!!

Die Nummern sind die ausgelesenen Steckplatz-Definitionen... alles gut und kann, wenn gewollt, in den DeviceProps manuell gesetzt werden.

Jo mei, Einwandfrei...

karacho & al6042 ,

was meint ihr, Freunde,..? Soll ich die EFI für OC in diesen Thread:

"OpenCore Sammelthread (lauffähige Konfigurationen) Desktop" hochladen (natürlich ohne Serial etc..),

für unsere Kollegen und Mitstreiter, die ein gleiches/ähnliches System wie das meine am Start haben?

Sollte doch OK sein.

Bis hierher euch nochmal Riesen Dankeschön.

Uuund... Weiter gehts....

Auf alle Fälle...

Was für eine Frage...

Im Insanelymac Forum habe ich mal das Problem geschildert mit dem nicht mehr funktionierendem NVRAM seit die 0.53 auf "Release" gestellt wurde.

Scheint irgendwie keiner so wirklich einen Plan zu haben oder keine Muße darauf mal was zu posten. Ausser "bei mir auch" kommt nicht wirklich was

btw: von anderen Mistreitern höre ich auch Frust über sehr schwache Resonanz sofern mal Fragen zu etwas tieferer liegenden Problemen kommen.

Ist sehr sehr schade , halte eigentlich sehr viel von OC und ja ich weiss , befindet sich noch in der Entwicklung. Naja, Jammern hilft nicht..

Aber wie geh ich jetzt das NVRAM Problem an ? Vorschlag von 2 Seiten vorher "geh auf die Beta zurück" ist natürlich eine Möglichkeit, aber hier gehts doch um die Weiterentwicklung und Bug-Beseitgung usw. und dann kann ich gleich wieder auf das Kleeblatt umsteigen. Das ist aber nicht das Ziel ...

Schönes Adventswochenende allerseits

Wo ich dir zustimmen kann, ist das Problem, dass nur wenige User wirklich verstehen was sie machen, bzw das Problem, dass es viel zu wenige OpenCore Experten gibt, die sich auch mit den Hintergründen auskennen. Das liegt aber nicht an OpenCore und erst recht nicht an der Dokumentation von OpenCore, sondern wenn dann daran, dass sich die OpenCore Nutzer-Basis gerade erst entwickelt und Clover hingegen schon bereits seit Jahren von Tausenden genutzt wird. Dementsprechend findet man zu fast jedem Problem zumindest einen Mitstreiter.

Was ich hingegen nicht nachvollziehen kann sind Klagen über schwache Resonanz der Entwickler. OpenCore wird aktuell praktisch ausschließlich von zwei Einzelpersonen gestemmt und entwickelt, und das liegt nicht daran, dass die Hauptentwickler nicht gerne Hilfe von anderen kompetenten Entwicklern hätten. Zudem haben diese beiden Hauptentwickler auch privat einiges um den Hut, was neben Privatleben an Zeit in das OC Projekt fließt ist beachtlich bis unvorstellbar. Dass man vor diesem Hintergrund nicht auf Probleme reagiert, die zB eindeutig Nutzerbedingt sind oder die aus Behauptungen ohne eindeutige Sachlage (z.B ausführliche Tests, OC- und Apple- Logs etc.) bestehen ist meiner Meinung nach ziemlich verständlich. Wenn es hingegen mal ein wirkliches/eindeutiges Problem gibt und dieses per acidanthera BugTracker an die Devs herangetragen wird, ist dieses meistens innerhalb kürzester Zeit gefixt.

Mit mehr Zeit wird es mehr User geben, die kompetente Hilfestellungen bieten werden können. Bis dahin sollte man sich meiner Meinung nach anhand von "Resonanzmenge" kein Allgemeinbild von OC versuchen zu bilden.

Was dein NVRam Problem angeht, beschreib doch mal was genau die Sachlage ist und was du bereits versucht hast. Hast du bisher bei deiner Z390 Platform (die allgemein bekannt NVRam Probleme und unknown Behaviour mit sich bringt) den NVRam emuliert, zB per EmuVariable unter Clover, oder LegacySchema unter OC? Wie sieht deine Configuration (zB bezüglich FWRuntime) aus? Hast du mal versucht den Zeitpunkt genau einzuschränken, seit dem das "NVRAM Problem" existiert, um herauszufinden mit welchem OC-Commit das zusammenhängen kann? Wenn ja, an welchem Commit liegt es, enthält der problematische Bereich DEBUG Meldungen, was geben dir diese DEBUG Meldungen aus, wie sieht das LOG aus? Wie testest du den NVRam, bist du dir sicher, dass das Problem (was auch immer das Problem genau ist) am NVRam liegt? Ist das Problem anhand von verschiedenen OC Revisionen reproduzierbar, oder handelt es sich womöglich um einen FW Bug, der mit OC garnichts zu tun hat? Mit solchen Informationen kann man dann arbeiten und wenn man dabei ein OC-Bug findet, kann man mit diesen Informationen super an die Devs herantreten

Ebenfalls schönes Adventswochenende!

pstr Es gab aber auch noch andere Vorschläge, als nur die von dir genannten. Zb. das man auch die Treiber gleich mit erneuert bei einem Wechsel von der Beta zur Release. Das hatte in den meisten Fällen bei den Usern, die davon betroffen waren, schon gereicht. Habe ich auch schon hier geschrieben und auch bei insanely.

Edit: bin leider kein coder, sonst würde ich gerne viel mehr zu OC beitragen.

pstr  kuckkuck hat (leider) mit vielem Recht... generell ist der Konsens, dass NVRAM auf Z390 nicht funktioniert - und wenn dann zwei Leute kommen, die meinen, es ging bei ihnen bis zu einem bestimmten Update, dann ist das mit der Informationsquantität und -qualität schwer oder zumindest unökonomisch zu glauben und Zeit zu investieren. Wenn jemand bisektioniert und dann den Fehler aufzeigt, ist er gerne in 10 Minuten gefixt, aber Eigenrecherche lohnt sich bei soetwas einfach nicht.

Wie karacho gesagt hat, gerade FwRuntimeServices *muss* immer mit OC aktualisiert werden - zukünftig wird dieser Treiber wohl direkt mit OC ausgeliefert

danke für euren Beistand und Rückmeldungen - ich muss euch natürlich in den meisten Punkten Recht geben.

Es ist so, dass ich selbstverständlich alles aktualisiert habe, also auch die .efi Treiber und genau an dieser Stelle ist mein System durchgefallen.

Ja, natives NVARM mit z390 wird allgemein als "funktioniert nicht" beschrieben. Zugegebener maßen habe ich die Emulation nicht aktiviert, es lief halt bislang ohne ein einziges Problem u.a. durch das angepasste DSDT immer nativ.

Um es zu nochmal kurz beschreiben : ein mit einem funktionierendem System per , sagen wir mal per Hackintool, ergänzter NVRAM- Testeintrag, ( geht natürlich auch auf commandline) blieb nach Re-Boot persistent und war auch übergreifend (Clover / OC und zurück ) immer persistent. Nun ist's vorbei - mit OC 0.53 Releae wird der Eintrag übernommen, lässt sich auch jederzeit per commandline "nvram -p" usw anzeigen, ist aber nach Re-Boot verschwunden. Also ist natives NVRAM nicht mehr funktionabel.

An der Stelle fällt mir halt nur ein, das die Speicherverwaltung in den FWRuntimeServices sich geändert haben mag und mir nun einen Strich durch Rechnung macht.

Und nochmal .. Respekt vor der ganzen Arbeit der Dev's und es liegt mir fern hier a) zu meckern und b) irgendwie jemanden zu Nahe zu treten.

Bis dahin und Grüße

OC v053:
Heute wieder, nach einen NVRAM-Reset zerschießt es mir den EFI-Booteintag für macOS.

Booteintrag füge ich dann mittels Linuxconsole wieder ein, bei Clover hatte ich nie das Problem.

Lösche unter Linux mal alle Booteinträge mit dem eifibootmgr. Wenn kein Booteintrag mehr vorhanden ist, gibt der efibootmgr eine Meldung aus, dass deine UEFI Firmware beim Neustart neue Einträge von den gefundenen Systemen erstellt. Die sollten dann 'eigentlich' auch nach einem NVRam Reset erhalten bleiben.