opencore mit OCLP

Danke für den Link!

...aber, da sich das Ganze für Laien wie mich doch nicht so ganz „ungefährlich“ anhört, mal eine kleine Noob-Rückfrage, ob ich das hier...

„...- config.plist: change csr-active-config to 6F020000 or FF0F0000 (having csr-active-config also in NVRAM >> Delete >> 7C436110-AB2A-4BBB-A880-FE41995C9F82)
- reboot...“

...soweit richtig verstanden habe:

noobshot.png
 
aber, da sich das Ganze für Laien wie mich doch nicht so ganz „ungefährlich“ anhört, mal eine kleine Noob-Rückfrage, ob ich das hier...
Versuch #17 da, das ist Noob freundlich.

Ich denke die Änderungen in der plist sind damit man die Preboot mounten und bearbeiten darf.
Vielleicht reicht ja auch schon der updatePreboot Befehl von diskutil?
 
  • Gefällt mir
Reaktionen: flyproductions
ich denke die Änderungen in der plist sind damit man die Preboot mounten und bearbeiten darf.
Vielleicht reicht ja auch schon der updatePreboot Befehl von diskutil?
Ja, vermutlich, und nee, irgendwie nicht. Ich hatte mal versucht, die Preboot Partition einfach so zu mounten. Da behauptet Terminal zwar, er hätte, aber auf dem Desktop sieht man nix.

Ja, versuche ich dann mall.
 
Versuch #17 da, das ist Noob freundlich.
Schade!

Screenshot 2023-03-24 at 11.11.37.png

Ich würde ja einfach mal das Single-Prozessor-Tray einschieben und das Ding installieren. Aber da hätte ich denn wieder Angst, dass das irgendwelche Probleme macht, wenn ich das nicht vollständig deinstalliert bekomme und danach wieder mit dem Doppelprozessor weitermache.

Also bleibt mir wohl doch nur die manuelle Methode. 😟

War das, was ich da in dem vorletzten Post gefragt hatte, denn richtig, bzw. kann ich das gefahrlos probieren?
 
War das, was ich da in dem vorletzten Post gefragt hatte, denn richtig, bzw. kann ich das gefahrlos probieren?
Das arrary drunter gehört mit zum key.
Ob das Ersetzen da richtig ist, kann ich nicht dir nicht sagen.
 
  • Gefällt mir
Reaktionen: flyproductions
Das arrary drunter gehört mit zum key.
Ob das Ersetzen da richtig ist, kann ich nicht dir nicht sagen.
Hmm, ich glaube, deutlich sympatischer wäre mir die Sache mit dem Intel Power Gadget und dem Single-Prozessor-Tray. Ich glaube, ich mache das so und schaue, dass ich das Gadget dann, zur Not manuell, wieder deinstalliert bekomme, bevor ich das Dual-Tray wieder einbaue.
 
Tja, Versuch mit dem Single-Tray hätte ich mir sparen können. Jetzt kam dann, dass der Prozessor generell nicht unterstützt wird.

...und der Rest ist mir irgendwie nicht ganz geheuer. Ich will mich nicht wegen einer kleinen kosmetischen Sache in die Gefahr begeben, mir mit irgendwelchen Hackintosh-Tricks meine Bootkonfiguration zu zerschießen. 😕

Sachen, bei denen ich nicht so wirklich verstehe, was ich da eigentlich mache, sind mir generell eher unsympatisch. 😉
 
Danke nochmal!

Ja, manche Sachen sind zwar so naheliegend, dass man ums Verrecken nicht drauf kommt. Aber, nein, es hat leider nicht fuktioniert: Im OC-Bootpicker erscheint noch der alte Name. Auch wenn ich die Platte im Startvolumes-Kontrollfeld auswähle.

Zwei Anmerkungen noch:
Der alte Name erscheint nur im OC-Bootpicker! Im (dank desaktivierten GOP-Treibers nun sichtbaren) nativen Bootpicker erscheint das Startvolume mit dem richtigen Namen.

Die Datenwiederherstellungssoftware R-Studio „sieht“ unter dem Device einen ein Partitions-Snapshot mit dem alten Namen.
 
Ich denke die Änderungen in der plist sind damit man die Preboot mounten und bearbeiten darf.
Vielleicht reicht ja auch schon der updatePreboot Befehl von diskutil?
So, nun doch noch Erfolg!

Ich habe es letztlich (auf einem geklonten System) genau so gemacht, wie unter dem Link beschrieben. Allerdings sind die Änderungen in der config.plist, vor denen ich solche Angst hatte, wie ich beim Bearbeiten des eigentlichen Volumes bemerkt habe, überhaupt nicht erforderlich. Die Preeboot-Partition lässt sich auch einfach so per Terminal mounten. Nur taucht sie eben nicht auf dem Desktop auf. Sondern nur unter /System/Volumes. Und man muss natürlich per Befehl-Umschalt-Punkt die unsichtbaren Dateien sichtbar machen. Aber das steht da ja auch.

Jetzt sehen die Namen im OC-Bootpicker jedenfalls aus, wie sie sollen. Danke also nochmal für den am Ende doch noch zielführenden Tipp! 👍
 
Zuletzt bearbeitet:
Sehe ich das richtig, dass OCLP 1.2.0 die (wohl irgendwie mit dem Kernel Debug Kit zusammenhängenden) Boot-Probleme, die viele Leute nach dem Update auf Sonoma 14.1 hatten, vollständig behebt?
 
Als Betroffener interessiert mich das natürlich auch...
 
Als Betroffener interessiert mich das natürlich auch...
Also, wenn man sich das komplette Change Log anschaut, sind da jedenfalls etliche Fixes dabei, die etwas mit den KDKs zu tun haben. Wobei das hier wohl das Wichtigste sein sollte:

„Resolves KDKless Macs failing to boot after updating from 14.0 to 14.x“

Soweit ich das verstanden habe, resultierten die Probleme wohl im Wesentlichen daraus, dass Macs, die Root Patches brauchten um eine Internetverbindung aufzubauen, wohl im Rahmen des Updates den aktuellen Kernel Debug Kit nicht herunterladen konnten und dann versuchten, einen Alten zu verwenden, der eben mit 14.1 nicht mehr funktioniert. Und da hing es dann. Die Root Patches werden ja durch ein Update regelmäßig gelöscht. Macs mit einem upgegradeten, also ohne Patch funktionsfähigen, WLAN-Modul sollten also normalerweise nicht betroffen sein. Ich hab mich allerdings nicht getraut, das zu probieren.

...und nochwas ist mir mit OCLP 1.2.0 aufgefallen: Der OC-Bootpicker bietet mir nach einem mit Standardeinstellungen neu gebauten OC nun auch meine Legacy-Windows-Installation an. Merkwürdigerweise gleich dreifach, obwohl Windows nur zwei sichtbare Partitions hat. Aber ich kann darüber tatsächlich booten. Das mit dem „OC kann kein Legacy-Windows“ scheint also durch zu sein.
 
Zuletzt bearbeitet:
Das Heist Das macs Ohne wlan Vorher Schon keine probleme mitt den update haben sollten ?
 
OCLP 1.2.0 installiert, danach das Update auf 14.1.1 geholt und - löppt! :)
 
Hatte vorhin einen seltsamen Zwischenschritt beim Update auf 1.2.0. Nach dem Installieren kam zuerst die Meldung dass ein Paket MDK 22G... mit über 600MB runtergeladen werden musste, Danach liefen die Post Install Patches durch. Als ich dann von 13.6 auf 13.6.1 updaten wollte, kam wiederrum eine OCLP Meldung, dass für das Upgrade auf 13.6.1 zuerst ein Paket MDK 22G330 geladen und installiert werden musste, danach lief das Update problemlos durch. War bei einem Mini von 2011, bei einem 2012 Mini waren keine zusätzlichen Pakete erforderlich
 
MDK... wurden bei meinem MBP 2011 auch heruntergeladen zum Root-Patch. Je nach Modell muss halt einiges von OC gerichtet werden, hier beim MBP ist es u.a. die AMD GPU (die ich dann eh wieder deaktiviere ;) ) usw.
 
  • Gefällt mir
Reaktionen: Saffire
Läuft das ganze mit der larmen IGPU überhaupt Vernünftig?
 
Ich bin gerade das erste mal zurück. ^^
war eine Prozedur aber hat geklappt.

Sonoma hatte krasse Grafikprobleme. z.b. Keine Videos. Nur flackerndes Schwarzes Fenster und der VLC Stürzt ab.
Zwischendurch einfach mal 20-50 Sekunden Gedenkpause bei stehendem Cursor.
Plötzlich komplett verzögerte Maus.
Root Patches mehrfach installiert - kein besserung.

Ventura läuft am MBP 9,1 deutlich besser.
 
Zurück
Oben Unten