OpenCore Sammelthread (Hilfe und Diskussion)

Hallo xerano ,

Bei OpenCore ist die SIP als Standard aktiviert. Macht auch Sinn und sollte nicht geändert werden. Bei Clover hast du die SIP deaktiviert.

Bei aktivierter SIP wird das laden von nicht Apple Kexten aus dem System blockiert.

Vorschlag wäre, du baust dir einen Clover Ordner mit aktivierter SIP auf einem USB-Stick. Diesen ergänzt du um die fehlenden Kexte welche im System installiert sind. Zum aktivieren der SIP am besten beide Werte im Bild auf 0 setzen.

Sollte es dir dann möglich sein von diesem Clover USB-Stick zu booten ist das eine gute Basis für den Umbau zu deinem Opencore EFI-Ordner.

Zitat von bumbuy

und mit meinen Treibern und Kexten aufgefüllt,

Was heißt das ? du Nimmst die Treiber aus dem NDK Fork für das normale OC ?

Ich glaube der USBPorts.kext ist der gleiche wie im NDK-Fork, oder hätte ich den neu erstellen müssen?

Hallo bumbuy ,

Die config.plist vom OC N-D-K Fork und original OC sind voll zueinander kompatibel. Es gibt auch keinen unterscheid in den Kexten oder Patches ...

Am besten ist du nimmst die Sample.plist und machst die mit dem Plist Editor deiner Wahl auf und daneben deine alte bereits funktionierende config.plist. Dann alle Werte rüber kopieren. Bis auf einige normalerweise nicht mehr relevanten Parameter solltest du alles aus deiner alten config.plist in der neuen Sample.plist finden.

PS: Einzige relevante Änderung ist "Replaced RequireVault and RequireSignature with Vault". Vault sollte auf Optional gesetzt werden.

Kexte sind erst mal egal.

Treiber sollten aber immer vom jeweiligen Fork genommen werden von dem man das OC nutz. grade die RuntimeServices.EFI bumbuy

Danke für den Hinweis. Ich hab das auch so begonnen, aber die neue config ist in vielen Bereichen komplett neu aufgebaut und anders strukturiert. Da ist vieles hinzugekommen und weggefallen. @anonymous writer

Hab korrekt drauf geachtet die richtigen zu verwenden. @julian91

Hallo bumbuy ,

Eigentlich nicht wirklich.

Die Parameter wurden verschoben in andere Bereiche. Als Beispiel von MISC BOOT nach UEFI OUTPUT.

Sollt die "SIP" im Hacki nicht immer deaktiviert sein ?

Wie kommst du den da drauf ?

Das ne Sicherheitsfunktion von MacOS.

ich hab sie auf allen Systemen an auf den Hackys ...

schmalen , Apple hat die SIP nicht umsonst eingebaut. Ich kenne keinen Grund warum man die deaktivieren sollte.

Es soll welche geben welche bestimmte Kexte im System benötigen. Bei mir war das noch nie der Fall.

anonymous_writer weil wenn ich aktiviere diese Meldungen bekomme, und wenn ich in die Systemsteuerung diese aktivier, werden Sie dennoch eingeblendet

Das ist kein Grund die SIP zu deaktivieren.

https://helpcenter.steinberg.d…Installation-von-Hardware

schmalen Ich habe SIP immer aktiviert nur zu bastelzwecken hatte ich bei Clover mal die 0x67 drin... hatte bisher noch keine Probleme...

Danke werd mich morgen mit SIP beschäftigen, muss zur Nachtschicht

Zitat von kuckkuck

Die beste Herangehensweise in so einem Fall ist über das Terminal im Log die Wake Reason zu finden und sich dann das entsprechende Gerät anzuschauen. Meistens ists USB, da hilft dann ne USB Dummy Kext.

Fix Sleepimage ist mehr Dirty Hack als Fix. Was da wahrscheinlich gemacht wird ist, dass das Sleepimage erst gelöscht wird, dann ein leeres Sleepimage erstellt wird und dieses schreibgeschützt wird. Dafür gibts auch Terminal befehle mit denen (leicht angepasst) du das einfach rückgängig machen kannst.

Dank dir kuckkuck für die Info. Hätte ich mal besser vorher fragen sollen - leider konnte man so nichts über die Funktion ergoogeln. Du hast offensichtlich Recht, wenn man sich den Screenshot anguckt oder? Haken bei "gesperrt" ist drin - aber angeblich hat der User "System" weiterhin read und write?!

Die gute Nachricht ist, dass der Sleep jetzt funktioniert. Die Schlechte ist jetzt aber wohl deine Info - sofern der Screenshot deine Vermutung bestätigt.

Sollte dem so sein, kann man das sleepimage bei deaktivierter SIP wohl einfach löschen - macOS legt es dann selber wieder an, mit den richtigen Rechten.

Danach würde ich dann deine "Ursachensuche" durchführen -- ist denn dieser Befehl den ich gerade gefunden habe, noch Up2date?

log show --style syslog | fgrep "Wake reason"

Das klingt gut und sieht gut aus

Ahhh also doch kein gemurkse mit einem Schreibschutz? Ich bin unsicher, weil das Image ja 0kb hat?

Im Netz finde ich aber hunderte Infos, dass bei den Usern das Sleepimage mehrere Gigabyte groß ist

Zitat von Maddeen

Haken bei "gesperrt" ist drin - aber angeblich hat der User "System" weiterhin read und write?!

Ja, der Haken ist für das System irrelevant. Es kann dann trotzdem lesen/schreiben. Du kannst aber z.b. mit dem Kext Updater unter Werkzeuge das Sleepimage korrekt einstellen/erzeugen. Es werden dann die entsprechenden Bits gesetzt.

ich habe folgendes Problem:

Wenn ich vom OpenCore-Menü aus in die Shell gehe und dort beispielsweise eingebe "cd fs1:", bekomme ich die Meldung "Current directory not specified". Dieselbe Meldung kommt logischerweise auch, wenn ich beispielsweise eingebe "map > map.txt". Ich kann mir problemlos die Inhalte eines Volumes anzeigen lassen ("ls fs1:" etc.), aber ich kann eben in keines wechseln oder auf eins was drauf schreiben.

Das Problem besteht übrigens auch, wenn ich dasselbe vom Clover-Menü aus probiere, so hab ichs gerade auch probiert. Es scheint also nicht wirklich OpenCore-spezifisch zu sein. Ich poste es trotzdem hier, weil ich hier die hellsten Köpfe vermute, die mir damit vielleicht helfen können Ansonsten gerne verschieben.

tipp mal nur

und dann Enter.