Beiträge von griven

Das das traurig ist ist keine Frage aber nunmal der Gang der Dinge nutzt ja nichts viel Geld in einen Rechner zu investieren der von dem gewünschten Betriebssystem halt nicht oder nur in teilen unterstützt wird...

Wenn man mal alles sentimentale beiseite schiebt und die Sache realistisch betrachtet wird es vielleicht noch 1-2 Versionen von macOS geben (eher eine als zwei) die überhaupt noch kompatibel mit X86_64 sind und dann war es das (Apple Silicon geht im kommenden Jahr ins fünfte Jahr) mit macOS auf der X86 Plattform. Bisher war zumindest Apples Preispolitik immer noch ein Argument für einen Hackintosh aber mit dem Mac mini hat sich das auch erledigst. Man bekommt hier für einen sehr fairen Preis eine Maschine die von der Leistung her (zumindest unter macOS) jeder X86 Maschine haushoch überlegen ist (vom Stromverbrauch und damit von den Folgekosten ganz zu schweigen). Wenn es also um Neuanschaffung primär für die Nutzung mit macOS gehrt ein "No Brainer" wie man Neudeutsch so schön sagt

Was Erweiterbarkeit/Reparierbarkeit angeht ist halt, Apple typisch, sehr begrenzt aber wird in den sehr engen Grenzen dennoch möglich sein. Klar Speicher, der unified Memory ist ein Teil des SoC's, lässt sich nicht aufrüsten (hier also vorab gut überlegen ob die 16Gig genug sind oder ob es mehr sein muss) aber zumindest im Bereich der SSD's gibt es Hoffnung. Der Mini kommt mit SSD Speicher in Modulbauweise und die ersten Drittanbieter stehen in den Startlöchern um Module dafür auf den Markt zu bringen ist also eher eine Frage der Zeit wann und nicht ob der SSD Speicher sich im Mini erweitern lässt...

Naja speziell bei Windows geht es schon auch um die Einschränkungen die Win on ARM für sich genommen nunmal auch hat...

Zum einen muss ich das zwingend über eine VM machen was für sich genommen schon nicht schön ist zum anderen sind die meisten Windows Apps eben auch keine ARM Apps bedeutet also das hier in der VM noch eine Emulationsschicht läuft die X86 zu ARM Code übersetzt. Man kann das nutzen (hab's selbst auf dem M1 MBP ausprobiert) nur stößt man halt relativ schnell an Grenzen zumindest dann wenn man mehr als Office und I-NET Kram machen möchte/muss (und ganz ehrlich für Office und Internetkrams muss man sich kein Windows auf den Mac dübeln)...

Asahi Linux ist in sofern interessant als das es eben keine VM braucht sondern sich nativ auf den M-Serie Macs als zweites OS installieren lässt (Dualboot). Asahi unterstützt bzw. hat inzwischen für fast alles AppleSilicon spezifisches Treiber was das ganze zu einem sehr, sehr potenten OS macht...

Kommt in meinen Augen halt nach wie vor darauf an für was ich den Rechner einsetzen möchte/muss...

Szenario1: Die Kiste soll nur mit/unter macOS laufen -> Die Antwort kann an der Stelle dann wirklich nur sein vergiss den Hackintosh nimm das Geld und kauf einen MacMini mit M4 oder M4 Pro Du wirst nichts bauen/finden können im Hackintosh Bereich das ein besseres Preis/Leistungsverhältnis bietet als der aktuelle Mini.

Szenario2: Die Kiste soll/muss auch Windows/Linux tauglich sein -> Hier ist die Antwort dann schon gar nicht mehr so eindeutig denn zumindest Windows ist auf Apple Silicon aktuell (noch?) ein eher schlechter Kompromiss denn Win11 on Arm läuft "nur" in einer VM auf AppleSilicon und da auch mehr schlecht als recht. Einzig an der Linux Front sieht es hingegen deutlich besser aus denn mit Asahi Linux steht hier eine Distribution zur Verfügung die speziell AppleSilicon abgestimmt ist und inzwischen wirklich erstaunliche Erfolge feiert (auch und insbesondere im Bereich Gaming sofern das interessant ist).

Es ist also meiner Meinung nach nicht so einfach zumindest nicht wenn man nicht weiß was der TE wirklich mit dem Rechner vorhat/plant

Doch ich habe die Erkenntnis gewonnen das man aus dieser Stadt einfach nicht trockenen Fußes wieder raus kommt zumindest dann nicht wenn man nicht mit dem Auto anreist...

Ansonsten war es ein kleine aber sehr feine Runde die sich (ausnahmsweise) weniger mit dem Thema Hackintosh dafür umso mehr mit dem Thema Glücksrad auseinandergesetzt hat

Letzteres könnte man ja leicht rausfinden indem man die folgenden NVRAM Variablen bzw. deren Inhalt bei beiden Systemen mal vergleicht:

• fmm-computer-name
• fmm-mobileme-token-FMM
• fmm-mobileme-token-FMM-BridgeHasAccount

Wenn sich deren Inhalten zwischen den Versionen unterscheiden wäre der Grund für das Verhalten ja schon gefunden wobei ich ehrlich gesagt bezweifle das Apple einem das so einfach macht

Joa hängt von verschiedenen Faktoren ab letztlich...

Nur weil die iGPU das kann bzw. so spezifiziert ist das ein Betrieb mit drei Bildschirmen möglich ist muss der Hersteller des Boards das ja noch lange nicht auch sauber implementieren. Da die Probleme hier bereits auf Bios/UEFI Ebene auftreten ist davon auszugehen das sie genau das eben nicht gemacht haben sprich die Firmware die auf UEFI Ebene für die Anzeige verwendet wird (UEFI GOP) ist in dem Punkt unvollständig oder fehlerhaft (man kann ggf. den GOP Treiber unabhängig vom Bios aktualisieren erfordert aber das man das Bios File modifiziert zum Beispiel mit UBU und dann das modifizierte File wieder auf dem CMOS schreibt). Spannend ist in dem Zusammenhang vielleicht der Treiber BiosVideo den OpenCore mitliefert zwar wird der nichts daran ändern das der dritte Schirm (bzw. eben gar keine wenn der dritte angeschlossen ist) schwarz bleibt bis das OS geladen ist aber eventuell lässt sich so wenigstens der OC Picker anzeigen sprich Bild ab start von OpenCore (ins Bios muss man in der Regel ja nicht so häufig demnach vielleicht zu verschmerzen)...

Das Problem tritt häufiger auf als man denkt und betrifft bei weitem nicht nur Hacks sondern passiert auch bei echten Äpfeln wenn die verschiedene macOS Versionen im Dualboot verwenden. Woran genau das liegt weiß ich nicht kann mir aber vorstellen das es irgendwas damit zu tun hat wie Apple die Anmeldung an die Cloud intern realisiert (also eher ein Problem auf Apples Seite als eines das wir beeinflussen könnten)...

Ich war zweiter btw. und danke für die Spaßwünsche al6042

Ich denke ich bin am Start

Auf dem Elitebook hat sich der RC2 von 15.2 (25C100) ohne Probleme installieren lassen und auch OCLP hat seinen Dienst wie gewohnt verrichtet und die FENVI zurück ins Leben geholt

Vielleicht ja eine blöde Idee aber sicher einen Versuch wert...

Wie bzw. was hast Du im Bios für DVMT-Prealloc und VRAM eingestellt? Da die Probleme schon auf Bios Ebene austreten ist ja davon auszugehen das eben genau hier auch schon was im argen liegt. Möglicherweise reichen die (vor)eingestellten Werte hier nicht für den Betrieb von drei Bildschirmen bzw. stellt das Bios der IGPU nicht genug Speicher zur Verfügung um alle 3 Bildschime zu befeuern (im OS sieht das dann anders aus denn sobald dessen Treiber übernimmt kümmert der sich um die Verwaltung des Video Speichers). Möglicherweise lohnt es sich hier mal ein wenig mit den Einstellungen zu spielen.

Ich habe mich am Samstag an Elisenlebkuchen (Fotos von der Sauerei habe ich jetzt keine gemacht dazu hatte ich viel zu viel Schokolade an den Pfoten) versucht und was soll ich sagen die Dinger sind richtig gut geworden. Gar nicht so aufwendig (wenn man das mit der Kuvertüre mal ausser Acht lässt) zu produzieren und eine wirklich geniale Leckerei. Kein Vergleich zu den total übersüßten Dingern aus dem Supermarkt...

Ähm Dir ist aber schon klar das OC im UEFI Modus (nicht im Legacy Mode) schon auch ein UEFI Bios braucht damit das vernünftig funktioniert? Es gibt ja schon gute Gründe dafür das man zum Beispiel CSM wenn möglich deaktivieren soll. So ein Mischmasch ist selten eine gute Idee. Vielleicht solltest Du in dem Fall doch lieber auf Clover zurückgreifen denn das ist in solchen Fällen um einiges toleranter als das bei OC der Fall ist.

Einhorn guter Tipp, danke dafür

Kocht man den Holundersaft nicht auf Vorrat ein? Ich selber mache das nicht mehr aber ich kann mich gut an die Zeit erinner als meine Oma noch lebte. Oma war vom alten Schlag und hat alles eingekocht und verarbeitet. Wenn Saison war ist Oma in die Brombeeren gegangen und hat davon Marmelade und Saft gemacht, wenn der Holunder soweit war wurde der geerntet (gibt es hier beides in Hülle und Fülle) und zu Saft verarbeitet gleiches gilt für Hagebutten (ich habe ihre Hagebuttenmarmelade geliebt) und wenn es schwarze Johannisbeeren (hatte sie im Garten) gab dann wurde Aufgesetzter davon gemacht (hicks)...

Gerade bei dem dem Holundersaft ist es gelegentlich auch mal vorgekommen das die eine oder andere Flasche dann doch angefangen hat zu gären ein Riesenspaß wenn die dann in der frisch renovierten Küche losgehen und anschließend alles nett gesprenkelt ist. Das Zeug (die Farbe) bekommt man nicht wieder weg da hilft dann nur neu streichen/tapezieren

Ach ja schöne Zeiten und schöne Erinnerungen schade das solche "Tugenden" heute mehr und mehr in Vergessenheit geraten...

Das geht schon auch mit OC es muss nicht Clover sein aber bei simon0302010 kommen gleich mehrere ungünstige Faktoren zusammen denn er hat ja nicht "nur" einen SandyBridge welche ja ohnehin mit Blick auf UEFI/ACPI schon schwierig mit macOS zu verheiraten sind sondern obendrein handelt es sich bei Ihm noch um einen Fujitsu Prebuild Office PC. Gerade die Prebuilds aus der Generation sind ja zudem dafür bekannt noch zusätzlich "verkorkste" Firmwares zu haben. Man darf halt nicht vergessen das SandyBridge und die dazu gehörenden Chipsätze so gerade der Wendepunkt in Richtung UEFI waren. Gerade bei den Sandy Boards gab es oft nichtmal offizielle UEFI Firmwares. Erinnert Euch mal an die GA Boards aus der Generation da gab es durch die Bank nur eine experimentelle UEFI Version die nie den Beta Status verlassen hat. UEFI war erst ab Z77 verbreitet ein Thema und selbst diese Firmwares waren oft noch richtiger Murks...

Vielleicht wäre es sinnig bei der Plattform eher auf Legacy zu gehen anstelle von UEFI (sofern das Bios das zulässt) möglicherweise hält man sich damit eine menge Ärger vom Hacken

Bevor jetzt jemand mit Laptops um die Ecke kommt das kann man nicht 1:1 vergleichen da die Laptops auf eine andere Bios Implementation setzen als die Desktop Systeme. Die Laptops der Generation haben oft ein InsydeH2O UEFI Bios verwendet und waren an der Stelle den Desktop Systemen um einiges voraus...

Ich verwende OCAT zum editieren der configs (https://github.com/ic005k/OCAuxiliaryTools) und ja das hat in der Tat so eine Art Plausiprüfung bzw. bereinigt bestimmte Dinge selbstständig bei anderen meldet es Fehler beim speichern (OCValidate wird vorher ausgeführt) Demnach kein Wunder das ich das nicht gesehen habe denn das hat es von sich aus bereinigt

Pillenflitzer ich denke er meint das KVM Umschalter Problem (Probleme beim Einsatz von KVM-Umschaltboxen) ich habe dazu allerdings keine Idee da ich sowas gar nicht nutze 🤷

Füg mal noch das BootArg npci=0x2000 hinzu könnte nämlich auch daran liegen...

ACPI sieht soweit erstmal unkritisch aus meiner Meinung nach...

Du solltest vielleicht die Tabelle SSDT-1.aml droppen da sie zum einen reichlich Syntaxfehler enthält und zum anderen offenbar in irgendeiner Form für das CPUPM zuständig ist was aber ja so unter macOS eh nicht funktioniert da Apple hier eigenen Mechanismen einsetzt (AppleIntelCPUPowerManagement.kext in Deinem Fall)....

Um die Tabelle zu droppen in der config unter dem Punkt ACPI->Delete folgendes eintragen: