Install-Stick Sonoma 14.4: Platzbedarf bei Einsatz von OCLP

[T-easy]

Ich denke, dass die Packages die draufgeschrieben werden universell sind.

Unterscheiden wird sich die ESP auf der OpenCore drauf ist. Wahrscheinlich nur durch die config.plist.
Aber ob ich jetzt 5 Installer Sticks für 5 verschiedene Rechner habe oder 1 Installer Stick und 5 Sticks mit unterschiedlichen OpenCore ESPs ist am Ende auch Banane :]

Es sei denn ich hab noch unzählige Mini Sticks rumliegen mit 1GB oder so. Da wird's aber wieder blöd, weil in Voreinstellung bei den Sticks (glaube es war 4GB) kein ESP beim Initialisieren geschrieben wird.

Meine Vorgehensweise ist übrigens, den Installationstick letzten MacOS mit dem OCPL auf eine 64GB ;-) Stick schreiben zu lassen, dort dann nach Anfrage auch den OC in ein EPS auf diesem Stick anzulegen.

Wenn dann das "Zielgerät"/'target model' der Installation abweicht von dem "Erstellergerät"/'host model', dann wähle ich über die OCLP-App bei 'Setting' > 'target model' noch das Zielgerät ein. Dann nochmal mit "Build and Install OpenCore" den OC auf den Stick aktualisieren.

Den Stick kann ich mit dieser Vorgehensweise auch beliebig oft und schnell wiederverwenden, muss aber nur drauf achten, welches 'Target Model' in meiner EPS durch OC hinterlegt ist. Leider habe ich das bereits öfters mal vergessen. Ist das fundamental abweichend, dann bleibt der Installer irgendwann hängen, ist das nur marginal - etwa MBP11,2 statt MBP12,2 - dann läuft zwar die Installation eher durch, aber die Treiber sind nicht korrekt - beispielsweise funktioniert dann die Tastatur nicht oder das WLAN uswusf. Daher habe ich mir angewöhnt, den Modelltyp aus dem letzten EC-Build immer auf dem Stick mit Bleistift aufzuschreiben, dann kann ich es nicht so einfach vergessen.

PS: Ich denke auch, diese für die meisten unbestritten praktische Integration von OCLP-Pkg und KDK ist auch erst zeit kürzerer Zeit so integiert worden, irgendwann ab den 0.6.x-ern denke ich.

 

[flyproductions]

PS: Ich denke auch, diese für die meisten unbestritten praktische Integration von OCLP-Pkg und KDK ist auch erst zeit kürzerer Zeit so integiert worden, irgendwann ab den 0.6.x-ern denke ich.

Die Relevanz des Kernel Debug Kit ist letztlich erst mit den Problemen mit 14.1 in den Fokus gerückt. Dass das automatisch abgeprüft und bei Bedarf vor dem Start eines Updates bzw. einer Installation heruntergeladen wird (solange es noch geht!), ist meines Wissens erst seit OCLP 1.4.0 der Fall. Für Monterey z. B. ist das wohl noch unerheblich.

 

[T-easy]

Genau so bei meinem late2008er c2duo MBP5,1 beim Installationsversuch mit "normalem macOS-Installer erlebt:
RootPatch braucht für's Funktionieren von WLAN/Ethernet Komponenten aus dem Netz, die nicht geladen/installiert werden können, weil WLAN/Ethernet nicht funktionieren.
Mit dem per OpenCorePatcher.App und "Create macOS Installer"/"Build and Install OpenCore" erstellten USB-Stick und den darauf versteckt installierten zusätzlichen Komponenten für's Patchen ist die Installation automatisch glatt durchgelaufen und Touchpad/Tastatur/WLAN waren beim Erscheinen des Begrüssungsbildschirms funktionsfähig. "So muss Technik"
D.h.: hier in Zukunft für jedes Mac-Modell/macOS-Version seinen eigenen (mit OpenCorePatcher.App erstellten) macOS-Installer-BootStick mit EFIBoot-"Blessing"

Beim MBP5,1 beachte noch folgendes: OTA-Updates funktionieren bei diesem Modell leider noch nicht - siehe hier
Der Patcher selbst möchte zwar, aber dadurch, dass du keinerlei Eingabegeräte hast, ist dann einfach Sense.

 

[T-easy]

Die Relevanz des Kernel Debug Kit ist letztlich erst mit den Problemen mit 14.1 in den Fokus gerückt. Dass das automatisch abgeprüft und bei Bedarf vor dem Start eines Updates bzw. einer Installation heruntergeladen wird (solange es noch geht!), ist meines Wissens erst seit OCLP 1.4.0 der Fall. Für Monterey z. B. ist das wohl noch unerheblich.

Stimmt wohl. Ich hatte den KDK vorher heruntergeladen (...wie z.b. auch die OCLP-App) einfach manuell auf der FP oder Installationsstick zusätzlich abgespeichert. Der Patcher wird halt immer komfortabler und denkt sozusagen für einen mit. Ich habe früher eine ellenlange "Gebrauchsanleitung" auf den Schreibtisch jedes gepatchten Mac gelegt, damit die Anwender(Familie, Bekannte, ...) eine Todo haben, falls sie sich überhaupt ein Update selbstständig zutrauen. Das kann ich mir jetzt sparen, bis auf einige Ausnahmen. Die größe Herausforderung besteht aktuell eher darin, dass die Updates auf v.a. älteren Geräten sehr zeitlich sehr lange brauchen, meist mehrere Stunden. Da reisst meistens dem unbedarften Anwender der Geduldsfaden und es wird ein Fehler vermutet, der Rechner ständig manuall neu gestartet uswusf. Dann kommt der Hilferuf 'Rechner kaputt' und ich antworte der Generation "TikTok" mit 'Hab Geduld'.

 

[Macschrauber]

PS: Ich denke auch, diese für die meisten unbestritten praktische Integration von OCLP-Pkg und KDK ist auch erst zeit kürzerer Zeit so integiert worden, irgendwann ab den 0.6.x-ern denke ich.

Ab 0.4.4, siehe Post 30, 31

Was ist bei dir die Abkürzung EC? Stände bei mir für El Capitan, macht aber keinen Sinn.

 

[flyproductions]

Der Patcher wird halt immer komfortabler und denkt sozusagen für einen mit.

Eben! In den meisten Fällen vermutlich deutlich besser als man selbst „denken“ könnte.

...und genau deshalb halte ich halt auch nicht viel davon, ihm ins Handwerk zu pfuschen.

Aber das ist natürlich nur meine ganz persönliche unmaßgebliche Meinung, die keinesfalls für jedermann der richtige Weg sein muss! 😝

 

[flyproductions]

Was ist bei dir die Abkürzung EC? Stände bei mir für El Capitan, macht aber keinen Sinn.

Hab ich mich auch die ganze Zeit gefragt. Mit O statt E würde es deutlich mehr Sinn machen. Beim ersten Mal glaubte ich an einen Tippfehler. Aber das ist ja praktsich durchgängig.

 

[T-easy]

Natürlich Tippfehler EC meinte OC.

Da habt ihr mich wieder mal. War aber nur in dem einen Beitrag. Habe ich schläfrig im sonnigen Wintergarten auf der Couch verfasst, zudem auf einem MB8,1 - da sollten mildernde Umstände gelten. Habe es mit 'Bearbeiten' korrigiert.