macOS Catalina Startfähigen Stick für macOS "El Capitan" erstellen

mein script funktioniert auf allen Macs, auch Intels
Hatte ich nicht getestet, aber stark vermutet. ;)
Ich fürchte allerdings, dass das den TE u. U. überfordern könnte, wenn man den bisherigen Verlauf mit createinstallmedia.... betrachtet.
 
das wird nicht kommen. Und xattr benötigt man nicht bei Aufruf mittels sh oder per copy&paste oder per shell pipe oder ...

Mir ist schon mehrmals begegnet das selbst Textdateien in VSCode nicht zu öffnen waren, wenn ich sie lokal übers Netz verschoben hab, zum Beispiel per Screen Sharing. Und erst durchputzen per xattr -c half.
Bin dadurch sehr vorsichtig geworden.

Und was Sequoia jetzt veranstaltet ist schon mehr als nervig, kaum ein Script läuft, ohne das man es explizit unter Security einzeln freigibt. Ich weiß, das man das generell abschalten kann, bringt mir aber nichts, wenn die Projekte bei Andern laufen sollen muss ich das mitbekommen.
 
Lieber TE, also @Yaep

du kannst auch ohne Terminal einen Installationsstick erstellen, sogar komplett in KlickiBunti...schaue einfach zurück auf meinen Beitrag #36
 
Als klarer Verfechter der Apple-eigenen Hausmittel habe ich heute auf dem MP3.1 @ Lion die EC-Install.dmg aus #18 heruntergeladen, entpackt und dann in den Ordner Programme installiert.
Der Stick war vorbereitet mit Name MyVolume, Format Mac OS Extendet (Journ...) & Schema GUID und steckte im Mac.

Terminal geöffnet, mich eingeloggt und dann den Befehl mit Copy & Paste
sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app
eingefügt, PW blind eingegeben, bestätigt, Abfrage mit 'y" + Enter bestätigt und eine Schallplattenlänge später war der EC-Installstick fertig.

EC-Stick @Terminal.png

EC-Stick @Terminal-02.png

+1 für so einfach und kurz wie möglich…
Mit der Vorgehensweise sehe ich Deine Anforderung einfach & kurz mehr als erfüllt an. ;)

Ein Anfangsschritt Richtung Installation bis hin zur Auswahl des Datenträgers war ohne Problem möglich - weiter bin ich halt nicht gegangen, da ich keine leeren Datenträger hatte.
Der Stick bootete nach Neustart bis zum Auswahlmenü - Weitergehendes erspare ich mir.

Das sollte der TE auch schaffen, wenn Lion bereits als Ausgangslage besteht.
 
Und was Sequoia jetzt veranstaltet ist schon mehr als nervig, kaum ein Script läuft, ohne das man es explizit unter Security einzeln freigibt. Ich weiß, das man das generell abschalten kann, bringt mir aber nichts, wenn die Projekte bei Andern laufen sollen muss ich das mitbekommen.

das kann ich nicht nachvollziehen. Ich muss kein script irgendwo frei geben und ich habe keinerlei security settings deaktiviert.

Wo bzw wie hast du Probleme?
 
das kann ich nicht nachvollziehen. Ich muss kein script irgendwo frei geben und ich habe keinerlei security settings deaktiviert.

Wo bzw wie hast du Probleme?

Sämtliche Skripte meines Dumper Pakets müssen einzeln freigegeben werden. Die Dateien sind im iCloud Drive.
Selbst ein .png wurde in Quarantäne geschickt (!)

Alles, was ich durch runterladen installiere (letztes Beispiel: OpenOffice) genauso.

Sequoia, Silicon.png

png in quarantine.png
 
Sämtliche Skripte meines Dumper Pakets müssen einzeln freigegeben werden. Die Dateien sind im iCloud Drive.

okay, dann weiß ich was du meinst, bzw. wieso das bei dir auftritt.

Du erstellst ein script / binary auf einem Mac, lädst das auf einen Speicherplatz im web (hier iCloud, kann auch jeder andere Space im web sein) hoch und lädst dass dann wieder runter, vornehmlich auf einem anderen Mac.

Du hast kein offizielles developer cert, so dass durch das hochladen und anschließende runter laden, dein scipt / binary als nicht signiert erkannt wird, mit der Folge, dass eben Gatgekeeper das meldet. (jetzt bei macOS 15 via Systemeinstellung, vorher mit 2 x Rechtsklick + öffnen). Es leigt also nicht an eigenen Scripten und Restriktionen, sondern daran, dass du deine scripte durch das hochladen als "fremd ohne Signatur" kennzeichnest.

Es gibt mehrere Vorgehen, die für Entwickler zu empfehlen sind:

Das einfachste:
Lade deine scripte / binaries nicht auf webspace / Clouds hoch, sondern nimm ein NAS / Dateifreigaben

Eine Variante für Entwicklungen:
Verwende für source codes von binaries oder für script einfach github oder ganz banal ein lokales "bare" git Verzeichnis auf einem NAS. Da hast dann zusätzlich auch noch Versionskontrolle.

Willst du für andere User was anbieten hast du die zwei bekannten Varianten: ein Dev Cert von Apple, oder eben eine Anleitung für die User deiner Scripts. Aber für eigene Scripte, tritt es halt nur auf, wenn du webspace nimmst (nicht bei git)

Und zu OO: wenn du natürlich Software nuztzt, deren developer keine Lust haben, sich ein Dev Cert zu besorgen, dann musst du halt damit leben. Bitte jetzt keine Diskussionen über die 99 EUR p.a. Das entscheidet jeder Entwickler selbst. Wer das eben nicht macht, muss den den Reklamationen / Fragen seiner User leben. Für eigene Sachen gibt es andere Möglichkeiten.
 
Apple's nächste macOS-Version wird dann: "Hasta La Vista Baby" heißen.

sorry, aber auf sowas reagiere ich allergisch.

Wenn man seine eigenen Scripte auf fremden webspace hochlädt, ohne sie zu signieren, setzt man selbst die Grundlage, dass dieses Scripte eben als "fremd und unsigniert" angesehen werden.

Es gibt weit verbreitete Standards für Entwickler bei denen dies nicht auftritt. Man muss sie halt nur nutzen.

Ich hatte dich eigentlich für so kompetent gehalten, dass du das weißt und nicht in das hier im Forum so verbreitete dumpfe und von Wissen befreite Apple-Bashing einsteigst.

Aber da hier im Thread nun wieder mal lieber sinnloses bashing betrieben wird, entweder weil man nicht weiß, wie man solche Dinge angeht, oder weil man "cool" und "hipp" sein will, anstatt faktenbasierte und auf Wissen basierte Infos austaucht.... ich lass euch alleine weiter meckern und bashen.

Viel Spaß noch.
 
Bei mir wäre der Entwickler Account nicht das Hinderniss. Bringt mich beim Dumper eben auch nur einen halben Schritt weiter, weil Flashrom und DirectHW sowas von die Malware Scanner triggern. Und ja, in den App Store würde der Dumper es nie im Leben schaffen :)
 
okay, dann weiß ich was du meinst, bzw. wieso das bei dir auftritt.

Du erstellst ein script / binary auf einem Mac, lädst das auf einen Speicherplatz im web (hier iCloud, kann auch jeder andere Space im web sein) hoch und lädst dass dann wieder runter, vornehmlich auf einem anderen Mac.

Du hast kein offizielles developer cert, so dass durch das hochladen und anschließende runter laden, dein scipt / binary als nicht signiert erkannt wird, mit der Folge, dass eben Gatgekeeper das meldet. (jetzt bei macOS 15 via Systemeinstellung, vorher mit 2 x Rechtsklick + öffnen). Es leigt also nicht an eigenen Scripten und Restriktionen, sondern daran, dass du deine scripte durch das hochladen als "fremd ohne Signatur" kennzeichnest.

Es gibt mehrere Vorgehen, die für Entwickler zu empfehlen sind:

Das einfachste:
Lade deine scripte / binaries nicht auf webspace / Clouds hoch, sondern nimm ein NAS / Dateifreigaben

Eine Variante für Entwicklungen:
Verwende für source codes von binaries oder für script einfach github oder ganz banal ein lokales "bare" git Verzeichnis auf einem NAS. Da hast dann zusätzlich auch noch Versionskontrolle.

Willst du für andere User was anbieten hast du die zwei bekannten Varianten: ein Dev Cert von Apple, oder eben eine Anleitung für die User deiner Scripts. Aber für eigene Scripte, tritt es halt nur auf, wenn du webspace nimmst (nicht bei git)

Und zu OO: wenn du natürlich Software nuztzt, deren developer keine Lust haben, sich ein Dev Cert zu besorgen, dann musst du halt damit leben. Bitte jetzt keine Diskussionen über die 99 EUR p.a. Das entscheidet jeder Entwickler selbst. Wer das eben nicht macht, muss den den Reklamationen / Fragen seiner User leben. Für eigene Sachen gibt es andere Möglichkeiten.

Bei mir wäre der Entwickler Account nicht das Hinderniss. Bringt mich beim Dumper eben auch nur einen halben Schritt weiter, weil Flashrom und DirectHW sowas von die Malware Scanner triggern. Und ja, in den App Store würde der Dumper es nie im Leben schaffen :)

Ja, und wenn ich das iCloud Drive mit meiner Apple ID nutze. (ständig, mit diversen Macs unter diversen OS, was der Natur des Projekts geschuldet ist). Dann sollte der Gatekeeper das mMn in Ruhe lassen. Aber da haben wir keinen Einfluss drauf.

Wenn es nur um mich persönlich gehen würde, wäre der abgeschaltet, aber ich muss ja sehen wie das beim User reagiert. Der Mechanismus geht doch nach hinten los, wenn, sagen wir mal PowerUser dazu getrieben werden, den Gatekeeper abzuschalten. Weil sie, wie in meinem Fall, selbst Grafikdateien in Quarantäne schicken…

Bis jetzt lässt ein runterladen mit curl den Gatekeeper aussen vor. Deshalb auch mein Beispiel mit Deinem Script.
 
Wenn das so weiter geht braucht man doch Optimierungssoftware am Mac...

Das nächste ist dann, dass so eine halbe Malware dann den Meister spielt und sich damit rühmt Programme und Dateien zu "Unlocken", dass man sie wieder starten kann. :hum:

MacKeeper lässt grüßen.

Ein wenig schiesst Apple da schon über das Ziel hinaus. (wobei ich keine idee habe wie es besser geht...)
 
... ich habe dein Eindruck, wir reden etwas aneinander vorbei

Ja, und wenn ich das iCloud Drive mit meiner Apple ID nutze. (ständig, mit diversen Macs unter diversen OS, was der Natur des Projekts geschuldet ist). Dann sollte der Gatekeeper das mMn in Ruhe lassen. Aber da haben wir keinen Einfluss drauf.

Clouds sind extern. Auch iCloud. Nimm ein NAS oder einfaches Dateisharing.

Oder nimm github oder ein lokales "bare" git repositiory. Damit kannst du auch problemlos all deine scripte zwischen all deinen Macs aktuell halten / syncen / abgleichen.

Weder mit NAS / Dateisharing noch mit git hast du irgendwelche Dinge rund um Gatekeeper.

Wenn es nur um mich persönlich gehen würde, wäre der abgeschaltet,

du musst es doch gar nicht abschalten. Sh oben.

aber ich muss ja sehen wie das beim User reagiert.

Das kommt einzig darauf an, wie du deine scripte einem User präsentieren willst.

Eine Anleitung / scirpt mit welchem mittels xattr das erledit wird, ist meines Erachtens sinnvoll, da es den Usern zeigt, dass man zum einen es individuell lösen kann ohne generell Sicherungsmaßnahmen zu deaktiveren und zum anderen hat es keinen negativen "Lerneffekt".

Du könntest auch, so wie du es gemacht hast, dein scripte einfach nicht ausführbar machen und dann deine User dazu anleiten es mit "sh script" zu starten. Da dein script nicht ausführbar ist, erhält es auch kein Quarantäne bit.

Oder (was ich allerdings für eher kritisch halte, da es einen negativen Lerneffekt hat, da man scripte direkt aus dem Netz ausführt ohne Chance sie vorher anzusehen) du machst das mit einer shell pipe. Auch da machst du dein script nicht ausfürhbar und sagst deinen Usern in der Anleitung sowas wie "curl https://domain.tld/dein.script | bash "

Somit...

Der Mechanismus geht doch nach hinten los, wenn, sagen wir mal PowerUser dazu getrieben werden, den Gatekeeper abzuschalten.

... ist es einfach nicht notwendig, Gatekeeper abzuschalten.

Weil sie, wie in meinem Fall, selbst Grafikdateien in Quarantäne schicken…

Dann haben deine Grafikdateien in den Unix-Rechten ein executable-bit gesetzt. Solltes du ein älteres NAS haben, dann kann dort aufgrund einer wenig Mac-kompatiblem Konfiguration jede Datei die vom NAS auf den MAc gelden wird, eben das executable bit erhalten, was wie du siehst, äußerst nervig ist. Hier leigt aber die Ursache eben eindeutig beim NAS und der dortigen samba-config.

Bis jetzt lässt ein runterladen mit curl den Gatekeeper aussen vor. Deshalb auch mein Beispiel mit Deinem Script.

Es wird auch weiterhin so sein. Egal wie sehr hier im Forum gebashed wird. Definitv. Schon alleine deswegen, weil es für die Apple-Systeme eine Entwicklungsplattform geben muss. Und die ist halt nun mal macOS.
 
Ein wenig schiesst Apple da schon über das Ziel hinaus. (wobei ich keine idee habe wie es besser geht...)

Sorry, da schießt Apple nirgends hinüber.

"Probleme" mit Gatekeepr kommen nur dann auf, wenn jemand ausführbaren Code von extern runterladen will, dessen Entwickler nicht will / nicht weiß, wie man diesen ausführbaren Code eben so gestaltet, dass es keine "Probleme" mit Gatekeeper gibt und dann seinen Usern nicht sagt, wie sie mit seinem Code umgehen sollen.
 
Sorry, da schießt Apple nirgends hinüber.

"Probleme" mit Gatekeepr kommen nur dann auf, wenn jemand ausführbaren Code von extern runterladen will, dessen Entwickler nicht will / nicht weiß, wie man diesen ausführbaren Code eben so gestaltet, dass es keine "Probleme" mit Gatekeeper gibt und dann seinen Usern nicht sagt, wie sie mit seinem Code umgehen sollen.

Mein Beispiel .png war ein screenshot, vom Sequoia Finder erzeugt. Mit Sicherheit hat da niemand ein Ausführ-bit gesetzt.
Das war auch nur ein Beispiel. Das geht kreuz und quer durch alle Dateitypen.
 
Mein Beispiel .png war ein screenshot, vom Sequoia Finder erzeugt. Mit Sicherheit hat da niemand ein Ausführ-bit gesetzt.
Das war auch nur ein Beispiel. Das geht kreuz und quer durch alle Dateitypen.

und was hat das png mit Gatekeeper zu tun? Kann man das Bild nicht ansehen oder beaebeiten?
 
und was hat das png mit Gatekeeper zu tun? Kann man das Bild nicht ansehen oder beaebeiten?
Ja, ich kann das Bild nicht öffnen.

btw:
Code:
ls -l /Users/user/Library/Mobile\ Documents/com\~apple\~CloudDocs/Scripts/Macschrauber\'s\ CMP\ Rom\ Dump\ 24-12-2024\ M1/Is\ damaged\ fix/Sequoia\,\ Silicon.png
-rw-r--r--@ 1 user  staff  193719 Dec 21 20:44 /Users/user/Library/Mobile Documents/com~apple~CloudDocs/Scripts/Macschrauber's CMP Rom Dump 24-12-2024 M1/Is damaged fix/Sequoia, Silicon.png
 
Ja, ich kann das Bild nicht öffnen

dann muss bei dir irgendetwas anderes im Argen liegen.

Screenshots haben zwar bei mir auch das quarantäne bit, aber ich kann alles problemlos öffnen und bearbeiten.
 
Zurück
Oben Unten