MP5.1, OCLP, High Sierra, Ventura und diverse Nebenwirkungen

Somit vermischt du aber unterschiedliche Systeme.

So wie bei mir mit Monterey und Ventura mag das noch funktionieren. Siehe die beiden Systemordner in /Preboot.

Wenn der Aufbau der Systeme sich zu stark unterscheidet gibt's Trouble.
 
  • Gefällt mir
Reaktionen: dg2rbf und BEASTIEPENDENT
Ich hab auch einen wilden Mix von Systemen und bis jetzt kein Theater gehabt. Mal das sich ein Bootlader im Namen vertan hat (Ventura - Daten anstelle Ventura).

Ich versuche aber tunlichst die Systeme zu trennen - oder zumindest nicht mehrere Generation dazwischen zu haben wenn zwei Systeme sich eine Platte / SSD teilen.
 
  • Gefällt mir
Reaktionen: dg2rbf
einen wilden Mix von Systemen
Dein Mix entspricht bis auf BS in etwa meinem Mix- Mav & EC sind auch da und hier noch Moj. Ob das den Unterschied macht?
Ich werde mal über eine andere Art Verteilung nachdenken, wenn das 5er-Bundle Platten hier eintrifft.
 
  • Gefällt mir
Reaktionen: dg2rbf
Wenn es nur um Test-Systeme geht dann kannst von einer Datenplatte 40-100 GB abziehen für eine _Partition_, je nach Generation des Systems.

An einem Testplatz habe ich Ventura "sogar" nur auf einen Dreher. Funktioniert auch, ist halt etwas langsamer. Für meine Ansprüche kompatibilität von Hard- und Software zu testen genügend.
 
  • Gefällt mir
Reaktionen: dg2rbf
Dein Mix entspricht bis auf BS in etwa meinem Mix- Mav & EC sind auch da und hier noch Moj. Ob das den Unterschied macht?
Ich werde mal über eine andere Art Verteilung nachdenken, wenn das 5er-Bundle Platten hier eintrifft.
Naja, den Mix von vielen Systemen (auch HFS+ neben APFS) würde ich mich auch trauen. Aber nicht, weitere macOS-Versionen in APFS-Container zu packen.
 
  • Gefällt mir
Reaktionen: dg2rbf
Naja, den Mix von vielen Systemen (auch HFS+ neben APFS) würde ich mich auch trauen. Aber nicht, weitere macOS-Versionen in APFS-Container zu packen.

Wie geschrieben, solange die nicht allzu weit von der Technologie voneinander entfernt sind, ok.

Hab zwei Test-SSDs, Apple AHCI Blades. Eine mit Monterey/Ventura und eine mit Mojave/Big Sur.

Das funktioniert.

High Sierra hab ich auf einer 40 GB Sata SSD einzeln. Es gab immer wieder mal Berichte dass das AFPS von High Sierra andere Systeme unbrauchbar machen. Das muss ich nicht herausfordern.

Die HFSplus Systeme mixe ich wie ich lustig bin, da gab es noch nie Theater.

Nebenbei sollte man auch an das NVRAM denken. Mojave / Big Sur / Monterey / Ventura schreiben zum Beispiel verschiedene Bluetooth und Wifi Variablen. Da kann es schnell Chaos im NVRAM geben. Also beim wilden Kreuz und Querbooten auch mal einen NVRAM Reset machen.

Nein, ich schreibe jetzt nichts über das NVRAM des Mac Pro :)
 
  • Gefällt mir
Reaktionen: dg2rbf und BEASTIEPENDENT
high sierra APFS ist nicht einmal alpha stadium von APFS und absoluter schrott.
vorallem wenn diese eine umwandlung von HFS+ hat (fsroot tree error), wobei der
gleiche fehler auch unter mojave auftritt.

mein 2017er 15" (2TB) hatte für die arbeit am set bis jetzt eine bigsur APFS formatierung,
mit einen 2ten container für mojave und einen HFS+ container für die videodaten.
das lief immer problemlos, auch nach dem update auf monterey*.

*musste sein wegen arriRAW daten auf codex medien als MXF.
 
  • Gefällt mir
Reaktionen: dg2rbf
Würde für experimentelle oder volatile macOS Installationen folgende Konfiguration mit Partitionen (P) bevorzugen:
P1: macOS(Haupt-System/APFS); P2: Daten(HFS+); P3-Px (von hinten nach vorne abgezweigt von P2): weitere macOS/OSX (HFS+/APFS)

Auf PPC die Variante P1:Leopard; P2:Tiger; P3: Daten (alle HFS+)
 
Die Theorie hat dem /Preboot und High Sierra hat sich zumindest teilweise bestätigt:

Nachdem ich in einen meiner Testsyteme eine High Sierra SSD eingesteckt hatte haben sich die /Preboot EInträge von Monterey und Ventura verändert, wieso und warum sich High Sierra im /Preboot verewigt hat weiß nur der Gott des Software-Bugs.

Monterey und Ventura teilen sich bei mir einen Container auf einem Volume.

High Sierra war auf einer separaten SSD in APFS




Code:
cat /Volumes/Ventura/System/Volumes/Preboot/*/System/Library/CoreServices/SystemVersion.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ProductBuildVersion</key>
	<string>17G14033</string>
	<key>ProductCopyright</key>
	<string>1983-2020 Apple Inc.</string>
	<key>ProductName</key>
	<string>Mac OS X</string>
	<key>ProductUserVisibleVersion</key>
	<string>10.13.6</string>
	<key>ProductVersion</key>
	<string>10.13.6</string>
</dict>
</plist>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ProductBuildVersion</key>
	<string>17G14033</string>
	<key>ProductCopyright</key>
	<string>1983-2020 Apple Inc.</string>
	<key>ProductName</key>
	<string>Mac OS X</string>
	<key>ProductUserVisibleVersion</key>
	<string>10.13.6</string>
	<key>ProductVersion</key>
	<string>10.13.6</string>
</dict>
</plist>


OpenCore wird das auslesen und wenn da 10.13 steht dann kommt das Icon von High Sierra...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
nachdem die korrekte SystemVersion.plist (/System/Library/CoreServices/SystemVersion.plist) in die CoreServices von /Preboot wieder zurückkopiert waren stimmten die Icons und die Namen.

Also ist da anscheindend High Sierra der Böse, nicht OpenCore (Legacy Patcher).
 
  • Gefällt mir
Reaktionen: BEASTIEPENDENT und dg2rbf
@LuckyOldMan:

könntest den Threadtitel akkurat umbenennen in: High Sierra Boot ändert Systemversionen von anderen Systemen in /Preboot - oder so?


Ich werde jetzt in Preboot die SystemVersion.plist nochmal sichern in SystemVersion.bak - ist dann schneller gefunden.

Vielleicht gibt's dann noch nen zweiZeiler zum automatisch umkopieren ;-)



wenn mehrere Ordner wie 37A4F142-5804-4EB9-A6EF-BA91ECDB7C55 in Preboot auftauchen für mehrere Systeme im gleichen Container dann sieht man die Zugehörigkeit mit

Code:
diskutil apfs list

.
.
.
 +-> Volume disk2s7 37A4F142-5804-4EB9-A6EF-BA91ECDB7C55
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk2s7 (Data)
    |   Name:                      Ventura - Data (Case-insensitive)
    |   Mount Point:               /System/Volumes/Data
    |   Capacity Consumed:         14662537216 B (14.7 GB)
    |   Sealed:                    No
    |   FileVault:                 No
.
.
.

dort eben nach 37A4F142-5804-4EB9-A6EF-BA91ECDB7C55 suchen. Man sollte seine Partitionen dann halt eindeutig benannt haben. Wer seine Disk "MeinTollesNeuesSystem" nennt hat verloren :p

hier noch die Positionen in bunt:

Screen Sharing Picture 26. February 2023 at 15.44.28 CET.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
  • Gefällt mir
Reaktionen: dg2rbf
könntest den Threadtitel akkurat umbenennen in: High Sierra Boot ändert Systemversionen von anderen Systemen in /Preboot - oder so?

kann er ja leider nicht mehr und muss von einem moderator gemacht werden :- (
 
Es wird noch schöner:

High Sierra überschreibt auch noch PlatformSupport.plist in Preboot von Ventura.


das trifft sich mit den Beobachtungen von @LuckyOldMan - dass er auf einmal das Verbotsschild bekam und neue Systeme ohne OpenCore starten konnte.


Und ich erinnere mich an Meldungen dass das Booten von High Sierra andere Systeme beschädigt hat.

Nicht wirklich beschädigt, aber wenn die Systeme die alte Liste der BoardIDs von High Sierra bekommen dann kann das freilich durcheinander kommen.

das Kopieren geht dann für beide (SystemVersion.plist und PlatformSupport.plist) so (das Preboot Zahlengewirr entsprechend anpassen oder bei nur einem System im Container durch * ersetzen):

Code:
sudo cp /System/Library/CoreServices/PlatformSupport.plist /System/Volumes/Preboot/37A4F142-5804-4EB9-A6EF-BA91ECDB7C55/System/Library/CoreServices
sudo cp /System/Library/CoreServices/SystemVersion.plist  /System/Volumes/Preboot/37A4F142-5804-4EB9-A6EF-BA91ECDB7C55/System/Library/CoreServices



Edit: und wenn es noch um die Namen geht:

in /Preboot die versteckte Datei .contentDetails in den gewünschten Namen ändern. Zum Beispiel per pico

Code:
sudo pico /System/Volumes/Preboot/37A4F142-5804-4EB9-A6EF-BA91ECDB7C55/System/Library/CoreServices/.contentDetails

Im Editorfenster dann den gewünschten Namen eingeben,
ctrl-o [Return]
ctrl-x

die 37* ist wieder die Beispiel-ID
 
Zuletzt bearbeitet:
Freut mich zu lesen, dass Du inzwischen erkannt hast, dass es mir nie um die Icons als solche ging, sondern darum, dass diese plötzlich einheitlich verändert wurden, hier also tiefere Eingriffe in die Systeme vorgenommen wurden.
Ich hatte schon andere Konfigurationen, bei denen auch HS beteiligt war. Nie gab es Vergleichbares wie jetzt hier - alle Icons im Bootmenür blieben an ihren zuständigen Plätzen. Auch bei den Dosdude-gepatchten Installationen blieb Alles, wie es sein sollte.

Insofern gingen Deine Bemerkungen ...
aber mal im Ernst, ist das wirklich schlimm? Die Jungs und Mädels haben großartiges geleistet und Du bekommst wegen ein paar Icons schlechte Laune?
und ..
Ich finde das völlig übertrieben. Stören dich die Icons, ändere sie. Es gibt wirklich wichtigere Dinge an den Systemen zu Pflegen wie ein paar bunte Bildchen.
völlig am eigentlichem Thema vorbei.
Es hätte eh nichts gebracht und ich hätte andere Icons bauen & einpflegen können, bis ich in die Kiste gesprungen wäre.

Hat Dich denn nicht schon vorige Woche gewundert, dass alle drei macOS plötzlich einheitlche Icons hatten und dass es auschließlich die von OCLP abhängigen macOS sind?
Weder HS noch Mavericks noch Mojave wurden "behelligt". Dazu war Mojave mit HS auch noch auf der selben SSD wie das Trio. Schon seltsam, findest Du nicht?

Du kannst Dich doch bestimmt daran erinnern, dass beim MP3.1 exakt die gleiche Geschichte beim Einsatz von OCLP ablief. Plötzlich hatte das Trio auch einheitliche HS-Icons.
Ist High Sierra also der Übeltäter und nicht OCLP? Bedaure - das ist mir als Begründung zu einfach. Dagegen sprechen andere Dinge.

Ich bin natürlich nicht untätig geblieben und habe im Rahmen meiner Möglichkeiten einige Versuche angestellt, auf die ich bauen muss. Du mit Deinem Wissen kannst da anders herangehen.

So schaut (e) es vorher beim Trio und jetzt bei einem neu erstellten Trio auf der selben SSD aus - Mojave habe ich mal zu Mavericks auf eine HDD ausgegliedert, HS zur Sicherheit mal entfernt.

2x Trio@OCLP-02.jpg

Da sind sie in trauter Eintracht versammelt - auch das malträtierte Tro mittendrin (inzwischen gelöscht) - und Niemand stört sich an den Icons Anderer.

Ich habe da ein ganz andere Theorie, die eher auf Logik baut - eventuell kannst Du oder jemand Anderer sie technisch unterfüttern.

Wäre wirklich HS der Übeltäter, dann hätte sich das schon zu HS-Zeiten gezeigt. Mir ist nichts dergleichen bekannt, dass HS andere OS infiltriert und sein Icon aufzwingt.
Aber es gibt ein Tool, das tiefer in die Systeme eingreift als Allen inklusive der Devs lieb sein kann und das ist OC bzw. hier OCLP.

Du hast Dich an das Phänomen mit dem Stopschild und dem Booten von BS ohne OCLP-Stick erinnert, wenn ich Deine Worte in #35 richtig deute. Das war der Grund, weshalb ich damals den OCLP-Einsatz fürs Erste abbrach.

Ich vermute, dass OCLP auf irgendeine Weise in die drei OCLP-abhängigen macOS eingreift, da einen Zugang schafft und sich der HS-Icon-Identitäten bemächtigt und sie jetzt als ID einsetzt und zwar für alle macOS, die über OCLP gestartet werden müssen.. Ist jetzt ziemlich laienhaft ausgedrückt, aber ich denke, man kann erkennen, worauf ich hinaus will.

Ich habe ja schon vor ein paar Jahren negative Erfahrungen machen müssen, dass OC in BIOSse bestimmter Mainboards der Z87/97-Klasse eingriff und sie still legte bis platt machte. Bei mir hat es ein Gigabyte- & zwei Asus-MBs erwischt. Ich hatte Glück und konnte sie wiederbeleben, Andere hatte Pech: Totalausfall.

Fakt ist für mich, dass durch den Einsatz von OCLP Dinge passieren, die auf Macs, die BS bis Ventura nativ unterstützen, nicht passieren.

Wäre mal wirklich interessant, einen Mac, der Ventura, Monterey ... unterstützt, mit High Sierra auf eine Platte zu packen und abzuwarten, ob sich da dann auch das HS-Icon breit macht.
Ich wage die Prognose, dass nichts passiert, lasse mich aber durch einen Praxistest auch eines Anderen belehren
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Der Punkt ist dass Systeme nach Monterey ohne OpenCore gar nicht da wären.
So hätte man das Verhalten ohne OpenCore nicht sehen können.

Bei meinem Testrechner hab ich sicher High Sierra ohne OpenCore gestartet. Da ich dort einen Bootscreen habe wäre OC auch nicht nötig.

Ich wollte den Dumper in High Sierra testen und kann dafür keinen Einfluss von OC in alten Systemen brauchen.


Warum auch immer High Sierra sich an den anderen Preboot Volumes zu schaffen gemacht hat kann ich nicht nachvollziehen. Es hat da nichts verloren. Wie weiter oben geschrieben erinnere ich mich an Berichte anderer Kollegen die auch nach einem High Sierra boot ihre neuen Systeme nicht mehr starten konnten. Ich glaube auch @Indio ? war dabei.


Mit den Befehlen und den Hinweisen ist es schnell wieder zu reparieren. Ein .bak file von SystemVersion.plist und Platformsupport.plist in /Preboot machen und bei Bedarf zurückkopieren.

Eventuell passiert das auch nicht wenn der Container in einer Partition drin steckt. Da kommen wir wieder zu dem Schluss dass es nicht optimal ist mehrere Systeme im gleichen Container zu haben. Auch wenn es wegen der Verteilung des Platzes sehr praktisch ist.

NichtsDestoTrotz hat High Sierra nicht in fremden /Preboots zu schreiben. Das ist sicher ein Bug von High Sierra der gefixt gehört. Das wird die Hausmarke wahrscheinlich nicht interessieren weil wir Kombis fahren die nicht supported werden.
 
  • Gefällt mir
Reaktionen: dg2rbf
High Sierra Boot ändert Systemversionen von anderen Systemen in /Preboot
Ich denke, dass Du da ein wenig voreilig bist.
Das ist sicher ein Bug von High Sierra der gefixt gehört
Auch daran glaube ich nicht.
Den Türöffner macht nach meinem Gefühl ein Tool. das die Befähigung hat, in die Systeme einzudringen und das ist bestimmt nicht HS.
Selbst wenn ich jetzt Größen-festgelegte Einzel-Container für jedes macOS machen würde, bleibt immer noch das vorgelagerte Bindeglied OCLP.
Ich weiss, dass das Keiner hören will, aber für mich gibt es da eine stringente logische Linie.
 
Ich hab's getestet.

1. Laufwerk High Sierra APFS
2. Laufwerk Monterey/Ventura in APFS

1.) Boot Monterey über OpenCore, keine Änderung
2.) Boot Ventura über OpenCore, keine Änderung

3.) Boot High Sierra direkt. Nach Neustart wurde /Preboot von Monterey mit den Daten von High Sierra überschrieben

Code:
cat /Volumes/Monterey/System/Volumes/Preboot/*/System/Library/CoreServices/SystemVersion.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ProductBuildVersion</key>
	<string>17G14033</string>
	<key>ProductCopyright</key>
	<string>1983-2020 Apple Inc.</string>
	<key>ProductName</key>
	<string>Mac OS X</string>
	<key>ProductUserVisibleVersion</key>
	<string>10.13.6</string>
	<key>ProductVersion</key>
	<string>10.13.6</string>
</dict>
</plist>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ProductBuildVersion</key>
	<string>22D49</string>
	<key>ProductCopyright</key>
	<string>1983-2023 Apple Inc.</string>
	<key>ProductName</key>
	<string>macOS</string>
	<key>ProductUserVisibleVersion</key>
	<string>13.2</string>
	<key>ProductVersion</key>
	<string>13.2</string>
	<key>iOSSupportVersion</key>
	<string>16.3</string>
</dict>
</plist>


1.)
96263456-DFB9-43FC-B821-772D2B3DBAE5.jpeg


3.)
89C0A927-D060-4775-8E00-80494EB1ED6F.jpeg



Screen Sharing Picture 26. February 2023 at 18.44.13 CET.png


siehe PlatformSupport und SystemVersion von 2020. Die .bak Dateien sind die Backups die ich gemacht habe um wieder zurückzukommen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BEASTIEPENDENT
Nach zurückschreiben der plists und des Namens wieder ok. High Sierra als SSD stört nicht, solange sie nicht gebootet wird :-D

38F74787-5297-48B2-B229-00E12C078081.jpeg


Ergo:

Wenn High Sierra benötigt wird dann bitte die anderen APFS Systeme aus dem Rechner entfernen - oder eben die plists wieder zurückschreiben.

Habe noch High Sierra gebootet und Monterey/Ventura rausgezogen. So schräg das ist, das wollte ich noch geklärt haben. Keine Änderung im Preboot von Monterey/Ventura.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten