Install-Stick Sonoma 14.4: Platzbedarf bei Einsatz von OCLP

nehm mal einen 16 GB Stick, lass den Patcher in den Fehler rennen
Ehrlich gesagt interessiert mich das weniger - war ja auch nicht Ausgangsthema. ;)

Welch ein netter Euphemismus. Aus OCLP-Sicht passt es aber: Allzeit bereit in jeder Lebenslage. ;)
der Patcher baut mit createinstallmedia den Stick.
So ist mein Satz in #57 auch zu verstehen.
Ich bezog mich mit den "naiven Glauben" auf uns beide und u. A. auf diese Aussage in #20 ...
Ich hatte eigentlich angenommen, dass der Patcher einen Originalen Installer baut.
und eben nichts hinzu-/einfügt, denn so klar war das hier
Und packt ein paar Files in das OS des Sticks in Packages
zum Zeitpunkt von #20 noch nicht, sondern ergab sich erst später durch die intensive Recherche.
Ich persönlich habe nicht (mehr) den Anspruch, alles, was da „hinter den Kulissen“ passiert, komplett zu „verstehen“. In vielen Fällen würde ich es vermutlich auch nicht wirklich verstehen.
Dito.
Aber zumindest "Auffälligkeiten" wie diese hier wollte ich schon zumindest grob hinterfragen. Hat sich ja jetzt geklärt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: T-easy
Ich bezog mich mit den "naiven Glauben" auf uns beide und u. A. auf diese Aussage in #20 ...
und eben nichts hinzu-/einfügt, denn so klar war das hier
Aber zumindest "Auffälligkeiten" wie diese hier wollte ich schon zumindest grob hinterfragen. Hat sich ja jetzt geklärt.


Yep,
Ich sehe es immer noch so:

- Schritt 1: Der OCLP Patcher Installer baut einen Stick mit createinstallmedia, das ist Original
- Schritt 2: Der OCLP Patcher fügt, je nach System, in das Boot-Betriebssystem (in /Library/Packages) des Installer Stick OS ein paar Dateien ein, um diese nicht runterladen zu müssen. Nennen wir es mal offline cache.

Der gebootete Stick ansich, nehmen wir mal an wir booten den auf einen supporteten Mac, ist 100% original. Die Dateien in /Library/Packages liegen ja nur rum. Die werden beim Booten des Installers nicht geladen, noch irgendwie beim Installieren behandelt. Der Stick wurde ja mit createinstallmedia gebaut.

- Schritt 3: Wir booten über OpenCore den Installer Stick, der installiert wie auf einer supporteten Maschine.
- Schritt 4: Das neu installierte OS bootet, die Kernel Extension AutoPkgInstaller wird durch OpenCore ins Ram eingebunden und geladen. Diese kext enthält code, welcher die root patches durchführt. Diese root patches brauchen ihre Komponenten, und wenn diese auf dem Stick in /Library/Packages gefunden werden, dann wird der root patch durchgeführt. Ansonsten werden die Komponenten aus dem Netz geladen. Wenn ich den root patch brauche um ins Netz zu kommen geht das nicht. Das "cachen" der Komponenten macht durchaus Sinn.



...Fehlt noch der Log von einem Versuch das Ganze auf einen Stick zu schieben, der 16GB hat und zu klein für den "Installer mit OCLP Paketen" hat.



Ich persönlich hab das nicht so richtig bemerkt, weil ich immer createinstallmedia benutze. Den Befehl mit Parameter (ist ja auch nicht viel ./createinstallmedia --volume "/Volumes/Name der Partition oder Stick" hab ich im Kopf, und in den Pfad gehe ich über cd - reinziehen in's terminal.

Weil ich immer den Installer auf eine Partition des OS setze. Das geht viel schneller und ich habe auf dem Rechner eine für einen unsupporteten Mac funktionsfähige "Recovery". Da sind dann keine Pakete drauf. Und meine Mac Pros häng ich beim Installieren ans Kabel, das funktioniert - und wenn nicht, so wie bei Sonoma 14.4 dann an einen USB-Ethernet Wandler.
 
Ich persönlich hab das nicht so richtig bemerkt, weil ich immer createinstallmedia benutze
Ich noch weniger - eben weil ich seit Jahren createinstallmedia verwende. Da gab es zwar mal kurz Tinu & noch ein anderes grafisches Tool, aber letztlich waren Terminal, create .. & dort MyVolume als fester Stick-Name das Werkzeug meiner Wahl.

Wer einen porentief OCLP-freien Stick haben möchte (soll es ja geben ;) ), darf den Stick nicht via OCLP erstellen, wie @Der Reisende richtigerweise in #42 festgestellt hat.

Insofern ja mal gut, dass das trotz anderlautendem Threadthema in voller Gänze durchdekliniert wurde. Hat zwar den Thread überproportional aufgebläht, aber im Gegensatz zu manch anderem Thread war es dieses Mal eine produktive "Aufblähung". :LOL:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: T-easy, dg2rbf, Macschrauber und eine weitere Person
Diese root patches brauchen ihre Komponenten, und wenn diese auf dem Stick in /Library/Packages gefunden werden, dann wird der root patch durchgeführt. Ansonsten werden die Komponenten aus dem Netz geladen. Wenn ich den root patch brauche um ins Netz zu kommen geht das nicht. Das "cachen" der Komponenten macht durchaus Sinn.
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" :drum:
D.h.: hier in Zukunft für jedes Mac-Modell/macOS-Version seinen eigenen (mit OpenCorePatcher.App erstellten) macOS-Installer-BootStick mit EFIBoot-"Blessing"
 
D.h.: hier in Zukunft für jedes Mac-Modell/macOS-Version seinen eigenen (mit OpenCorePatcher.App erstellten) macOS-Installer-BootStick mit EFIBoot-"Blessing"

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.
 
Da ja 95% der Kommentare sich auf den Einsatz in der OCLP-Umgebung beziehen, habe ich einen Admin gebeten, den Titel adäquat anzupassen - hierfür Danke.
 
  • Haha
Reaktionen: T-easy
Wer einen porentief OCLP-freien Stick haben möchte (soll es ja geben ;) ), darf den Stick nicht via OCLP erstellen, wie @Der Reisende richtigerweise in #42 festgestellt hat.
...nur macht man mit einem „porentief OCLP-freien Stick“ in einer nicht supporteten Maschine mit einem „modernen“ OS halt nix. Und für eine Supportete gibt es an sich keinen Grund, den Stick mit OCLP zu erstellen.
 
  • Gefällt mir
Reaktionen: dg2rbf
nur macht man mit einem „porentief OCLP-freien Stick“ in einer nicht supporteten Maschine mit einem „modernen“ OS halt nix
Wie kommst Du denn darauf?
Mach ich, seit OCLP existiert und ich es nutze: ein normal via Terminal erstellter Install-Stick und ein einziger OCLP-Stick passend zum nicht-unterstützten Gerät. ;)
Und für eine Supportete gibt es an sich keinen Grund, den Stick mit OCLP zu erstellen.
Aber darum ging es hier nicht (mehr), sondern darum, auf den Installstick direkt OCLP mit drauf zu packen, wenn OCLP gebraucht wird.
 
Respect!! An dem Thema wird sich aber mal so richtig abgearbeitet. Fast schon Sadomaso. :cool: ;)
 
Die Geister die er rief .... :p
 
  • Haha
Reaktionen: Der Reisende
Wenn ich den root patch brauche um ins Netz zu kommen geht das nicht. Das "cachen" der Komponenten macht durchaus Sinn.
Eben!

...und es sind ja nicht nur die Patch-Komponenten, sondern auch der passende Kernel Debug Kit, den OCLP (löblicherweise) offline auf dem Stick bereitstellt. Und, wenn der gebraucht wird, aber, aufgrund ohne Patch nicht verfügbarer Internet-Verbindung, nicht geladen werden kann, kann das halt durchaus „dramatische“ Folgen haben...

...wie man bei den Problemen, die es im Umfeld des 14.1-Updates gab, gesehen hat.

Ich verstehe dieses ständige latente Misstrauen gegenüber OCLP/OC absolut nicht. Natürlich muss es Sachen machen, die relativ weit in sensible Bereiche des Systems eingreifen. Sonst könnte es das, was es macht, eben nicht machen und es gäbe auf dem cMP nichts jenseits von Catalina. Wenn man ihm nicht über den Weg traut, dann darf man es halt nicht benutzen und muss sich mit dem begnügen, was ohne geht. Ich bin dankbar, dass es es gibt. Und, was es installiert, installiert es dann halt.
 
  • Gefällt mir
Reaktionen: dg2rbf und bobesch
Wie kommst Du denn darauf?
Mach ich, seit OCLP existiert und ich es nutze: ein normal via Terminal erstellter Install-Stick und ein einziger OCLP-Stick passend zum nicht-unterstützten Gerät.
Ja, so hast du genau das, was OCLP auf einen Stick machen würde. Nur eben in super unkomfortabel. Und wo genau ist da jetzt der „Vorteil“?

Ich glaube, Macschrauber hat recht: Du verstehst einfach nicht, wie das Ganze grundsätzlich funktioniert.

Aber darum ging es hier nicht (mehr), sondern darum, auf den Installstick direkt OCLP mit drauf zu packen, wenn OCLP gebraucht wird.
Ja, man sollte für jedes System, das nicht nativ auf der Kiste läuft, den Stick eben mit OCLP erstellen. Dann ist alles drauf, was drauf muss. Und, wenn der Stick dann größer sein muss als 16GB, obwohl der Installer nur 13,2GB groß ist, dann ist das eben so!

Ich verstehe absolut nicht, wo da das Problem ist.
 
  • Gefällt mir
Reaktionen: dg2rbf
Nur eben in super unkomfortabel.
Ansichtssache. Ich finde es komfortabler, weil es meine Belange abdeckt. ;)
Nicht unbedingt massentauglich: wer hat denn auch jedes Mac-OS von SL bis Sonoma auf einem eigenen Stick zu Hause im Fundus, dazu noch die Bootloader auf einem eigenen Stick? Oder wer hat denn auch so viel Altmetall rumstehen? Verschwenderisch in beiderlei Hinsicht, ich weiß. Aber mir gefällt's. :)

Du verstehst einfach nicht, wie das Ganze grundsätzlich funktioniert.
Och - da war ich aber nicht ganz allein auf weiter Flur. ;) So richtig klar war das Einigen nicht, weil auch bislang das ganze Prozedere doch nicht so hinterfragt wurde.
Durch meine Nachfragen, die sich ursprünglich auf eine andere Ausgangslage ohne jede Beteiligung von OCLP bezogen, der Thread aber eine andere Wendung bekam, ist doch eine konstruktive Diskussion & Recherche angestoßen worden. Jetzt sind wir hoffentlich alle ein bißchen schlauer, der Eine halt mehr, der Andere weniger.
Ist doch auch was wert, finde ich und wie @bobesch in #34 & #37 anmerkte. ;)

Du verstehst offenbar doch nicht, wie bei mir mein System funktioniert. Früher dachte ich mal, Du hättest es verstanden, aber da hatte ich mich wohl getäuscht.
man sollte für jedes System, das nicht nativ auf der Kiste läuft, den Stick eben mit OCLP erstellen.
Man kann, muss aber nicht - s. o. .
dann ist das eben so!
Würde ich denken wie Du, hätte es die schöne Diskussion womöglich gar nicht gegeben. Freu Dich doch mal über das Ergebnis. ;)

Ich verstehe absolut nicht, wo da das Problem ist.
Das ist offensichtlich, weil Du meine Ausgangsfrage nicht im Blick hast, die eine andere war als der Thread-Verlauf dann ergab.

Aber ich verstehe inzwischen Dein Problem nicht. Warum echauffierst Du Dich so? Was stört Dich?
Sei doch mal etwas toleranter und lass mich "alten Mann" es so handhaben wie ich möchte oder es für mich für richtig halte und dahingehend entscheide statt es so abzutun.
Ich schreibe Dir doch auch nicht vor, wie Du was zu handhaben hast.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: T-easy und dg2rbf
Ansichtssache. ich finde es komfortabler, weil es meine Belange abdeckt.
...nur merkst du halt, ob es das tut, im Zweifelsfall erst, wenn es zu spät ist!

So war dir also offenbar nicht klar, dass bestimmte speziell neuere Sonoma-Versionen auf entsprechende korrespondierende Versionen des Kernel Debug Kits angewiesen sind, die eben weder auf deinem „porentief OCLP-freien Stick“ noch auf deinem „OCLP“-Stick vorhanden sind. Und, wenn dein Rechner dann ohne Patches nicht ins Netz kommt, ist deine Installation eben vorbei, ehe sie richtig angefangen hat.

Nicht unbedingt massentauglich: wer hat denn auch jedes Mac-OS von SL bis Sonoma auf einem eigenen Stick zu Hause im Fundus, dazu noch die Bootloader auf einem eigenen Stick?
Vor allem hab ich bis heute keine konkrete Vorstellung davon, was sich auf diesem ominösen Stick befindet. Der Bootloader ist ja nicht OCLP, sondern eine von OCLP konfigurierte OpenCore-Version und gegebenenfalls irgendwelche Assets, die für eventuell benötigte Patches beim Booten geladen werden müssen. OCLP ist nichts weiter als eine App, die dabei hilft, die erforderlichen Sachen zusammenzustellen und eine passende config.plist zu schreiben.

Der OC Ordner auf der EFI-Partition des Sticks oder eines beliebigen Volumes wird also immer nur auf genau diese Systemversion auf genau diesem Rechner passen! Worin in aller Welt besteht also der Sinn, den Installer und OpenCore auf zwei verschiedenen physischen Devices vorzuhalten? Dass OCLP die eigentliche Installer-App nicht anrührt, hat dir Machschrauber nun mehrfach ausgiebig erklärt. Du begibst dich damit also nur in das Risiko, im „Ernstfall“ wesentliche Sachen – wie eben z. B. einen notwendigen Kernel Debug Kit – nicht (offline) parat zu haben.

Aber ich verstehe inzwischen Dein Problem nicht. Warum echauffierst Du Dich so? Was stört Dich?
Es „stört“ mich nicht! Jeder kann von mir aus seinen Rechner in den Orkus schicken wie er möchte. 😉

Ich halte es nur eben für relativ gefährlich, zu glauben, Sachen „besser“ machen zu können oder zu „müssen“ als die Leute, die sie gemacht haben. Vor allem dann, wenn man die Funktionsweise nicht vollständig verstanden hat.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Install OCLP.... links und Patch .... rechts.
Ach ja, es heißt dort übrigens nicht „Install OCLP“ sondern „Build and Install OpenCore“...was ja auch dem entspricht, was tatsächlich passiert!
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich muss mal eine Lanze brechen für LuckyOldMan. Ich hatte Ihm sein Thema mit #4 quasi mit einem Trojaner versaut und er hat es trotzdem angenommen und ein toller Thread ist dadurch entstanden Daher spreche ich ihm mal alles Vorrecht zu, in seinem Thread auch seine individuelle Belange etwas mehr in den Vordergrund zu stellen, ohne sich dafür rechtfertigen zu müssen oder dem Zwang einer Allgemeingültigkeit zu unterliegen.

@flyproductions: Nicht böse gemeint und im Grunde der Sache ist dein Weg wohl pragmatisch. Wenn jemand aber andere Wege geht, dann finde ich das auch bereichernd und kann es auch so stehen lassen, selbst wenn es nicht mein Weg ist...und auch unabhängig davon, wie ich persönlich den Weg finde und ob ich ihn 100% nachvollziehen kann...
 
  • Gefällt mir
Reaktionen: flyproductions und LuckyOldMan
Ach ja, es heißt dort übrigens nicht „Install OCLP“ sondern „Build and Install OpenCore“...was ja auch dem entspricht, was tatsächlich passiert!
Ja, OCLP ist nicht OC. Ich glaube LOM meinte eher, dass da seitens einer Abfrage eine aktive Handung bzgl. des OCLP bei der Stick-Erstellung kommt und damit "offenkundig" die erste wirkliche Indivualisierung. Ist jetzt aber längst geklärt
 
es heißt dort übrigens nicht „Install OCLP“ sondern „Build and Install OpenCore
Ach Herrje - da war ich ein wenig schluderig. :rolleyes:

Auch wenn ich mir sicher bin, dass jeder mit der Materie Befasste es verstanden hat: ich hoffe, Du siehst mir nach, dass ich statt des kompletten „Build and Install OpenCore“ nur die Kurzform „Install OCLP ....“ geschrieben habe - mit den Pünktchen wollte ich mir als Tipp-Meister aller Klassen die ausführliche Tipperei ersparen. Das nächste Mal versuche ich mir mehr Mühe zu geben - versprochen.
Ich hatte Ihm sein Thema mit #4 quasi mit einem Trojaner versaut und er hat es trotzdem angenommen
Richtig - ich war gerade auf dem Weg, das noch nachzufügen und bin auch froh, es nicht abgeblockt zu haben.
Insofern auch mit ein Verdienst von @T-easy , dass er ins Lenkrad gegriffen hat. :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: T-easy
Ja, OCLP ist nicht OC. Ich glaube LOM meinte eher, dass da seitens einer Abfrage eine aktive Handung bzgl. des OCLP bei der Stick-Erstellung kommt und damit "offenkundig" die erste wirkliche Indivualisierung. Ist jetzt aber längst geklärt
Ich habe das nochmal so explizit herausgestellt, weil der glückliche alte Mann schon öfter die Begrifflichkeiten relativ wild durcheinander geworfen hat.

Es gibt eben keinen „OCLP-Bootloader“!

„Install OCLP ....“
Das ist eben aber genau nicht das was passiert! „OCLP installieren“ meint schlicht das Herunterladen der App. „Build and Install OpenCore“ meint das Konfigurieren von OpenCore und Kopieren auf die EFI-Partition irgendeines Devices.
 
  • Gefällt mir
Reaktionen: dg2rbf und T-easy
  • Love
  • Haha
Reaktionen: flyproductions und T-easy
Zurück
Oben Unten