Ich habe auf karacho und Arkturus reagiert und hier nur beipflichtend erklärt das der Patch nichts mit dem T2 zu tun hat und sonst gar nichts. Wie Du bluebyte daraus schließt ich könnte Dich in irgendeiner Weise gemeint haben erschließt sich mir nicht 🤷♂️Anyway wenn das bei Dir so läuft ist das doch okay und liegt ziemlich sicher daran das Du ein "kompatibles" SMBIOS fährst ändert aber ja nichts an der Tatsache das der Patch für sich genommen für andere User dennoch sinnvoll ist. Das im Blick erschien es mir wichtig nochmal zu erwähnen was der Patch eigentlich genau tut...
Beiträge von griven
-
-
Vollkommen richtig der Patch hat rein gar nichts mit dem T2 zu tun sondern umgeht einfach den BoardID Check in der Boot.efi von macOS...
Im großen und ganzen verhindert er lediglich das altbekannte "Einfahrt verboten" Schild das man sonst bei einem nicht unterstützten SMBIOS zu sehen bekommt. Der Patch ist ein Ersatz für das BootArg np-compat-check mit dem Vorteil gezielt "nur" auf die boot.efi zu wirken und den Rest unangetastet zu lassen. Kombiniert man den Patch dann mit RestricEvents.kext und dessen BootArg revpatch=sbvmm bekommt man anschließend in einem so installierten macOS auch Updates ausgespielt auch dann wenn das SMBIOS zu einer eigentlich nicht mehr offiziell untetstützten Mac gehört.
-
Ich bin natürlich auch wieder am Start

-
-
Vielleicht sei an der Stelle auch nochmal erwähnt das ein evtl. vorhandener APPLE Ordner gefahrlos entfernt werden kann denn die dort enthaltenen EFI Updates nutzen einem auf einem Hackintosh generell ohnehin nichts

-
Leider ist meine FENVI im Elitebook nicht kompatibel (0x43A0) ich habe mir daher jetzt mal eine DW1820A bestellt (war für unter 10 Euronen auf Ebay zu haben). Sobald die geliefert wurde werde ich das ganze dann auch mal testen. Die FENVI kommt dann in die Schublade bis möglicherweise eine OCLP Lösung dafür verfügbar ist. Ohne WLAN ist das Elitebook ansonsten aktuell nämlich leider nur von sehr eingeschränktem Nutzen für mich.
-
Für macOS braucht es da ggf. noch einen Connector Patch das ist es worauf ST3R30 hinaus wollte Arkturus. Entsprechende Patches sind immer dann notwendig wenn die Gegebenheiten von dem Abweichen was Apple im Framebuffer definiert hat. Das die USB-C Geschichte hier nicht betroffen ist liegt indes daran das dieser spezielle Output gar nicht über den Framebuffer direkt bedient wird....
-
Ist mir bisher nicht aufgefallen aber möglich ist das allemal. Wenn sich das nun gegeben hat ist ja alles gut. Generell ist es schon so das nach einem Update ein ganzer Haufen an Prozessen zunächst im Hintergrund noch werkelt wobei man das in aller Regel nicht wirklich merkt (mit der Ausnahme von Spotlight)...
-
Da läuft irgendein Kurzbefehl Amok bei Dir...
Schau mal in die Kurzbefehle App was da aktiv ist und beende das ggf. damit sollte der Spuk dann ein Ende haben.
-
Mir erscheint es an der Stelle auch nochmal wichtig zu sein darauf hinzuweisen das 5Gbit/s in der Theorie für ein Gehäuse mit 4 SATA Geräten ausreichend sein mögen in der Praxis es da aber recht schnell deutliche Grenzen gibt die schnell erreicht sind wenn man zum Beispiel auf konstante Datenströme angewiesen ist (Thema Video Bearbeitung/Betrachtung) und exakt das ist ja hier dann der Fall. Meiner bescheidenen Meinung nach wäre es, wie ja schon erwähnt, sinnvoll das Massenspeicher Problem entweder über eine entsprechende Thunderbolt Lösung (Dock, Gehäuse) zu lösen oder darüber nachzudenken dem Mini einfach direkt eine entsprechend große SSD zu verpassen (https://store.m4-ssd.com/produ…y-ssd-for-mac-mini-m4-pro) und die SATA Geschichten in Rente zu schicken bzw. als Backup Medien zu behalten. Was unterm Strich die preislich attraktivere Variante ist müsste man mit spitzem Stift selbst ausrechen (Preis für das SSD Modul vs. TB4 Dock + NVME SSD + ggf. benötigte Kabelage etc.)...
-
Habe es mal auf erledigt gesetzt löschen ist hier eher unüblich

-
Meiner Meinung nach klar das M4 Modell...
Der M1 ist inzwischen in alle seinen Iterationen 5 Jahre alt und wird demnach demnächst irgendwann aus dem support fallen (eher früher als später) von daher schon allein mit Blick auf Zukunftsfähigkeit eher richtung M3 oder M4 gehen ganz davon abgesehen das der M4 selbst in der kleinsten konfiguration jeden M1 in sachen Leistung locker in die Tasche steckt.
-
Das iMessage Problem liegt weniger am SMBIOS sondern mehr an einem Bug den Apple in Sequoia eingebaut hat. Das Problem tritt vermehrt seit dem Leitzen Update auf und betrifft inzwischen viele User sowohl mit als auch ohne Patch auf dem Hackintosh und auf echter Apple Hardware. Es soll helfen (zumindest temporär) den Prozess auf dieser Seite zu durchlaufen: https://apple.co/IMFT-mac
-
Das FileVault Thema ist eigentlich seit der Beta 6 oder Beta 7 keins mehr will meinen passiert nicht mehr ungefragt wobei ich jetzt nicht sagen kann ob FileVault, falls gewollt, dann ohne APFSAligned funktionieren würde. Die Crux hierbei liegt ja darin das Apple der Tatsache Rechnung trägt das nur noch Mac's mit T2 Chip oder AppleSilicon überhaupt unterstützt sind und alles andere rausgeschmissen hat. Bei den T2 mac's läuft der Spaß ja über den T2 (Verschlüsselung und Controller für Massenspeicher) könnte mir vorstellen das es deshalb dann auf nicht T2 Modellen (inkl. Hackintosh) eben nicht geht.
-
Das SMBIOS spielt eine untergeordnete Rolle wenn man RestrictEvents.kext zusammen mit dem BootArg revpatch=sbvmm verwendet. Kombiniert man das dann noch mit dem Booter Patch um den BoardID Check der boot.efi von macOS zu umgehen kann man guten Gewissens und getrost mit dem iMAcPro SMBIOS weiter segeln

-
Grob vereinfacht ausgedrückt sorgt restrictevents zusammen mit dem BootArg dafür das dem SoftwareUpdate Prozess von macOS signalisiert wird das er in einer virtualisierten Umgebung (VM) läuft und somit keine Prüfungen durchführen muss/soll ob verfügbare Updates auf dem zugrundeliegenden System zugelassen sind oder nicht. Ohne diesen Kniff prüft der Dienst unter anderem anhand der BoardID, FirmwareVersion und DeviceID ob ein Update für das vorliegende Mac Modell freigegeben ist oder nicht und falls diese Prüfung fehlschlägt wird ein Update eben nicht angeboten.
-
So blöd das jetzt auch klingen mag aber nein da kann man Dir nicht helfen. Die RX7900XT ist schlicht und ergreifend zu neu für macOS und wird daher nicht unterstützt. Leider hat Apple von dem Moment an als klar war das man sich von der X86_64 Architektur verabschieden würde kein Anstrengungen mehr unternommen neuere Grafikkarten als die NAVI 21 bzw. 23 zu unterstützen will meinen mit macOS ist bei der RX6950XT das Ende der Fahnenstange erreicht.
-
Lass das an der Stelle einfach komplett OCLP erledigen. Auf originaler Apple Hardware macht es überhaupt gar keinen Sinn in irgendeiner Weise in die vom Patcher erstellte EFI einzugreifen. Das was da am Ende rausfällt ist perfekt auf Deinen Typ Mac abgestimmt. Sofern Du den Installer ebenfalls mit dem Patcher erstellst musst Du Dich nach der Installation von Sequoia nichtmal mehr selbst um die Patches kümmern das OS läuft am Ende einfach so als wäre es für die Kiste gemacht worden

Also kurz und Knapp Installer und EFI von OCLP bauen lassen, Installieren wie gewohnt und im Anschluss die Finger insbesondere von der EFI Partition lassen!
-
Lade Dir auf dem funktionienden MacBook ELCapitan (die letzte offiziell auf dem MBP 2008 unterstützte Version) herunter und nutze dann dann im Terminal den CreateInstallMedia Befehl um ein ElCapitan installationsmedium zu erstellen (zuvor natürlich das heruntergeladene DMG öffnen und die App nach Programme ziehen).
sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app
Mit dem so erstellten USB Medium kannst Du dann auf dem 2008er MBP ElCapitan erneut installieren und anschließend von dort aus weiter machen.
-
Aus eigener Erfahrung kann ich sagen das 2015er MBP läuft mit Sequoia recht stabil und ausreichend schnell kann man also gut und gerne mit Arbeiten bis der OCLP irgendwann (wenn überhaupt) Tahoe unterstützt
