Beiträge von griven

Ich möchte an der Stelle darum bitten das ggf., falls notwendig, bitte per PN oder auf andere geeignete Weise auszudiskutieren und davon abzusehen das hier öffentlich zu tun ich danke Euch.

Hitzig würde die Diskussion jetzt nicht nennen wollen aber ja wir hatten das im Tahoe Thread ja schon auseinander gedröselt

So wirklich neu ist der Ansatz also wirklich nicht wobei ich aber auch nicht glaube das ST3R30 sich hier mit fremden Federn schmücken möchte sondern der Ansatz für Ihn und vermutlich auch viele andere hier wirklich "neu" ist. Begründen lässt sich das möglicherweise damit das die Lösung von Nico hier seit einer gefühlten Ewigkeit dokumentiert ist und praktiziert wird einfach weil es funktioniert und demnach auch nicht hinterfragt wird. Das USB Portmapping ist ja ohnehin irgendwie so ein einmalig notwendiges Übel das man dann eben erledigt (oft genug der Einfachheit halber mit der USBToolBox) und anschließend vergisst bis irgendwann Apple was am OS schraubt und es plötzlich nicht mehr geht. Das sich in der Zwischenzeit die Dinge weiterentwickelt haben ist dann komplett an einem vorbei gegangen einfach weil keine Notwendigkeit bestand sich damit zu befassen lief halt Jahrelang einfach so mit...

martin#001 da ist generell so einiges im argen mit dem Plugin...

Google schraubt aktuell mit wachsender Begeisterung and den API's rum bzw. weniger an den API's selbst und mehr and den API Keys und deren Berechtigungen. Hier müsste Coaster mal gucken für welche Dienste der aktuell hinterlegte API Key berechtigt ist und ggf. dessen Berechtigungen anpassen. Leider ist das alles nicht (mehr) sonderlich durchsichtig denn am liebsten hätte es Google das für jeden Dienst ein eigener Key in der Maps API eingerichtet und berechtigt wird. Eben das geht aber mit dem von uns für die Karte genutzten Plugin (und vielen gleichartigen) gar nicht weil das so gestrickt ist das das alle Services die angeboten werden über einen API Key abgewickelt werden (es gibt gar keine Möglichkeit mehr als einen Key zu hinterlegen). Alles in allem ziemlich nervig...

Ick denk wohl auch ich werde da sein

Und vermutlich auch die Erklärung dafür warum es bevorzugt im Bildungssektor zum Einsatz kommt denn gerade da macht es ja Sinn

Verschiedene Plattformen zu Hause und in der Schule bzw. an der Uni, Datentausch mit Schülern oder Studenten die dann auch wieder auf ganz unterschiedlichen Systemen arbeiten usw. hier ist eine plattformübergreifende OpenSource Lösung dann der beste Weg

BT ist eigentlich, bei kompatiblen Modulen, unkritisch und funktioniert in aller Regel einfach so und ohne weiteres zutun (ist zumindest bei der FENVI der Fall weil der Chip von Apple selbst verwendet wird) auch in den Systemeinstellungen kannst Du da eigentlich nicht wirklich etwas essentiell verbastelt haben denn da gibt es normalerweise nichts was BT komplett Schachmatt setzen würde

Der OCLP RootPatch wirkt sich im Falle vom "Modern Wireless" auch nur auf den WLAN Part der Fenvi Karte aus der BT Part ist davon komplett unberührt und eigentlich sein eigen Ding. Du musst Dir das so vorstellen das auf der kleinen Karte zwei Devices vereint sind einmal ein PCIe Device für die WLAN Funktion (vom Patcher beeinflusst) und unabhängig davon ein USB Device für das BT Gedöns. Wenn BT nach einem OS Wechsel unvermittelt nicht mehr funktioniert hat das in der Mehrzahl der Fälle mit der Firmware zu tun dazu muss man wissen das die Firmware immer erst im Bootprozess vom OS auf den BT Chip geladen wird was aber nur dann funktioniert wenn der Chip auch dazu bereit ist eine Firmware zu empfangen. Was Du jetzt testen kannst ist ob Dein BT unter Monterey noch tut wenn ja dann kannst Du zumindest schon mal ausschließen das ein Problem mit der Karte selbst vorliegt. Weiterhin kannst Du unter Sequoia auch mal gucken ob der BT Controller am USB Bus auftaucht (Systembericht -> USB) falls auch hier ja dann kannst Du auch das USB Portmapping ausschließen. Für alles weitere müsste man dann wissen was Du an Kexten wie in die EFI gebastelt hast (BRCMPatchRam3, BluetoolFixup usw.) und wie Du die einsetzt (Die Fenvi braucht für BT eigentlich nix von alledem)...

Es kommt gelegentlich vor das sich die Firmware bei den Dingern aufhängt bzw. nicht korrekt geladen wird was sich dann auch in einem nicht (mehr) funktionierenden BT äußert. Häufig passiert das in einem reboot Szenario wenn hier die Devices nicht korrekt Deinitialisiert werden. Testen kann man das indem man die Kiste einfach mal komplett herunterfährt bzw. ggf. auch mal stromlos macht...

Womit wir wieder bei der Denkweise und der mangelnden Erfahrung wären...

Monterey verwendet den klassischen Kextcache wie wir ihn aus den "guten, alten Zeiten" kennen nämlich gar nicht mehr sondern Monterey startet von einem versiegelten APFS Snapshot in dem sich dann eine KC (KernelCollection) befindet. An dieses, im Vergleich zu älteren Systemen, geänderte Bootverhalten muss man sich halt anpassen was bei den von Dir genannten Tools nicht der Fall ist. Jetzt ist, zumindest mir, einigermaßen unklar warum Du den Kextcache/KernelCollection neu erstellen möchtest denn eigentlich ist das zur Installation/Update auf Monterey absolut nicht notwendig alles was nötig ist kann sowohl Clover alsauch OpenCore über die KextInjection ins System einbringen wobei gerade bei Clover hierzu eine aktuelle Clover Version pflicht ist einfach weil die KextInjection der älteren Clover Versionen mit den "modernen" MacOS Versionen nicht mehr kompatibel ist. Du musst Dir also weniger Gedanken darüber machen das System selbst auf irgendeine Weise zu verbiegen sondern Deine Energie mehr in den Bootloader und dessen Konfiguration stecken und dann klappt das auch

Ohne jetzt Werbung für OC machen zu wollen ist gerade um OpenCore inzwischen ein recht ausgeprägtes Ökosystem an Tools entstanden die Benutzer gezielt dabei unterstützten auf möglichst einfache Art und Weise eine lauffähige Grundkonfiguration zu erstellen. Exemplarisch genannt sei hier zum Beispiel OpCore-Simplify (https://github.com/lzhoang2801/OpCore-Simplify) welches das (teil)automatische erstellen einer an die Gegebene Hardware angepassten OC EFI unter Windows ermöglicht. OpCore-Simplify läuft auch unter macOS hier weiß ich allerdings nicht ob das Ergebnis dann brauchbar ist die unter Windows von dem Tool erstellten EFI's sind es in aller Regel und benötigen im Nachgang, wenn überhaupt, nur geringen Feinschliff.

Am Elitebook und am M1 MBP grundsätzlich ohne Probleme gelaufen...

Am Elite mit dem OCLP-MOD den AppleHDA Patch rein und alles schick allerdings hat es mir beim Elite FileVault ungefragt angeschaltet! Keine Ahnung was das nun werden soll wenn das fertig ist aber irgendwie finde ich das schon fast ein wenig übergriffig was Apple da treibt (am M1 MBP kümmert mich das nicht da darf dat ruhig aktiv sein bzw. da ist es per se aktiv)....

Oh glatt vergessen dazu zu schreiben...

Das Launchpad musst Du manuell ins Dock ziehen Du findest es nach erfolgter Operation in den Programmen (Finder->Programme)...

Rückgängig geht natürlich ebenfalls hierzu folgenden Befehl im Terminal absetzen:

anschließend neu starten und damit das ganze einen Effekt hat noch:

Der Studentd Prozess ist Teil von Apples MDM (Mobile Device Management) und dafür gemacht auch zu laufen wenn das Gerät nicht im MDM ausgerollt ist. Dieser Prozess ist somit ein legitimer Teil des OS und soll bzw. darf laufen. Wenn der Prozess abstürzt liegt das in aller Regel daran das er sich nicht mit Apples Servern verbinden kann um den MDM Status der Maschine zu bestimmen/verifizieren. Falls Du irgendwelche Firewalls einsetzt (LittleSnitch und Co.) dann stell sicher das der Prozess "telefonieren" darf womit das Problem dann behoben sein sollte. Was die neue Spotlight Funktion angeht (Apps Icon) das ist ziemlich sicher ein Bug in der Beta und konkrete Abhilfe gibt es dazu aktuell nicht. Du könntest allerdings einfach das alte Verhalten (vor Tahoe) wiederherstellen und das gute, alte Launchpad anstelle von Spotlight nutzen. Hierzu ein Terminal öffnen und folgendes eingeben:

sudo mkdir -p /Library/Preferences/FeatureFlags/Domain

sudo defaults write /Library/Preferences/FeatureFlags/Domain/SpotlightUI.plist SpotlightPlus -dict Enabled -bool false

Anschließend einen Reboot durchführen und Spotlight verhält sich wieder so wie unter Sequoia und anstelle von App's befindet sich wieder das gewohnte Launchpad im Dock.

Na dann bleibt ja eigentlich nur noch zu klären wer eigentlich Paul ist :p

Danke an alle Beteiligten für diesen durchaus amüsanten Thread

Das ist unser Bot also ein "simpler" Automatismus der gewisse Dinge rund um die Pflege des Forums automatisch erledigen kann. Natürlich nur sehr begrenzt und nicht vergleichbar mit heutiger KI aber dennoch einige simple Dinge kriegt man so automatisiert...

Wäre vielleicht gut wenn Du eben schreiben würdest wo Du es gefunden hast nur falls jemand anders auch mal das Problem hat, danke Dir.

Das sind unterschiedliche Vorgehensweisen bluebyte

Eine SSDT ist immer eine Ergänzung zu eine schon bestehenden Definition. Wenn Du so willst ist sie eine Anlage die ein Gerät oder dessen Eigenschaften ergänzend genauer beschreibt. Je nachdem wie man nun vorgeht kann man entweder diese Anlage ersetzen (Drop SSDT) oder ergänzen. Nico geht in seinem Ansatz davon aus die Anlage zu ersetzen sprich er verwirft die bestehende SSDT und ersetzt sie durch eine eigene was man machen kann solange es eben eine SSDT gibt die solche Eigenschaften genauer definiert. Will man eine bestehende SSDT ersetzen muss die bestehende SSDT zuvor gedroped werden anderfalls führt das zu Problemen. Im Falle von Justfun ergänzt er aber die schon vorhandenen Informationen zum Device RHUB (unabhängig davon ob diese in einer SSDT vorliegen oder direkt in der DSDT) um eine Handlungsanweisung für den Fall das das OS Darwin ist. Für den Fall das es sich beim OS um Darwin handelt wird für das DEVICE RHUB einfach der Wert ZERO zurückgegeben sprich für macOS existiert das Device RHUB und somit auch dessen definierten Eigenschaften schlicht nicht. Anstelle von RHUB wird hier ein neues Device Namens XHUB an gleicher Adresse definiert das dann alle für macOS wichtigen Informationen enthält. Das ganze funktioniert ohne die bestehende Definition zu droppen weil macOS diese gar nicht mehr zu Gesicht bekommt. Die Lösung von JustFun ist an der Stelle eigentlich sogar die elegantere weil es in einer Multiboot Umgebung die anderen Systeme nicht beeinflusst. Ich bin da auch kein wirklicher Experte drin aber das, meine ich zumindest, habe ich verstanden.

Der Fehler ist bei HP Rechnern recht verbreitet und lässt sich mit einem Patch im Bereich ACPI -> Patch beheben (hatte das am Elitebook ebenfalls und ja ist wirklich nervig)...

Entweder den folgenden Codeschnipsel mittels PLIST Editor direkt einfügen:

Oder manuell in OCAT eintippen:

Wenn Du unter Tahoe unterwegs bist wäre es Sinnvoll das BootArg -lilubetaall noch hinzuzufügen denn ohne das Arg könnte es gut sein das diverse Extensions (so auch BluetoolFixUp) möglicherweise nicht gehen zudem kann es auch nicht schaden die beiden Werte für bluetoothExternalDongleFailed und bluetoothInternalControllerInfo im NVRAM Bereich zu setzen damit der FixUP seinen Dienst auch korrekt verrichten kann. Beides mal entsprechend gemacht, geänderte config.plist anbei...

DerTschnig sieht mir verdächtig nach fehlendem oder veralteten BluetoolFixup.kext aus zumindest lassen die Meldungen auf Deinem Bild darauf schließen...

Nope meinte ich nicht aber spielt in dem Fall auch keine Rolle

Verwende, wenn Du den Patch für WLAN nutzt, bitte für LAN den IntelMausi.kext dann sollte das meiner Meinung nach auch in Koexistenz klappen. Der native Treiber verlässt sich tatsächlich auf die IOSkywalkFamily und funktioniert dann entsprechend nicht mit der Version die für den WLAN Patch notwendig ist zusammen.

Der IOSkywalkFamily.kext kann sehr wohl auch was mit dem Internet Via LAN zu tun haben...

Was Du mal testen kannst wäre, wenn alles für den WLAN Patch ordnungsgemäß am Start ist, unter Kernel den Quirk DisableIoMapperMapping zu setzen sofern nicht ohnehin schon vorhanden beziehungsweise zu deaktivieren wenn schon gesetzt. Also beide Einstellungen einmal durchspielen. Ich meine mich zu erinnern das Mieze in einem anderen Thread mal was in die Richtung gesagt hatte.