cMP 5,1 und MONTEREY

[oneOeight]

Vielleicht gibt es irgendwann eine Lösung oder die Softwarehersteller liefern nach.

Du solltest die Meldungen richtig verstehen, die beziehen sich auf Befehle, die die CPU nicht versteht oder die falsche CPU verbaut ist.
Da besser die nicht nach, denn deine CPU ist zu alt und du kannst nur bei den alten Versionen bleiben.

 

[flyproductions]

Offenbar laufen nur Apps die im System vorhanden sind. Alles andere, bei Mojave funktionierende, schmiert sofort nach dem Öffnen ab.

Das ist aber jetzt auch maßlos übertrieben! Es gibt auch eine wirkliche Masse an Fremdhersteller-Software, die unter Monterey problemlos läuft. Eigentlich fast alles 64-bit-Zeugs. Insofern wäre es mal interessant, zu wissen, was für eine Photoshop-Version da bei dir nicht geht.

Auf deinem zweiten Bildschirm sieht es so aus, als ob du da versucht hättest, irgendeine Classic-Umgebung an den Start zu bekommen. Bei solchen Spielereien ist natürlich irgendwann auch mit den „üblichen Verdächtigen“ VMs Schluss. Da darf man sich dann aber auch durchaus nach dem Sinn fragen. Daraus aber den Schluss zu ziehen, dass „alle Software aus der Intel-Ära“ nicht mehr geht, ist sagen wir mal, gewagt.

 

[linux]

Da sind wir wieder da wo ich sagte : "neu kaufen" Ob Spielerei oder nicht, unter Systemen die M1 benötigen fängst Du bei 0 wieder an. Vmware ist für mich interessant weil mein Receiver unter Linux läuft und ich Aufnahmen mit Linux schneiden muß. Mir reichte es schon ständig neue Versionen von "Little Snitch" kaufen zu müssen weil Apple seine Systeme erneuert hat.
Machen wir´s doch wie Microsoft: Neues System - neuer Rechner.
Mojave tut´s ja.
@oneOeight Die CPU ist dieselbe wie bei Mojave weil sie auf derselben Kiste laufen.

 

[oneOeight]

Die CPU ist dieselbe wie bei Mojave weil sie auf derselben Kiste laufen.

Klar. Aber wenn die Apps gegen das SDK einer neueren MacOS Version kompiliert werden, dann scheinen da Optionen aktiviert werden die nur von neueren CPUs als deiner unterstützt sind.
Zum 1. Screenshot siehe
https://communities.vmware.com/t5/VMware-Fusion-Discussions/VMX-option-to-disable-use-of-XSAVE-instruction-under-Big-Sur/td-p/2307694


Zum 2. Screenshot, Bad CPU Type kommt bei 32bit Apps.
Mojave ist ja noch mit 32bit Apps.
Aber da sollten alle Apps inzwischen 64bit sein.

 

[SirVikon]

Also ich habe auf meinem cMP Monterey laufen und keine Probleme. Habe aber auch die CPUs erneuert.

 

[oneOeight]

XSAVE wurde wohl mit Sandy Bridge eingeführt.
VMWare 12 kann er halt nicht nutzen, da die XSAVE drin haben.
Bleibt ja noch Parallels oder VirtualBox oder UTM.

 

[stschulze]

Dauer ca. 20 min

 

[Macschrauber]

Bei mir deutlich länger weil ich den Root Patch wegen der Kepler machen musste, Bluetooth und Stock Wlan funktioniert auch:

Wichtig zu erwähnen wäre noch das man die aspp-override.kext ab 12.3 braucht, sonst schmiert der Mac Pro beim Booten ab.

OCLP 043 bringt das mit, oder händisch dazu tun.

Spoiler

Starting with macOS 12.3, the wrong power management driver is used for the MacPro5,1, preventing macOS from booting. To ensure that the right one is used, you'll need an extra component:

⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀
ASPP-Override

➊ Copy the file "ASPP-Override.kext" to your ESP as indicated below:

ESP
└── EFI
⠀⠀ ⠀├── BOOT
⠀⠀ ⠀└── OC
⠀⠀⠀⠀ ⠀ ⠀├── ACPI
⠀⠀⠀⠀ ⠀ ⠀├── config.plist
⠀⠀⠀⠀ ⠀ ⠀├── Drivers
⠀⠀⠀⠀ ⠀ ⠀├── Kexts
⠀⠀⠀⠀ ⠀ ⠀│⠀ ⠀├── Lilu.kext
⠀⠀⠀⠀ ⠀ ⠀│⠀ ⠀├── WhateverGreen.kext
⠀⠀⠀⠀ ⠀ ⠀│⠀ ⠀├── FeatureUnlock.kext
⠀⠀⠀⠀ ⠀ ⠀│⠀ ⠀└── ASPP-Override.kext
⠀⠀⠀⠀ ⠀ ⠀├── OpenCore.efi
⠀⠀⠀⠀ ⠀ ⠀├── Resources
⠀⠀⠀⠀ ⠀ ⠀└── Tools

➋ Enable the kext:

Find ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀
Replace ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀ ⠀
<key>Kernel</key>
<dict>
<key>Add</key>
<array>
⋮
</array>
<key>Block</key>
⠀
⠀
⠀
⠀
⠀⠀
⠀
⠀ <key>Kernel</key>
<dict>
<key>Add</key>
<array>
⋮
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>BundlePath</key>
<string>ASPP-Override.kext</string>
<key>Comment</key>
<string>Power management override</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string></string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>21.4.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>
<key>Block</key>

Eventuell mit relativ voluminösen Kernel Panic Logs im Nvram was zu neuen Problemen führen kann (Siehe Firmware Thread).

Außerdem soll die Radeon Boost Erweiterung auch nicht mehr kompatibel sein und das schreibt dann definitiv komprimierte Kernel Panic Logs (Typ B in meinem Dumper) ins nvram.

 

[Indio]

radeonboost ist schon seit big sur hinfällig.
wobei ich ausser bei geekbench nie irgendeinen
leistungssprung gesehen hatte, weder messtechisch, noch in realwork.
also war das sowieso nur ein geekbench tuner +g*

 

[Macschrauber]

trotzdem haben das manche in ihrem Setup drin weils noch nicht gestört hat.

 

[flyproductions]

Mir reichte es schon ständig neue Versionen von "Little Snitch" kaufen zu müssen...

Kein Mensch „muss“ sich Little Snitch kaufen!

Man kann sich auch einfach die Software kaufen, die man damit am Nachhausetelefonieren hindern will.

😂

 

[Indio]

Kein Mensch „muss“ sich Little Snitch kaufen!

Man kann sich auch einfach die Software kaufen, die man damit am Nachhausetelefonieren hindern will.

😂

ah, dass geht auch? +g*

 

[linux]

Eigentlich sind wir hier im falschen Forum.
Ich gestehe daß ich über die Äußerung von @flyproductions etwas "verschnupft" bin.
Seit der von den Seitenbetreibern "zu genehmigenden" Auswahl der Cookies weiß man doch erst was beim Datenaustausch so abläuft!
Wenn ich bedenke daß das vor der Cookieauswahl standartmäßig ablief läuft es mir eiskalt über den Rücken.
Die Möglichkeit in einer App eine Häkchen zu haben daß Nachhausetelefonieren unterdrückt halte ich für mehr als blauäugig.
Wozu muß Adobe z.B. wissen mit welchem Rechner, mit welchem Betriebssystem ich arbeite und auf welchen Standort ich befinde?
Glaubst Du allen Ernstes daß die gesendeten Daten ausschließlich zur Verbesserung der betreffenden Programme dienen???
Man erinnere sich daran daß plötzlich herauskam daß Neufahrzeuge ständig Daten zum Hersteller sendeten, natürlich nur zu Optimierungszwecken.
Es mag sein daß ich mit meinen 65 Lenzen etwas anders über die aktuelle Situation der EDV denke als derjenige, der mit seinem Smartphone ständig online sein muß, Bluetooth und GPS noch niemals ausgeschaltet hat und Google & Co für seinen besten Freund und Wohltäter hält.
Wenn ich Windoofs nutzen muß schalte ich das Netzwerk aus und mein Smartphone läuft unter LineageOS.
Das eigentlich zum Thema "Little Snitch".

 

[flyproductions]

Ich gestehe daß ich über die Äußerung von @flyproductions etwas "verschnupft" bin.
Seit der von den Seitenbetreibern "zu genehmigenden" Auswahl der Cookies weiß man doch erst was beim Datenaustausch so abläuft!
Wenn ich bedenke daß das vor der Cookieauswahl standartmäßig ablief läuft es mir eiskalt über den Rücken.
Die Möglichkeit in einer App eine Häkchen zu haben daß Nachhausetelefonieren unterdrückt halte ich für mehr als blauäugig.

Ich habe ja nicht gesagt, dass ich da den ersten Stein werfe.

Und ja, ADOBE war wohl der erste Hersteller, der irgendwann angefangen hat, hemmungslos alles nachhause zu funken, was er wollte. Und so auch der Erste, dem ich das - auch bei Programmen, die ich ganz offiziell besaß - kategorisch untersagt habe. Das war gefühlt schon Anfang der Nuller.

Aber ich denke, bei dem Job, den Little Snitch macht, indem es einem die weitgehende Herrschaft über die Kommunikation des eigenen Rechners zurückgibt und (teils aus gutem Grund) versteckte Aktivitäten ans Licht holt, sollte man sich über die paar Euro, die es kostet, nicht wirklich grämen.

Das war es, was ich eigentlich sagen wollte.

 

[DL8LAQ]

Update auf 12.3.1 verlief völlig problemlos!

 

[festplattenmagier]

Update auf 12.3.1 verlief völlig problemlos!

Was sagt @Macschrauber 's ROM Dumper dazu?

 

[Macschrauber]

Ich würde empfehlen vorher zu prüfen - und wenn der leere Platz eng wird (<16.000) zumindest so oft neu zu starten bis wieder genügend Platz da ist

 

[Grobi112]

Update auf 12.3.1 verlief völlig problemlos!

Bei mir Gestern auch. Zwischenzeitlich habe ich gedacht der Rechner hängt, weil der Ladebalken recht lange auf einer Stelle gestanden hat. Einfach in Ruhe weiterwerkeln lassen, dann hat er von sich aus neu gestartet und das neue System war drauf.

Rom Backup vor dem Update gemacht und nach dem Update noch mal den Dumper zur Sicherheit durchlaufen lassen: Alles steht auf "ok"

 

[Macschrauber]

Rom Backup vor dem Update gemacht und nach dem Update noch mal den Dumper zur Sicherheit durchlaufen lassen: Alles steht auf "ok"

Trotzdem sollte man (mit heutigem Wissen) vor dem Monterey Update mehr als 16k frei haben.

Sollten es deutlich weniger sein dann ein paar mal neu starten, pro Neustart werden es etwa 4k weniger biss dann die Garbage Collection einsetzt und Platz schafft. Bei dieser Gelegenheit hat man dann auch gleich den Gesundheitszustand des nvrams überprüft (und Backups gemacht).

Hat ja keiner mit so langen Kernel Panic logs gerechnet.

Das nvram der supporteten Kisten ist wesentlich größer, aber das berücksichtigt die Hausmarke nicht bei unseren Mac Pros.

Und ja, das ist nur ein Problem _wenn_ ein Kernel Panic kommt. Aber das weiß man nicht vorher.

 

[DL8LAQ]

Der angeschlossene ROM Dump mit dem neuen Dumper war so weit ok. Ich meine mehr als 16000 bytes frei. Das schaue ich heute Abend noch nach und melde mich ggf. wieder. Der Hinweis auf ein altes "boot code fragment" - Ich weiß den genauen Wortlaut im Dump nicht - liegt einfach daran, dass ich noch nie das aufgeräumte NVM reingeflasht habe. Kommt noch...