Beiträge von itisme

  • OpenCore Sammelthread (Hilfe und Diskussion)

    Ich würde behaupten, dass man seeeeeehr lange suchen muss, um ein derart gutes und auch derart gut dokumentiertes Software-Produkt zu finden.


    Von dem her einfach als kleinen "Gegenpol" mal ein FETTES DANKE an alle, die für OpenCore (mit-)verantwortlich sind!


    :thumbup: :danke2::thumbup::klatschen::thumbup:

  • OpenCore Sammelthread (Hilfe und Diskussion)

    OpenCore 0.6.9 bootet High Sierra bei mir in der Version 17G65 problemlos, sobald ich aber das Security-Update 2020-005 (sowohl als DMG als auch über den AppStore) eingespielt habe startet der Picker direkt nach der Picker-Auswahl von High Sierra wieder neu.


    Das Log-FIle endet bei "05:207 00:007 OCB: LoadImage failed - Security Violation".


    Das hier - bei einem funktionierendem Boot - fehlt alles:


    Code
    1. 22:164 05:650 AAPL: #[EB.H.IS|!] Err(0xE) <- RT.GV boot-signature 7C4
    2. 22:173 00:008 AAPL: #[EB.H.IS|!] Err(0xE) <- RT.GV boot-image-key 7C4
    3. 22:174 00:001 AAPL: #[EB|H:IS] 0
    4. 22:175 00:001 AAPL: #[EB|LOG:INIT] 2021-06-06T14:58:46
    5. 22:177 00:001 AAPL: #[EB|VERSION] <"boot.efi 495.100.13~59 (Official), built 2021-05-08T05:55:31-0700">


    Hat da zufällig jmd. ne Idee?

  • [gelöst] Mehrere macOS-Versionen auf einer Platte (ohne dass diese sich gegenseitig schrotten)

    Das war ein APFS-Volume, das stimmt. Wenn ich mir die Partitionstabelle dann aber unter Linux anschaue ist auch dieses APFS-Volume - das sich ja auch in einem separaten Container befindet - tatsächlich eine separate Partition.


    Ich kann die Partition für HS ja mal mit HFS formattieren, vllt. hilft das ja.


    Wobei das ja trotzdem nichts daran ändert, dass für HS nach wie vor die vorhandene BS Partition sichtbar und "angreifbar" bleibt.

    Um das zu verhindern müsste ich wohl den APFS-Support unter HS disablen, oder gibt es ne bessere Idee dazu?

    (die Partition zu "deaktivieren" funktionierte leider nicht)

  • [gelöst] Mehrere macOS-Versionen auf einer Platte (ohne dass diese sich gegenseitig schrotten)

    Und was verhindert nun, dass HS doch auf die BS Partition, bzw. dessen Container, zugreift und diesen zerschießt?

    Denn genau wie ihr es beschreibt hatte ich die HS-Partition ja angelegt (kein Volume).


    Ich hab das eben auch noch einmal verifiziert:


    Es wird dann im Falle von APFS ein neuer Container angelegt, wenn ich aber ein anderes Filesystem (z. B. XFS) drauf packe erscheint die Partition als "disk0s3", von dem her sollte das ja gepasst haben.


    Da pfuscht also tatsächlich was anderes mit rein, nur was?

  • [gelöst] Mehrere macOS-Versionen auf einer Platte (ohne dass diese sich gegenseitig schrotten)

    Hallo :)


    ich würde gerne die Thematik von gestern nochmal aufgreifen und hab ihr deshalb mal nen eigenen Thread spendiert.


    Wie schon beschrieben kann z. B. High Sierra nicht sauber mit unter Big Sur erstellten APFS-Containern umgehen, was letztlich dazu führt, dass z. B. Daten aus dem Big Sur System einfach verloren gehen und Big Sur nicht mehr gestartet werden kann.



    Hat es denn von Euch schon jemand hinbekommen, unterschiedliche macOS-Versionen auf ein und derselben Platte nebeneinander zu betreiben?


    Ich könnte mir vorstellen, dass das schon funktionieren könnte, wenn man z. B.


    - die Partitionierung entsprechend vornimmt oder

    - in einem alten macOS die neuen Laufwerke / Partitionen ausblendet, damit kein Zugriff stattfinden kann

    Zitat von CMMChris

    ein echte Partition und damit ein separates APFS Konstrukt zu nutzen

    - wie würde das praktisch ablaufen, sprich wo partitioniere ich was und wie?


    Was meint ihr?



    Edit (Lösung):


    Als ich die Big Sur macOS Partitionen unter High Sierra per

    Code
    1. sudo -i
    2. cd /etc
    3. vifs

    per Eintragen der Volume UUIDs vom Automount ausschloss konnten HS und BS parallel auf der Platte existieren! :)


    Die IDs bekommt man per diskutil info /Volumes/MOUNTPOINT | grep "Volume UUID"


    Ein Eintrag sieht dann z . B. so aus:


    Code
    1. UUID=12345678-1234-1234-1234-123456789012 none apfs rw,noauto

  • OpenCore Sammelthread (Hilfe und Diskussion)

    Zitat von apfelnico

    hätte ein weiterer "Container" völlig gereicht.

    Meine Platte sieht aus dem BS-Recovery derzeit so aus:


    SK Hynix

    - Container disk1

    - - macOS

    - - macOS - Daten

    - Container disk2

    - - HS

    - Win10 Pro

    am Ende noch ne kleine Linux-Partition


    Da liegt HS - wie es aussieht - zwar in einem eigenen Container, aber helfen tut das erst mal auch nichts.


    Zitat von DerTschnig

    Einfach big sur vom bootstick odef von der recovery drüberlaufen lassen.

    Ich installier einfach mal drüber, wobei schon interessant wäre, was da auf den - eigentlich ja voneinander getrennten - Partitionen passiert und warum OpenCore das nicht sauber trennen und starten kann.


    Edit #01: HS läuft nach dem Drüber-Installieren wieder. Wenn ich da meine Tests abgeschlossen habe kommt BS dran und HS wieder weg. ;)


    Edit #02: Wie CMMChris schon sagt vermurxt HS tatsächlich das BS-System - bzw. eben die APFS-Container. Nach den Installationen konnte ich wieder ein paar Mal beide Systeme starten, bis dann auf einmal wieder nur HS funktionierte und OpenCore kann dann auch nicht mehr finden, was nicht mehr da ist ;)


    Ein großes DANKE AN EUCH ALLE! :):thumbup:

  • OpenCore Sammelthread (Hilfe und Diskussion)

    N´abend :) Vllt. hat jmd. auf die Schnelle ne Idee:


    Ich hab von Big Sur aus ne neue Partition (BS-Partition verkleinert) angelegt, auf die ich testhalber High Sierra installiert habe.

    Im OpenCore (v0.6.9) Picker wird mir nun neben HS statt dem "macOS" (Big Sur) System "macOS - Daten" angezeigt.

    Dieser Eintrag startet aber nicht Big Sur, sondern führt zu nem Reboot.


    Hat nun die HS-Installation meine Big Sur Start-Platte zerstört, oder bekomme ich den OC-Eintrag für BS wieder hin?

    Im Moment kann ich nur HS booten, an der lokal liegenden EFI-Partition hatte ich für HS nichts ändern müssen.


    Was ich unter HS noch gemacht (bzw. zu machen versucht) habe war, alle anderen für HS nicht benötigten, im Festplatten-Dienstprogramm angezeigten, Partitionen zu "deaktivieren". Das konnte HS aber wohl nicht umsetzen oder hat irgend etwas Seltsames, nicht Nachvollziehbares damit gemacht. Keine Ahnung.


    Vielleicht kann ich ja nen manuellen BS-Boot-Eintrag setzen? Auf welche Datei müsste dieser zeigen?

    (<macOS>/System/Library/CoreServices/boot.efi ?)


    In die jeweiligen lokalen Recoveries von HS und BS kann ich booten, falls ich hierüber was ausrichten kann.


    Nach dem Security-Update 2020-005 unter HS bootet nun auch dieser Eintrag nicht mehr.

    Die letzte OC-Log-Datei sagt mir: "LoadImage failed - Security Violation"

  • Welche WebCam ohne Drittanbieter mit eigener Cloud betreibbar?

    Danke für Deinen ausführlichen Bericht, atl ! :thumbup::)


    Zum einen muss die Qualität der Bilder passen, die Logik bei Bewegungen und dann möchte ich die Fotos/Videos z. B. per SSH, telnet oder so, sicher und schnell z. B. in ne Cloud verschieben.


    Was die Qualität und Logik betrifft hab ich das bei ctronics z. B. schon recht gut gesehen, da sind dann bei Bewegung ein paar Sekunden vorher noch auf der Aufnahme mit drauf, wenn ich das richtig weiß.

    Da finde ich Preis/Leistung schon Klasse, wenn die das bei etwa 50,- EUR schon so gut machen.

    Ob die dann z. B. mit nem Raspi und fswebcam zusammenarbeiten weiß ich allerdings nicht.

  • Wie patcht ihr eigentlich Eure iMacs? | OpenCore am iMac?

    Ah, ok, ist dann im Vgl. zum micro-patcher tatsächlich ein Vorteil, die Updates aus dem System heraus aufrufen zu können. :thumbup:

    Beim micro-patcher hab ich es bisher immer über einen Full-Installer eingespielt und die Scripts erneut laufen lassen.


    Vorteile beim micro-patcher würde ich dann darin sehen, dass ich ohne Option-Taste starten kann und vmtl. nicht ganz so viele Manipulationen stattfinden, daher wohl auch der Name "micro"-Patcher ;-)