Posts by MacPeet

Ist so ja leider nicht ganz richtig. Nur weil ein Kext nur eine info.plist beinhaltet ist es auch in diesem Fall eine Art Code, wo auf Library's gelinkt wird, wo somit Abhängigkeiten zum System bestehen. Schau Dir mal die ganze info.plist an, bitte!

Die info.plist ist ja kein Treiber, der eigenständig agiert. Wäre auch zu leicht und zu schön, was den Hackintosh-Bereich betrifft. Das wäre ja ein Traum.

Die info.plist übergibt ja nur Werte an die eigentlichen Apple-Treiber, bzw. Library's und wenn diese in neueren Systemen gar nicht mehr vorhanden sind, dann nützt auch die beste info.plist nix.

Apple hat diese Geschichte in den neuen Systemen ja bekanntlich mehrfach geändert. Einiges ist ganz rausgeflogen, einiges bekam eine Namensänderung, etc. pp., was dadurch nicht mehr gefunden wird beim Linken.

Wenn ich diese Sachen auf einem modernen System im Finder suche, dann findet er diese Einträge bei mir nur noch in einer OCLP.app, welche ich noch auf der Datenplatte liegen habe.

OCLP bringt diese Sachen ja für gewisse ältere unsupported realMac's (MacPro, etc.) zurück, damit dort das USB wieder geht mit neuen Systemen.

Vielleicht kann man im OCLP-Patcher unter Optionen ja auch genau dieses USB-Patch explizit auswählen, damit er diese Dinge auch auf den besagten Lappi's zurück bringt.

Evtl. geht WWAN dann sogar auch mit den neuen Systemen wieder, wenn die Abhängigkeiten zur Library wieder gegeben sind.

Wer da Bock drauf hat, einfach mal testen, würde ich sagen. Versuch macht Klug.

PS:

Deine Aussage, Sonoma geht, Ventura aber nicht, verwirrt mich total, da Sonoma ja nach Ventura kam. War Dein Text so richtig, schrup21 ?

Apple setzt in heutigen Zeiten inzwischen auf Hotspot vom Handy, was mit LTE/5G auch ohne Probleme geht. Ferner ist heutzutage wohl kein User mehr mit Laptop ohne sein Handy unterwegs.

Windows pflegt bekannter Weise alte Hüte mit seiner Treiberpolitik, schön wenn's da noch geht, dann kann man es ja auch noch verwenden.

Die genanten Kext's und Foren-Hinweise sind 5 bis 7 Jahre alt. Die GitHub-Entwicklungen dazu sind inzwischen lange eingestellt und die Kext's linken auf Library's, die es in neuen Systemen nun mal so nicht mehr gibt.

Mit den alten Systemen funktionierten die Hackintosh-Systeme mit dieses Kext's damals noch ganz gut, auch wenn sie dann tatsächlich nicht immer die volle LTE-Geschwindigkeit darstellen konnten, je nach Modell.

Ich frage mich, ob man diese WWAN-Geschichte unter macOS noch wirklich braucht, zumal man in bei den meisten PC-Lappi's in den WWAN-Slot super eine moderne zusätzliche SSD einbauen kann, welche für mich mehr Sinn machen würde, z.B. für Daten, Zweitsysteme Win oder macOS. etc. pp..

Ist natürlich nur meine eigene Meinung.

Die Geschichte erinnert immer ein wenig an die Fingerprint-Geschichte, welche in WIN-Laptops noch heute verbaut wird und auch damals noch unter macOS ging, bis Apple die Entwicklung einfach aufgekauft hat und dann war Ende mit Hackintosh.

Wenn man die Unterstützung dieser alten Kext's wirklich zurück bringen will, dann müsste man dies den OCLP-Entwicklern beibringen, so dass sie ein Rollback von alten Systemen einbauen. Fraglich, ob es soweit nach hinten noch möglich ist und fraglich, ob die Entwickler da Bock drauf haben.

Ich hatte die Seite angesehen und schrieb auch, ausprobieren.

Edit:

Ich hatte heute früh nicht die Zeit, ausgiebig zu antworten, sorry.

Ja, natürlich habe ich die Seite gelesen, bin aber dennoch skeptisch, was dabei wirklich geht. Im Prinzip müsste OCLP ja das Rollback der Kext's von HS zurück ins System bringen, was ein ziemlich weiter Weg bis BigSur und weiter ist, bezüglich aller neuen Metal-Funktionen.

Steht ja auch so auf Deiner verlinkten Seite, dass trotz allem einige Funktionen nicht so gehen, wie es bei unterstützten Mac's wäre, was ich bei meinen Test's mit realMac`s und Hacki`s auch so bestätigen kann, selbst bei non-Metal-Patches Nvidia gibt es Probleme, leere Seiten bei Safari-Aufruf und vieles mehr.

Ich hatte lange mit MacPro3,1 mit original HD5770, Dell Hacki mit HD5450, Fujitsu Hacki, ich glaube eine HD6470 oder HD6450 war es und diverse iMac's dieser Ausstattung versucht, hatte nie wirklich gefruchtet.

Erstgenannte liefen mit Umstieg auf Kepler ohne Probleme weiter. Inzwischen kann ich es aber nicht mehr selbst testen, da ich alle diese Geräte verkauft habe. Der TE kann uns schlauer machen, diesbezüglich.

Ich bin da echt selbst gespannt, sofern der TE den Test wagen möchte, ob es inzwischen wirklich gut geht, Dock etc. auch transparent geht, etc., mal abwarten, wo es dabei dann noch klemmt.

Ob dies dann auf der älteren Kiste dann noch brauchbar zügig läuft, ist eine ganz andere Geschichte. Viele User mit Rechnern dieser Generation sind dann zu Catalina zurück.

Vielleicht warten wir einfach mal ab, ob es Berichte von Usern gibt, welche noch heute mit dieser Art Grafik und Patches arbeiten.

Arkturus

Ja, natürlich ist Catalina für ältere Rechner aktuell noch eine Option. Die alten Rechner werden bei neuen Systemen mit all den Patches sicher nicht schneller.

Catalina brachte ja die Unterstützung für AppleTV-App, Musik und ich glaube auch Fotos-App, bekommt zwar keine Updates mehr, aber bis heute funktioniert nach alles, bis auf einigen Einschränkungen, wie z.B. HomeKit nicht mehr ganz vollständig unterstützt.

Die Apple-Office-App's in dafür letzter Version gehen noch immer, Safari, Mail, iMessage, Facetime, etc. bislang auch ohne Probleme.

Habe selbst noch einen Legacy-Rechner mit Core2Duo auf Catalina und da geht noch alles, auch die Apple-Services.

Meiner doch sehr alten Mutter habe ich einen iMac 24" 2008, schon vor Jahren hingestellt, läuft heute noch mit Catalina ohne Probleme und nicht einmal langsam.

Wie lange noch? Keine Ahnung. Abwarten.

iMac 27" 2010 ist iMac11.3

MacRumors Thread "macOS 10.15 Catalina on Unsupported Macs" steht's anders.

Steht dort sogar mehrfach, keine Grafikbeschleunigung mit Radeon HD 5xxx or 6xxx series, auch Dosdude Patcher hat nie was anderes geschrieben.

Auch dort im "macOS 12 Monterey on Unsupported Macs Thread" steht hier iMac11.x ++

Bitte den Hinweis für ++ lesen!

Es gibt seit nach High Sierra keinen mir bekannten non Metal Patch für HD 5xxx oder 6xxx. Viele haben es versucht, gefruchtet hatte es aber wohl nie wirklich.

Für Radeon HD 4xxx soll es was geben. Für die ganzen Intel HD's HD 2xxx, 3xxxx, 4xxxx, etc. gab und gibt es auch was. Für Kepler gibts ohnehin die non Metal Patches.

Installation ist ja auch möglich mit Fixes ohne Dunkelbild, aber ohne Beschleunigung, aber wozu? Macht keinen Sinn.

Ich hatte diverse Geräte (Mac's/Hackintosh), dieser Art, mit dieser Art Grafik und nach HS ging nie was mit Grafikbeschleunigung, habe es aber in jüngerer Zeit nicht mehr selbst geprüft.

Sollte es inzwischen doch was geben, dann wäre es in dem Fall ja gut für den TE, aber ehrlich, ich glaube es nicht, weil die Entwicklung diesbezüglich damals bereits aufgegeben wurde, hatte es damals lange verfolgt und selbst getestet.

Der TE kann es ja versuchen, warum nicht, kann man ja auf einem zweiten Volume testen.

Zitat MacGrummel : "Ist schon krass: den Mini-Prozessor & Grafik gab's mit 27er Bildschirm - und jetzt gibt's den aktuellen iMac M4 nur mit nem 24er Mini-Schirm!"

Darüber bin ich auch enttäuscht, wobei der neuere iMac auch eine ganz andere Auflösung bietet, aber im Prinzip bin ich hierbei ganz bei Dir und auch enttäuscht von Apple. Die iMac's waren immer sehr beliebt und nachdem der erste neue iMac kam, dachte wirklich jeder, dass da bald der Kracher kommt, aber weit gefehlt, leider.

Ein iMac 27" M4 pro würde ich wohl selbst auch sofort kaufen. Verstehe gar nicht, warum Apple in der Sparte bislang nicht reagiert. Anscheinend machen die Pro-Nutzer für Apple kaum noch Sinn, was man an der Entwicklung Mac Pro ja auch sehen kann. Vielmehr setzt man nur noch auf KI-Kinderkram, um lustige Bildchen mit komischen Frisuren zu erstellen, leider.

Ich frage mich, wer von den Pro-Nutzern diesen Mist überhaupt braucht.

Arkturus

Wurde mit Festplatte oder SSD ausgeliefert, was der TE aber in Systeminformationen oder Festplattendienstprogramm sicher schnell auflösen kann.

Nio82

Ich hätte dem TE wirklich gewünscht, dass es tatsächlich ein iMac 27" 2013 ist, wie ja die Überschrift anfänglich gelautet hat.

Nun ist es aber nur ein iMac 2010 und der Te schreibt ja selbst, geschenkten Gaul....

Allerdings sind Deine Angaben zum 2010 so nicht richtig, da bei dem iMac tatsächlich bei High Sierra Ende ist, nix Dosdude oder OCLP, zumindest nicht mit Grafikbeschleunigung, was am langen Ende keinen wirklichen Sinn macht.

Für die verbaute Grafik Radeon HD 5xxxx und auch für HD 6xxxx gibt es keine Patches für Grafik-Beschleunigung, weder in Dosdude-Catalina-Patcher, sowohl nicht im Nachfolger OCLP.

Lediglich ein Umbau auf Nvidia Kepler würde hier weiter gehen, was auch in der OCLP-Anleitung so steht, was sich natürlich absolut nicht lohnt.

Fazit:

Der TE hat was zum Spielen und hat nun ein Mac-System, wo er mal saubere Sticks für weiterer Projekte erstellen kann.

Ist so, wie griven schrieb. Versuch dies mal!

Zitat Post#1: "Der Vorbesitzer hat das Betriebssystem gelöscht", ist natürlich mega dumm vom Vorbesitzer. Normal gibt man den originalen Mac zumindest mit last macOS in CleanInstall weiter.

Dein Mac wurde mit 10.8 bis 10.9 ausgeliefert, kann max Catalina nativ und liefert in der Recovery High Sierra, obwohl er nativ bis Catalina ist. Dies liegt aber daran, dass mit Installer für HS weitere Firmware-Updates geliefert werden, welche dann später Catalina nativ möglich machen.

Da der Vorbesitzer die Platte/SSD vermutlich mit einem neueren System gelöscht hat, sollte man evtl. die Platte/SSD in der Recovery Festplattendiesprogramm nochmals Formatieren in Guid/macOS extended, den Wechsel zu APFS macht der Installer dann ohnehin selbständig.

Fakt ist nur, dass die Internet Recovery nicht geht, wenn die interne Platte/SSD nicht beschreibbar ist, ggf. muss man mal mit einer Linux-Live auf die Platte/SSD schauen, was genau da los ist. Die Daten, welche über Internet-Recovery geladen werden, müssen auf der Platte/SSD schreibbar sein, erst dann kann MacOS daraus installiert werden.

Ferner hat Du noch die Möglichkeit hier nach Ersthelfern zu fragen, die in Deiner Nähe wohnen, dann ist die Sache vermutlich nach einer Stunde gegessen, mit einem sauberen macOS Catalina Stick. Alles danach mit OCLP ist dann eine andere Baustelle.

Beim 2012 gab es diese Art Probleme auch noch nicht, es sei denn, der Vorbesitzer hat aktiv was gesetzt.

Bei den neueren Mac's mit der höheren Sicherheitsstufe wird das PW automatisch passiv bei Erstanmeldung gesetzt.

Zitat: "Also ich verstehe vom Real Mac Nix, obwohl ich Late 2017 wegen einem Mac mini hier im Forum gelandet war." Es gab Macmini Late 2014 und dann 2018 (Oktober 2018 bis Januar 2023), letzterer hatte auch den besagten T2-Chip.

Den Mini 2017 gibt es so nicht, somit bringt es dem TE nix, weil die Angabe schon falsch ist.

"Google's Treffer wie Sand am Meer" bringen hier nix, wenn er nicht das PW vom Erstbenutzer hat, wenn er via DFU-Mode einen T2-Chip zurücksetzen will.

Ihr könnt ja gern was anderes sagen, sofern ich doch falsch liege, was ich aber nicht glaube.

Edit:

Mal davon ab, meldet sich der TE seit Post#3 ohnehin nicht mehr und vermutlich, aus Erfahrung, kommt da auch nix mehr, daher ist es ohnehin nicht nötig, dass die User sich hier gegenseitig angreifen, was hier wieder passiert ist und auch mehr als unnötig war.

Also, Abhaken!!! Hinweise wurden nun wirklich in allen Richtungen gemacht und was der TE nun daraus macht, ist allein seine Sache.

Edit2:

Diese Art Mac's müssen bei Verkauf über die Zurücksetzten-Funktion auf Auslieferungszustand zurück versetzt werden. Genau wie im DFU-Mode wird dafür das PW verlangt, was man hierbei aber wohl hat.

Danach wird der Käufer beim Einschalten begrüßt, als hätte er ihn frisch ab Werk gekauft. Mit Eingabe seiner Daten wird wieder automatisch das PW gesetzt.

Will er nun wieder Verkaufen, meldet aber nur iCloud ab, dann wird es für den nächsten Benutzer auch gehen, solange er nicht zurücksetzen muss, weil dafür noch das PW des Verkäufers aktiv ist.

Quote from griven

Nur kurz zu der Sache mit dem "editierten Post"...

Raoul Duke Du hast recht es gibt eine Änderungshistorie im Forum und der kann ich entnehmen das bluebyte in der Bearbeitung seines Posts tatsächlich lediglich den Nachtrag ergänzt hat den post ansonsten aber nicht verändert hat vielleicht hast Du hier wirklich etwas missverstanden beim ersten lesen des Posts? Anyway Du schreibst ja selbst die Sache sei für Dich erledigt demnach sollte es dann auch dabei bleiben.

Generell: bitte haltet Euch mit Spekulationen zur Herkunft des Gerätes und der Hintergründe wie es dazu gekommen ist zurück. Es ist nicht an uns zu urteilen ob der TE hier möglicherweise Opfer oder ggf. doch auch Täter ist. Denken kann man sich seinen Teil spekulieren sicher auch einiges mehr aber auch nicht. Der TE gibt an das Gerät auf eBay gekauft zu haben und der Verkäufer kann keine Angaben zum PW machen mehr wissen wir erstmal nicht. Wir kennen keine weiteren Details insbesondere nicht ob es sich bei dem Verkäufer um eine Privatperson (Wahrscheinlichkeit das es ein gestohlenes/unrechtmäßig in sein Besitz gelangtes Gerät ist hoch) oder um einen gewerblichen Verkäufer handelt. Für den Fall das es sich bei dem Verköufer um einen gewerblichen Verkäufer handelt ist es gar nicht so ungewöhnlich das solche Dinge passieren denn gewerbliche Verkäufer kaufen Leasingrückläufer von IT Dienstleistern als ungeprüfte Palettenware auf und verkaufen sie dann, nach mehr oder weniger sorgfältiger Prüfung und Aufbereitung, auf eigene Rechnung weiter. Das die IT Abteilung einses Unternehmens welches solche Kisten am ende ihrer Nutzungszeit aussondert kein gesteigertes Interesse daran ein evtl. gesetzts Firmware PW vorher zu entfernen oder gar die Rechner aus dem Unternehmenseigenen MDM zu nehmen oder den iCloud Account vorher zu deaktivieren dürfte wohl auf der Hand liegen.

Ich kann hier von einem aktuellen Beispiel berichten bei dem es genauso gekommen war. Ein mir bekannter User hat ein gebrauchtes MacBook Pro (16 Zoll, M2 Pro Chip) von einem gewerblichen Händler auf ebay gekauft (alles sauber gelaufen inkl. Garantie und allem Pipapo) welches klaglois seinen Dienst verrichtet hat bis zu dem Zeitpunkt an dem der User das OS auf dem Book wiederhestellen wollte weil ein macOS Update dauerhaft unverhältnismäßig hohe Last verusacht hat. Beim Versuch das Book zu restoren kam die Aufforderung das MDM PW einzugeben was natürlich nicht bekannt war. Der Händler hat es ebenfalls nicht besorgen können und nach einem Jahr Nutzung am langen Ende ein Ersatzgerät geliefert. Leider passieren solche Dinge immer wieder und gerade bei Apple wird auf die Weise eine riesen Menge (unnötiger) Elektorschrott erzeugt eben weil auch Apple sich hier grundsätzlich querstellt und sich weigert solche Geräte zu entsperren...

Display More

Alles richtig und kann ich so bestätigen, aus einiger Erfahrung mit den neueren T2 Chip Geräten, allerdings mit einigen Zusätzen.

Dem Verkäufer, Zitat Post#1 "Der Verkäufer gab an, das iCloud-Passwort sei unbekannt", muss ich hier sagen, dass es so nicht geht, mit dieser Aussage. Mac mit nicht abgemeldeten iCloud verkauft man nicht, was ein Händler wissen sollte. Ansonsten kann und will ich nicht beurteilen, ob hier wirklich grob fahrlässig gehandelt wurde.

Ansonsten ist Apple an dieser ganzen Geschichte absolut nicht ganz unschuldig und dies hat überhaupt nichts mit "geklaut" zu tun.

Ein Verkäufer ist zurecht im guten Glauben, wenn alle iCloud-Services inkl. Find My Mac sauber abgemeldet wurden und dies geht auch absolut gut für den neuen Benutzer, bis dahin, was bei alten Mac's auch nie ein Problem war, aber...

Tritt jetzt aber der Fall ein, insbesondere in vergangener Zeit oft bei den neueren MacBook Air und MacBook Pro passiert, dass es nur noch Update-Probleme gibt und nichts mehr geht, Updates gar nicht mehr gehen oder nur noch Probleme machen, insbesondere wenn man auch die Beta's gefahren ist, dann nur noch der DFU-Mode geht (was auch Apple dann so schreibt), dann werden immer die Daten vom letzten Benutzer verlangt.

Selbst mit völlig richtiger iCloud-Abmeldung ist dies so und hier muss der Fehler ganz klar bei Apple festgemacht werden, weil diese Daten ja niemand beim Verkauf mit gibt.

Kann man auch mit Internet-Suche "mac t2chip dfu mode zurücksetzen" bei Apple's Anleitung sehen, dass sowohl bei Reparatur, als auch bei Wiederherstellen, immer das BenutzerPW des letzten bekannten Benutzers verlangt wird, was ich aus eigener Erfahrung auch so bestätigen kann, auch wenn ich zum Glück natürlich die Daten kannte.

Fazit:

Also absolut nicht erforderlich dem TE hier Unterstellungen zu machen, auch wenn er bei der Aussage des Verkäufers schon echt gutgläubig war.

Sofern der TE den Kauf bei ebay komplett nachweisen kann, auch die Daten des Verkäufers, dann kann er getrost zur Problemlösung in den Store gehen, denn für diese Geschichte kann er gar nichts.

Diese Aussage von mir natürlich auch nur bei wirklich sauber abgemeldetem iCloud-Account, was ich so natürlich auch nicht beurteilen kann, was den Händler betrifft.

Nachtrag:

Der beschriebene Mac mini 2018 hat auch den T2 Chip, somit vermutlich die gleiche Geschichte. Ich füge dies nur noch an, weil ich diesen oben explizit nicht genannt hatte, was aber eben genau gleich ist in dem Fall.

Wenn's normale SATA-SSD's sind, dann reicht auch so ein Adapter, dann musst Du nix ins Gehäuse schrauben, bzw. beim Wechsel Umschrauben.

Gibt's auch als USB-C zu SATA Variante, alles im großen Laden für Lau. Leichter und schneller geht nicht, nutze ich seit Jahren in allen Varianten an den Mac's.

Beispiel:

Dieser User hatte Sound auf der Kiste, allerdings noch unter BigSur:

https://github.com/jerryhan77/dell-optiplex-7070mff-opencore

Es ist ja oft so, dass die User die alten Kisten dann verkaufen und nicht weiter an der EFI arbeiten, aber man kann die EFI ja auf neueres OC anheben und die Kext's erneuern.

Ich selbst habe meine EFI's bei meinen Hackintosh-Lappi's über viele Versionen erneuert und betreffs Audio hat sich da nie was geändert, höchstens mal neue bootargs oder Kexts, welche für die neue Version nötig waren.

Betreffs usbports.kext oder Audio war dies aber immer gleich.

Er hat hierbei nur HPET.aml verwendet. Die IRQ-Patches für RTC und TIMR sind evtl. auf dieser Kiste gar nicht nötig.

Ferner sind die EFI's für Dell 3070, 8080mmf und 7070m wohl alle ziemlich gleich, wobei man auch Informationen abkupfern könnte.

Die angegebenen Bios-Einstellungen sollte man beachten.

Er hat betreffs Audio ein DeviceProperties mit layoutID 0B gesetzt, was ja 11 entspricht und zusätzlich alcid=11 als boot-arg gesetzt.

Einfach mal die EFI's vergleichen, dann wird es auch mit neueren macOS-Versionen laufen, wenn man die Erkenntnisse aus früheren EFI's entsprechend anwenden kann.

Startsound wird hier eingestellt:

...hat mit dem späteren Sound im System aber nichts zu tun. Es ist ziemlich sicher, dass Du HPET lösen musst und ggf. auch die IRQ-Patches RTC und TIMR, dann wirst Du auch Sound im System bekommen.

Zitat: Aber wie kann es denn sein, dass mit der EFI Hackintosh-OptiPlex-7070-MFF dieser typische Mac Start Ton kommt, und mit meiner EFI nicht? Also muss diese EFI doch wohl Sound haben, oder?!

Weil in Deiner EFI 0x1B eingegeben war und in der EFI Hackintosh-OptiPlex-7070-MFF war es richtig 0x1F,0x3

Wie ich schon oben weiter geschrieben hatte, wenn HPET nicht passt, dann gibt's auch kein Sound unter Hackintosh. War schon immer so. Dann siehst Du auch kein Gerät unter Hackintool/Sound.

In der PCI-Liste ist die Hardware immer zu sehen.

Versuche mal als Variante 1 diese aml einzubinden:

SSDT-HPET.aml.zip

oder als Variante 2 diese aml und IRQ-Patches:

ACPI.zip

Diese Hinweise stammen von Usern auf GitHub, welche für Dein Gerät EFI's für BigSur bis Sonoma gebaut haben und mit LayoutID 11 Audio haben, teilweise wohl auch mit entsprechenden Grafik-Properties-Framebuffer-Eintrag auch HDMI/DP-Audio haben.

"PCIe Devices geht vor boot-arg." Seit wann? War früher immer umgekehrt, alcid=xx hatte immer Vorrang vor PCI-Device-layout-ID-Eintrag.

Ok, danke, dann spielt csr-active-config ja keine Rolle bei Lilu + AppleALC, ich hatte dies nicht mehr genau auf dem Schirm.

Da ich nun schon seit längerer Zeit nur noch mit relaMac's arbeite, noch einen älteren Hackintosh habe und auch nur noch einige unsupported realMac's betreue, bin ich gerade aus der Erinnerung etwas überfragt, ob Lilu + AppleALC mit csr-active-config 00000000, quasi SIP enebled, noch die Rechte hat, die Layout-ID's zur Laufzeit bei Boot ins System zu impfen.

Vielleicht können hier andere User noch diesbezüglich antworten. Ich bin hier nicht ganz sicher. Bei den WLAN-Patches musste SIP immer entsprechend eingestellt werden.

Falls man hier dann auch mal mit csr-active-config 030A0000 versucht, muss man natürlich csr-active-config auch unter nvram/delete eintragen, damit die Änderungen nach Boot auch fruchten.

Ich vermute ganz stark, dass Du die IRQ-Patches brauchst, wie ich es oben beschrieben habe, denn davon ist in der Eli nichts zu sehen und ich gehe davon aus, dass Dein Gerät ein Laptop-Bios hat.

In der config.plist hast Du unter UEFI/Audio auch einen falschen Device-Pfad drin "PciRoot(0x0)/Pci(0x1b,0x0)". 0x1b,0x0 hatten frühere ältere Rechner, Deiner hat Device ""PciRoot(0x0)/Pci(0x1f,0x3)"".

...oder mal Deine aktuelle EFI hier hochladen, dann sehen wir evtl. auch wo es klemmt.

Tatsächlich ist es alc255, denn alc3234 ist ja nur ein Pseudo-Name verschiedener Hersteller.

In AppleALC sind dafür die folgenden ID's speziell für Optiplex konfiguriert, siehe Bild, wobei natürlich auch die anderen ID's für Dell, Acer und weitere Hersteller durchaus Ergebnisse liefern können, weil die ID's oft sehr gleich sind, aber natürlich würde ich mal mit ID 11, 12 und 66 anfangen.

Hierbei ist der Hinweis betreffs boot-arg in der config.plist unter nvram/add/boot-arg ein sehr guter Weg, z.B. alcid=11 oder alcid=12 oder alcid=66 mitgeben, natürlich Lilu.kext und AppleALC.kext in der EFI mitgeben und wichtig, auch in der Reihenfolge.

Natürlich sollte dann in der config unter nvram/delete auch boot-arg gesetzt sein, damit die Änderungen nach Neustart auch wirksam werden können.

Wenn Du mit all diesen Versuchen dann im Hackintool unter Audio noch immer nichts siehst, dann liegt es an der vermutlich verbauten Laptop-Hardware und dem vermutlichem Laptop-Bios.

Alle Laptop's und auch diese Art Mini-Desktop-PC's brauchen den HPET-Patch und die IRQ-Patches für RTC und TIMR, damit Audio unter macOS mit Hackintosh und AppleALC geht.

Hierbei muss IRQ 0 und 8 aus RTC und TIMR gepatcht werden, weil 0 und 8 für HPET konfiguriert werden muss. Hierbei ist das Script ssdttime auf GitHub evtl. Dein Freund.

Ferner kann man auch die Internetsuche "OPTIPILEX 7070 MFF EFI github" bemühen, ob man ggf. eine EFI findet, welche diese Patches schon drin haben.

Hierbei auf spezielle SSDT.aml's oder DSDT-Patches in der config.plist achten!

Ich habe bei der Suche schon einige EFI's gesehen, welche bereits Audio mit dem Gerät hatten, auch wenn die EFI's von Monterey oder BigSur waren, aber wenn's dort ging, dann geht's auch noch weiter mit AppleALC und Audio.

Also einfach mal diese EFI's studieren und Du kannst Dir vermutlich ganz schnell selbst helfen. Info's abkupfern ist keine Schande, haben wir alle schon genutzt.

Kommt scheinbar nicht so ganz an. Hatte ich bereits in Post#6 alles geschrieben. Auf dem realMac braucht man die EFI nicht händisch verschlimmbessern, OCLP macht alles.

Sicherheit liegt doch eher am eigenen Verhalten, oder?

Früher gab es kein SIP in macOS-Versionen und dennoch war das System sicher, sofern nicht ein User irgend einen Blödsinn verzapft hat, was auch heute noch so ist.

SIP hat mit dem eigenen Verhalten nix zu tun und natürlich kann man SIP entsprechend freigeben, so dass gewisse Patches möglich werden. Viele haben den Sinn von SIP nicht wirklich verstanden.

Apple's Hintergrund war betreffs SIP-Einführung damals sicher eher der Hintergrund, dass viele Apple-real-Nutzer, mit vollem Zugriff auf die Systemplatte, wie es ja damals üblich war, sich oft selbst das System zerschossen hatten und Apple einen riesigen Support liefern musste.

Dies haben sie nicht wegen Hackintosh eingeführt, ganz sicher nicht.

Vielleicht nicht der einzige Grund, vielleicht stecken auch noch weitere Aspekte dahinter, aber die Aussage "Ich will SIP nicht brechen", ist oft nicht der richtige Weg in Sachen Hackintosh und Patches für WLAN/BT.

Die Broadcom-Karten funktionieren noch heute mit den aktuellen Patches und dies im vollen Umfang, was die Apple-Services und Airdrop angeht.

Natürlich gehen auch die Intel-Karten, sind dann aber im Universum nicht nativ und brauchen ggf. Zusatzsoftware, z.B. als Ersatz für Airdrop.

Ja, das 13 Zoll aus 2015, laut Deiner Angabe ganz oben, bis macOS Monterey ohnehin nativ.

Für mehr ist OCLP Dein Freund, mehr braucht es nicht.