UAD 11.8.2 Driver kann nicht installiert werden

hallo nights ,

hast du den amfipass.kext sowie das bootarg -amfipassbeta in deiner config.plist? vielleicht liegt es daran. ansonsten zur versionsnummer, ab tahoe wird 11.8.1 +höher benötigt https://help.uaudio.com/hc/en-…203-UAD-Software-Archives

vielleicht scheitert es daran.-an tahoe

lg

nights

das opencore nicht mehr mit tahoe läuft halte ich für ein gerücht, eher das die installation, und oder einrichtung eher frickelig ist, und desweiteren der offizielle "stable" strang des oclp derzeit quasi nicht verfolgt wird.

das du somit auf sequoia bleibst ist auch vollkommen ok, die letzten 3 os versionen von osx werden noch immer unterstützt und wenn ein tahoenachfolger kommt, fällt jeweils das letzte -in diesem falle sonoma- aus dem offiziellen support raus, ausnahmen mit dringenden patches mag es geben, siehe z.b. den mobile strang mit ipad und co welcher mit unter trotzdes alters dennoch abundan sicherheitsupdates bekommt.

der einzige unterschied scheinen ähnlich zu ms die feature-updates, also einpflegen neuer funktionen zu sein. ich persönlich finde es auch ok, bei seqouia zu bleiben, da geht es mir nicht anders,-aber das ist wie gesagt meine eingene meinung.

lg und viel erfolg weiterhin mit dem build.

lg

bist du bereits das hier durchgegangen? -> https://help.uaudio.com/hc/en-…ity-with-macOS-Sequoia-15

--

ansonsten, wenn es schlußendlich "kexte" sind, probiere z.b. mal mit 7zip das archiv zu öffnen, z.b. unter payloads im archiv, und die kexte zu extrahieren.

lg

---edit---

hallo nochmal, anhand deiner (oclp) config.plist -die wie ich das jetzt verstanden habe für einen realmac, dann wohl der aus deinem profil, erstellt wurde mittels oclp 2.4.1- ist ersichtlich, das dein smbios für den imac 18.3 erstellt worden ist, erstelle dir doch bitte eine für den (ab) imac 19.1 , da lässt sich uad installieren, da ich dort kein acc. habe kann ich dir insofern auch nichts näheres dazu sagen, nur, das es sich starten lässt. die debugversion, also den chinabuild vom oclp würde ich vermutlich nicht für einen realmac nehmen, finde ich persönlich für unsicher wenn dann nix läuft. durchfoste mal im forum den oclp-mod thread, wenn dich das interessiert. so das die menüeinträge dann auch in europäischen schriftzeichen zur verfügung stehen.

desweiteren hilft es auch dein anliegen im bereich der realmacs zu legen, sonst geht man von einem hacky aus-gut , mit dem oclp ist dein realmac ähnlich, aber eben kein "hacky" in dem sinne. der oclp ermöglicht manches , aber auch nicht alles. vielleicht hast du wie bereits erwähnt ja mehr glück, wenn du eben ein anderes smbios-ab imac 19.1 wählst.

da du das os auf einem dafür nicht vorgesehenen rechner nutzt, ist es auch möglich, das dir genau der oclp jetzt steine in den weg legt, dadurch das dein rechner für das os "kompatibel-u.a. durch ersetzen bestehender treiber , verknüpfungen..usw." gemacht wird, und diese dann nicht mehr gefunden werden. du hast dann zwar "das dem smbios gemäßen, aktuelle os-aber eben nicht alle der darin enthaltenen funktionen"

lg und viel erfolg

Das muss nicht zwangsläufig am SMBIOS liegen sondern kann durchaus auch mit der Arbeitsweise von OCLP als solcher zusammenhängen. Um die Patches ins System einbringen zu können muss der Patcher das Siegel des BootSnapshots brechen und genau damit habe einige Programme Probleme (unter anderem auch M$ Autoupdate welches nach der Anwendung der Post Install Rootpatches zuverlässig fehlschlägt). SO eine richtig greifbare Lösung habe ich da bisher noch nicht gefunden bzw. gibt es die wohl auch einfach nicht...

Universal Audio Treiber unterstützen doch macOS Tahoe noch gar nicht! Wie auch immer: wenn csr-active-config nicht 00000000 ist (wie bei Dir), dann muss AMFIpass.kext installiert werden, damit am Ende der Istallaition das pop-up für den Zugriff auf Peripherie-Geräte (Mics, Webcams, Interfaces, I/O) erscheint. Das hat nichts mit SMBIOS zu tun, sondern ausschließlich mit SIP und AMFI.

Wenn dann AMFIpass.kext installiert ist, kannst DU dieser Aneitung folgen https://help.uaudio.com/hc/en-…ility-with-macOS-Tahoe-26

nights

hast du einen pc und oder mac, mit dem du die efi bearbeiten kannst? wenn ja, hast du eine anleitung gegeben und kannst z.b. mit den ocat, opencore auxiliary tools die config.plist bearbeiten.-inwiefern man das auf eine oclp-efi anwenden kann weiß ich nicht.

--

amfi ist bereits kernelmäßig aktiviert, siehe_>

ob da noch das bootarg "-amfipassbeta" gesetzt werden muß->wobei der generalschlag bereits gesetzt ist mit "amfi=0x80" weiß ich nicht, die csr-active-config ist auch bereits so gesetzt, wie sie am pc-hacky aussehen würde mit der "csr-active-config-data-03080000" siehe ->

hier wird amfi erlaubt, inwiefern sich die argumente da gegenseitig ins gehege kommen weiß ich nicht
siehe ->

bei mindate, minversion käme beim pc meist der wert "-1" rein

das sind die werte, aus deiner hier geuppten efi

-der hacky-nutzer" nimmt meist nur die postinstall rootpatches, und kann beim hacky mit der vom oclp generierten efi, idr nix mit anfangen

lg

Generell wenn amifpass.kext zum Einsatz kommt hat das amfi=0x80 BootArg nichts in den BootArgs verloren. Das BootArg hebelt die Funktion von amfipass.kext aus indem es die Signaturprüfung durch AMFI komplett deaktiviert.

Kurz zum Verständnis:

• amfi=0x80 = Äquivalent zu amfi_get_out_of_my_way = komplettes Abschalten aller Signaturchecks
• amfipass.kext = Kernelextension die im Zusammenspiel mit Lilu dafür sorgt das bestimmte, mit dem Dortania Key signierte, Binärdateien adhoc signiert werden und somit den Signaturchecks von AMFI bestehen = AMFI bleibt aktiv und Systemseitig intakt.

Wenn es sich bei der Maschine des TE um Apple Hardware handelt dann sollte es demnach ausreichen das amfi=0x80 BootArg zu entfernen um ein mehr oder weniger intaktes AMFI zu haben. Sofern die Software sich "nur" daran reibt sollte dann auch die Installation funktionieren soweit ich das aber verstehe kommt es erst gar nicht dazu das die Abfragen kommen weil die Installation schon vorher fehlschlägt was mich zurück bringt zu meinem ersten Gedanken sprich die Installation scheitert weil das RootFS ein gebrochenes Siegel hat. In dem Fall könnte es klappen die Treiber zu installieren bevor die OCLP Post Install Rootpatches angewendet werden denn in dem Fall wäre zum Zeitpunkt der Installation das Siegel noch intakt und würde erst danach durch die Installation der Patches gebrochen...

Probier mal so: config.plist natürlich ohne Gewähr

So ziemlich das gleiche Problem wie beim M$ Autoupdater in Kombination mit OCLP...

Sobald das Siegel auf dem RootFS gebrochen ist schlägt die Installation zuverlässig fehl 🤷‍♂️ Gibt halt Software die sich verweigert wenn das RootFS modifiziert wurde machen kann man da nicht wirklich was ausser, wie bereits erwähnt, den Kram installieren bevor man die OCLP Patches anwendet...

Naja irgendwo ist das wohl der Gang der Dinge und man kann es den Herstellern von Soft/Hardware auch nicht verübeln das sie nicht mehr unterstützte Plattformen ihrerseits halt auch nicht mehr unterstützen. Man darf bei alldem halt nicht vergessen das der OCLP ziemlich massiv in das OS eingreift und einige Kernkomponenten des OS verändert bzw. Downgraded. Im Falle von Treibern kann das durchaus dazu führen das in den älteren Versionen der Frameworks oder API's benötigte Funktionen schlicht noch nicht verfügbar sind und somit dazu führen das der Treiber abstürzt oder im schlimmsten Falle sogar das gesamte OS nicht mehr startet.

Als Hersteller solcher Produkte würde ich auch sicherstellen wollen das mein Produkt auf der gegebenen Plattform bestmöglich funktioniert und ich meinen Produktsupport nicht mit Anfragen zu diffusen Verhalten auf modifizierten Systemen belasten würde. Wenn das, wie in diesem Fall, dadurch erreicht wird das Systeme mit modifizierten RootFS außen vor bleiben ist das wohl legitim 🤷‍♂️

Quote from nights

Vielen Dank für die Hilfe.

Frage könntest du mir das in meinem config.plist machen ? (siehe Daten Anhang)

P.S. Werde wohl nicht der einzige sein der dir sehr dankbar sein wird....

amfi=0x80 boot-arg entfernen und stattdessen -amfipassbeta verwenden.

Was mich irritiert ist, dass da keine ACPI Tables drin sind und auch kein SMBIOS ausgewählt.

ist bei echten Mac's im Zusammenhang mit OCLP nicht ungewöhnlich ST3R30