Install-Stick Sonoma 14.4: Platzbedarf bei Einsatz von OCLP

der packt die AutoPkg-Assets.pkg in /Library/Packages vom Installer Stick
Und das passiert ungeachtet der macOS-Version? Hast Du das mit Sonoma auch schon durchgespielt? Und bleibt das auch ungeachtet dessen, dass ich Open Core nicht installiert haben möchte?

Wenn dem so wäre, fände ich das mehr als grenzwertig, weil dann der Wunsch des Nutzers klar missachtet wird. Das ist kein reiner Install-Stick, sondern es wird etwas hinzugefügt, was ich nicht haben wollte.
Wenn der Nutzer die Frage mit Ja beantwortet, ist das eine ganz andere Sache.
 
Ich habe eine Zwischenfrage zum Verständnis. Ein OCLP Bootstick wird doch erstellt um ein macOS, welches auf einem älteren Mac nicht unterstützt wird, trotzdem installieren zu können. Dann wird Open Core doch nach erfolgter Installation erwartet um die passenden Patches anzuwenden. Wenn du also Open Core nicht installiert haben möchtest, darfst du OCLP einfach nicht nutzen.

Mit OCLP lässt sich kein Boot-Stick erstellen, der OCLP nicht enthält soweit ich weiß. Könnte natürlich falsch liegen aber es wäre logisch für mich.
 
Wenn du also Open Core nicht installiert haben möchtest, darfst du OCLP einfach nicht nutzen.
Genau das ist der Punkt. Auch @Macschrauber war ursprünglich wie ich der Meinung, dass die später hinzugefügte Möglichkeit, via OCLP den Install-Stick zu erstellen, sich auf den reinen Install-Stick beschränkt.
Nun lese ich aber, dass es darüber hinaus geht, obwohl an entsprechender Stelle die Abfrage mit NEIN beantwortet wurde.

Mit OCLP lässt sich kein Boot-Stick erstellen, der OCLP nicht enthält
Wenn Du Dir das Bild #9 anschaust, dann ist der Vorgang "Build and Install Open Core" und "Create macOS Installer" getrennt. Da ist es für mich nicht logisch, dass OCLP bereits enthalten sein soll, denn die unterschiedlichen Vorgänge lassen keine unmittelbare Verknüpfung erkennen.

Wozu dann überhaupt die Abfrage, wenn bereits schon beim DL Vorbereitungen für die Nutzung des BL+Patcher gemacht werden? Wurde das transparent kommuniziert?

Was ist mit den macOS-Versionen, für die gar kein Patcher benötigt wird, weil unterstütztes Gerät? Egal - die bekommen auch mal ein "Kuckucksei" in den Installer hineingelegt!
Und bei anderen Entwicklern gibt es einen Aufschrei, wenn die den Nutzern etwas verdeckt unterjubeln, was der gar nicht "bestellt" hat und auch nicht haben will. :rolleyes:
 
Und das passiert ungeachtet der macOS-Version? Hast Du das mit Sonoma auch schon durchgespielt? Und bleibt das auch ungeachtet dessen, dass ich Open Core nicht installiert haben möchte?

Wenn dem so wäre, fände ich das mehr als grenzwertig, weil dann der Wunsch des Nutzers klar missachtet wird. Das ist kein reiner Install-Stick, sondern es wird etwas hinzugefügt, was ich nicht haben wollte.
Wenn der Nutzer die Frage mit Ja beantwortet, ist das eine ganz andere Sache.

Du hast das System noch nicht völlig verstanden.

Der verändert den Bootstick vom Inhalt her nicht. Es wird in /Library/Packages lediglich das 500 MB ungrad Patches Paket kopiert.

Wenn nach der Installation der Patcher Dienst aktiv ist (was vormals durch einen root patch passierte) ruft der die Patcher App in Application Support/Dortania auf.

Damit diese nichts runterladen muss (weil es das vielleicht nicht kann, weil das Netz nicht da ist, wegen fehlenden Patches) zieht es sich vom System des Installer Sticks die Patches.

Das wird durch eine kernel extension getan die OpenCore ins Ram während der frühen Bootphase lädt.

So bleibt der eigentliche Installer original, der wird (schau dir nochmal die Logs an in meinem Post) vom Patcher genauso per createinstallmedia gebaut. Nur wird später eben noch die Patches Datei in's Betriebssystem vom Installer Stick kopiert.

Also bleibts original.
 
  • Gefällt mir
Reaktionen: dg2rbf und bobesch
Genau das ist der Punkt. Auch @Macschrauber war ursprünglich wie ich der Meinung, dass die später hinzugefügte Möglichkeit, via OCLP den Install-Stick zu erstellen, sich auf den reinen Install-Stick beschränkt.
Nun lese ich aber, dass es darüber hinaus geht, obwohl an entsprechender Stelle die Abfrage mit NEIN beantwortet wurde.


Wenn Du Dir das Bild #9 anschaust, dann ist der Vorgang "Build and Install Open Core" und "Create macOS Installer" getrennt. Da ist es für mich nicht logisch, dass OCLP bereits enthalten sein soll, denn die unterschiedlichen Vorgänge lassen keine unmittelbare Verknüpfung erkennen.

Wozu dann überhaupt die Abfrage, wenn bereits schon beim DL Vorbereitungen für die Nutzung des BL+Patcher gemacht werden? Wurde das transparent kommuniziert?

Was ist mit den macOS-Versionen, für die gar kein Patcher benötigt wird, weil unterstütztes Gerät? Egal - die bekommen auch mal ein "Kuckucksei" in den Installer hineingelegt!
Und bei anderen Entwicklern gibt es einen Aufschrei, wenn die den Nutzern etwas verdeckt unterjubeln, was der gar nicht "bestellt" hat und auch nicht haben will. :rolleyes:


Da wird nichts untergejubelt.

Wenn du den Patcher OpenCore auf den Installer Stick installieren lässt, dann baut der die OpenCore ESP, so wie immer, und das Ziel ist einfach nur der USB Stick "Install MacOS".

Was später getan wird passiert im Ram, solange keine root patches aktiv sind.
 
  • Gefällt mir
Reaktionen: dg2rbf
und:

von wegen: wird nicht kommuniziert:

"OCLP will automatically root patch your system during a first time install if the USB install media was created within OCLP. Users will also be prompted to install these patches after macOS updates or whenever patches are not detected on the system. We recommend rebuilding OpenCore with the latest version of OCLP to take advantage of these new features"

Beitrag #30
 
  • Gefällt mir
Reaktionen: dg2rbf und bobesch
Du hast das System noch nicht völlig verstanden.
Das wird immer offensichtlicher, aber diese Tatsache missfällt mir, wenn auch aus anderen Gründen, weil ich bislang wie Du auch immer von einer anderen Faktenlage ausging.

Das habe ich auch jetzt gelesen, meinte ich aber nicht.
Wo wurde dem Nutzer in der Anwendungsbeschreibung erläutert, was bei Erstellung des Installers noch alles passiert?
Bislang wurde ich nicht fündig, muss aber nichts heißen.

Edit: Jetzt habe ich es gefunden- Da hätte ich es nicht vermutet, weil es in die OCLP-Thematik mit verwoben ist, der Befehl sich aber nur auf den Create macOS Installer bezieht. Es geht somit m. E. komplett unter. Ich war ja nicht der Einzige, der andere Vorstellungen über Create macOS Installer hatte.

Wie kann ich im Sonoma-Install-Stick diese AutoPkg-Assets.pkg finden? "Versteckte Dateien sichtbar machen" reicht wohl nicht oder ich suche an falscher Stelle.
 
Wie kann ich im Sonoma-Install-Stick diese AutoPkg-Assets.pkg finden? "Versteckte Dateien sichtbar machen" reicht wohl nicht oder ich suche an falscher Stelle.

Am schnellsten findest es im Dortania Ordner in Logs, während der Zeit als der Stick gebaut wurde.

Edit: der genaue Pfad: ~/Library/Logs/Dortainia/

die Library ist normal versteckt, ich bin ein Fan von cmd-shift-g, dann kann man, wie im Terminal anfangen zu schreiben und mit der Tab Taste die Pfade vervollständigen lassen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
die Library ist normal versteckt
Soweit ich das feststelle, ganz besonders versteckt.
Ich mag an sich Shortcuts auch, aber als begnadeter Tipp-Künstler breche ich mir da bei den Tasten-Kombinationen die Finger. Gibt es auch einen anderen Weg?
 
In den Darstellungsoptionen beim Benutzer

Bildschirmfoto 2024-03-28 um 18.05.23.png
 
  • Gefällt mir
Reaktionen: bobesch und flyproductions
Soweit ich das feststelle, ganz besonders versteckt.
Ich mag an sich Shortcuts auch, aber als begnadeter Tipp-Künstler breche ich mir da bei den Tasten-Kombinationen die Finger. Gibt es auch einen anderen Weg?
Gehe zu, im Finder menü.
 
  • Gefällt mir
Reaktionen: bobesch
  • Gefällt mir
Reaktionen: bobesch und kd31
Gibt auch noch n Setting:

Code:
defaults write com.apple.finder AppleShowAllFiles TRUE ; killall Finder
 
  • Gefällt mir
Reaktionen: kd31
Dafür gab es, oder gibt es noch?, eine kleine App, die genau diesen Befehl ausführte. True oder False.

Edit: ShowAllFiles hieß sie, ob die in neueren Systemen noch funktioniert, k.A
 
Die App, die im Ordner "Programme" lag, war 13.2 GB groß. Und dennoch sollten 16 GB dafür nicht ausreichen?
Ich nehme mal an, da wird ein gewisser Puffer für während der Installation geschriebene temporäre Daten freigehalten.

Ist ja schön, dass sich das Limit umgehen ließ und es geklappt hat. Ich persönlich würde da – in Zeiten, in denen es einen 32 Gig Stick für drei Euro neunundneunzig gibt – nicht mehr wirklich irgendein Risiko eingehen. Vor allem nicht, wenn das ein Rescue-Volume sein soll.
 
  • Gefällt mir
Reaktionen: bobesch
defaults write com.apple.finder AppleShowAllFiles TRUE ; killall Finder
LuckyOldMan oder: Wie ich lernte, das Terminal zu lieben. :LOL:

1711663307955.png


Soviel zum naiven Glauben Zweier, die dachten, der Patcher würde einen normalen Installer wie mit createinstallmedia bauen. Baut er auch, aber mit diversen Zutaten aus eigener Rezeptur.
Nun genug der OCLP-Wege.

Die Thread-Frage dreht sich nicht um die Niedrigpreise heutiger 32GB-Sticks, sondern weshalb plötzlich via Terminal & createinstallmedia 32GB erforderlich sind, obwohl die Install-App unter 16GB bleibt. Das wurde bislang nicht herausgefunden.
 
Dann nehm mal einen 16 GB Stick, lass den Patcher in den Fehler rennen und schau den Log an, vielleicht schreibt der seine Kalkulation rein.

Dass die Bonusfiles Platz brauchen ist ja logisch.

Und wieder: der Patcher baut mit createinstallmedia den Stick. Und packt ein paar Files in das OS des Sticks in Packages. Damit die auch offline Verfügbar sind. Der eigentliche Installer ist unverändert.
 
  • Gefällt mir
Reaktionen: bobesch und flyproductions
Die Thread-Frage dreht sich nicht um die Niedrigpreise heutiger 32GB-Sticks, sondern weshalb plötzlich via Terminal & createinstallmedia 32GB erforderlich sind, obwohl die Install-App unter 16GB bleibt. Das wurde bislang nicht herausgefunden.
Wie gesagt: Ich gehe davon aus, dass da für irgendwelche Operationen während der Installation (Entpacken gepackter Bestandteile des Installers, Schreiben von temporary files etc.) ein gewisser Freiraum auf dem Installationsmedium benötigt wird. Es ist eben nicht nur die Installationsdatei. Du würdest ja vermutlich auch kaum ein System auf einem Volume laufen lassen, das bereits mit dem nackten System bis auf’s letzte MB voll ist. Auch wenn das System „darauf passt“.

Um das genau „herauszufinden“, müsste man sich – nach einer erfolgreichen Installation – wohl mal ein Installation Log genau durchlesen (und verstehen!). Ich sehe nur eben – in Zeiten, in denen ein den Anforderungen entsprechender Stick fast nichts mehr kostet – nicht so recht den Sinn darin, um Probleme zu betteln, indem man die (ja vermutlich in irgendeiner Form technisch begründete) Anforderung umgeht.

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. Deshalb glaube ich selbst Apple ab und zu, dass sie sich schon etwas dabei gedacht haben, wenn es eine solche (Mindest)Anforderung gibt. Auch wenn sie sich mir spontan nicht erschließt. Aber das muss letztlich jeder halten wie er will.
 
  • Gefällt mir
Reaktionen: bobesch
Soviel zum naiven Glauben Zweier, die dachten, der Patcher würde einen normalen Installer wie mit createinstallmedia bauen. Baut er auch, aber mit diversen Zutaten aus eigener Rezeptur.
Nun genug der OCLP-Wege.
Ach so: Der Kernel Debug Kit ist keine „Zutat aus eigener Rezeptur“ (von OCLP), sondern kommt von Apple und ist für eine erfolgreiche Installation unter Umständen zwingend erforderlich! Die Installer App geht davon aus, dass der bei Bedarf aus dem Internet geladen werden kann. Wenn dein Rechner aber, z. B. weil dein WLAN ohne Patch nicht funktioniert, während der Installation keine Verbindung ins Internet aufbauen kann, war’s das dann und deine Installation hängt! Sei also froh, dass die den da mit drauf packen!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bobesch
Zurück
Oben Unten