Kein Boot mit aktiver SIP

Was hier wieder für ein Quatsch geschrieben wird... EmuVariable fungiert absolut unabhängig von jeglichen MemoryFixes und funktioniert auch mit AptioMemoryFix wunderbar. Kein MemoryFix hat *direkt* etwas mit SIP zu tun, aber SIP-Optionen könnten theoretisch (das Symptom suggeriert dies, aber ich werde nicht wirklich nachschauen) die Speicherallokierungsmuster von boot.efi beeinflussen, was dann sehr wohl etwas mit den MemoryFixes zu tun hat. Ein Speicherallokierungsproblem liegt nach der Fehlermeldung auch offensichtlich vor.

Man sollte nicht "die MemoryFixes durchprobieren", man sollte *immer* AptioMemoryFix verwenden, wenn es läuft. Wenn Speicherallokierungsfehler auftreten, hier mit beeindruckenden 300(!) MB (erwarten würde ich max. 200 MB), sollte man *nicht* Fix20000 probieren, dieser Treiber ist Müll und kann zu allerhand Instabilitäten führen, sondern diesen hier: https://github.com/ReddestDream/OcQuirks/

Der Treiber basiert auf unserem aktuellen OpenCore-Code und enthält einen optionalen (standardmäßig *aus*!) DevirtualiseMmio-Quirk, der auf neuen Systemen (vorallem mit Thunderbolt) diese Probleme dramatisch verringern kann. Der Treiber wird von uns aber *nicht* unterstützt, dafür müsste man schon OpenCore direkt nutzen, wo das ganze über die Config angepasst werden kann.

macdream Genau. "Uns" meint Acidanthera

Meine aussage zu falsch ist eigentlich zu dem hier..
OsxAptioFix3Drv = OsxAptioFix2Drv + "EmuVariableUefi-64.efi"

wenn du den OsxAptioFix3Drv. efi drinne hast brauchst du doch keine zusätzliche EmuVariable.. der ist doch mit der Fix3 dabei..

Naja..

Habe ich beim schnellen Lesen wohl falsch verstanden, weil ich das noch nie irgendwo gelesen habe, stimmt aber genauso wenig.

EDIT: Achso, und verlesen habe ich mich offenbar auch nicht:

Zitat

EDIT: Das heisst das der EmuVariableUefi-64.efi nur mit OsxAptioFix2Drv etwas tut, alleine oder mit den anderen zusammen nutzlos ist.

Indem fall bemerke ich das was wir die ganze zeit predigen wohl alles falsch ist..

Klär uns doch bitte mal auf Fritz was das ganze mit diesen 3-4 verschiedenen Memory Fixe auf sich hat. Was bedeuten die, welcher ist wann zu benutzen, warum gibt es eben die in 3-4 Ausführungen?

Wäre sicher ne grosse hilfe.

Gruss Coban

AptioFix1: Nutzt einen Relocation-Block. Der Kernel wird *nicht* an die von boot.efi angefragte Position kopiert, sondern an eine beliebige, und dann vor dem Kernelstart "zurückkopiert" (an die eigentliche Zielstelle). Kann theoretisch Runtime-Speicher überschreiben und zu unerwarteten Adressen (bis dato kein Problem) in Boot-Args, Device Tree und Konsorten führen. Gehört in den Müll.

AptioFix2: Kein Relocation-Block. Das erfordert, dass die Zielposition frei ist. Gehört in den Müll, siehe nächste Beschreibung.

AptioFix3: AptioFix1 und AptioFix2 verhindern, dass Runtime-Data-Spannen von boot.efi verschoben werden, fixt NVRAM für Aptio 4. AptioFix3 verhindert zusätzlich, dass RT-Code verschoben wird, fixt NVRAM für frühe Aptio 5. Es gibt keine Nachteile gegenüber AptioFix2.

AptioMemoryFix: Puh, es gab diverse Kleinigkeiten gegenüber AptioFix2 (AptioFix3 ist ein Backport von ein paar der AMF-Änderungen gegenüber AF2), an die ich mich nicht mehr erinnere. Die Änderungen, auch wenn ich mich nicht mehr an sie erinnere, sind alle sinnvoll. Bringt geneüber allen anderen AFs eine automatische Slide-Berechnung mit, die auf manchen Systemen aber etwas wackelig ist. Dies kann in sehr, sehr seltenen Fällen zu stastistischen Nachteilen (fehlerhafte Bootversuche) gegenüber AF3 führen, aber in diesen Fällen laufen *beide* nicht rund. Wenn AF3 rundläuft, läuft AMF ebenfalls rund, nur, dass es die vorig genannten Änderungen beinhaltet.

OcQuirks: Die Evolution von AptioMemoryFix, ein externer Treiber, der unsere OpenCore-Bibliothek aufruft. Die Slide-Berechnung wurde korrigiert und "DevirtualiseMmio" hilft sowohl dabei, als auch bei Systemen, die sonst auf free20000 angewiesen wären. Wäre der Treiber nicht "privat" verwaltet (außerhalb von Acidanthera), würde ich diesen bedingugslos empfehlen... so empfehle ich ihn technisch, aber auf eigene Gefahr.

free20000: Pflügt einmal über den Speicher und gibt beliebige (teils wichtige) Regionen einfach frei, nicht der Rede weg, in den Müll.

Danke Fritz

Also Fixt der AptioFix3 auch den Nvram, klar, ist halt auch alt. das der AptioMemoryFix & FwRuntimeServices.efi neuer und moderner ist das ist wohl auch klar.

Gruss Coban

Wie meinst du das vom anderen Platte starten? Wenn du das von einem anderen Os aus tust bist du nicht der Besitzer dieser Partition oder Ordner, daher die Fehlermeldung.

Gruss Coban

Aa jetzt.. das ist der SIP der verhindert, für den müsstest du

Filesystem Protections: disabled haben.

Gruss Coban

Genau, im Moment ist da die Clover Entwicklung noch nicht so weit denke ich, die kriegen das schon sicherlich irgendwie hin.

Sip ausschalten, -rw mounten, Clover aktualisieren, Sip einschalten. rw behebt sich nach neustart.

Gruss Coban

Guck, damit der Hack mit aktivierter SIP und ohne sorgen laufen kann muss wirklich fast alles passen,

mit passen mein ich der muss sagen wir mal so salopp 99% dem originalem Apple Hardware angenähert sein.

Dafür musst du eben all die problem stellen fixen.

Ich kenne leider deine Hardware nicht aber es gibt sicherlich viele Leute die das schon hinbekommen haben und dir Unterstützung anbieten.

Ansonsten muss man sich halt bissl der Materie einlesen.

Hackintosh ist halt Geduld Sache

Gruss Coban

macdream Ich habe zu OcQuirks geraten, wie gesagt, wegen dem DevirtualiseMmio-Quirk, der standardmäßig *de*aktiviert ist. Da wäre es doch naheliegend herauszufinden, wie man ihn aktiviert (an/aus) und konfiguriert (Whitelist), oder?