Beiträge von griven

Den Inhalt des Screenshots kann man bestenfalls erahnen aber eines fällt dennoch auf da fehlt noch was entscheidendes...

Die IOSkyWalkFamily.kext ist zwar drin aber der IO80211FamilyLegacy.kext fehlt noch und ohne den kann das natürlich auch nicht klappen. Sorry aber den habe ich komplett aus den Augen verlohren bei dem ganzen hin und her...

Also erst den iOSkyWalkFamily.kext dann den IO80211FamilyLegacy.kext erst dann den AirportBRCMFixup einfügen dann sollte es klappen.

Kannst Du mal bitte die EFI anhängen mit der Du gestartet bist also den Stand VOR Deinen Bastelaktionen ?!?

Für mich hört sich das Reboot Thema nach der Installation von OCLP nach einem simplen vergessen des Block Eintrags für die IOSkywalkFamily.kext an wenn ich ehrlich bin das Verhalten deckt sich nämlich mit dem was Du beschreibst. Bindet man die Version die zum Patch passt ein und vergisst die von macOS mitgelieferte zu blocken gibt es einen lustigen Kernel Panik -> Reboot Loop...

Okay unter Kernel -> Block trägst Du ein:

Unter dem Punkt NVRAM trägst Du folgendes bei ADD ein (wobei hier nur er Wert für CSRActiveConfig relevant ist für Dich:

und unter Delete:

Unter Kernel ADD dann den oben angesprochenen IOSkyWalkFamily.kext hinzufügen und aktivieren. Hierbei auf die Reihenfolge achten der IOSkyWalkFamily.kext gehört idealerweise vor alle AirpotBRCMFixup Geschichten. Ebenfalls hinzufügen solltest Du AMFIPass.kext (https://github.com/dortania/Op…FIPass-v1.4.0-RELEASE.zip) erleichtert im Anschluss so einiges. System damit starten (zum testen immer mit einem USB Stick arbeiten und die EFI erst übertragen wenn es läuft!!) und anschließend den OpenCoreLegacyPatcher in der aktuellsten Version ausführen, Neustarten und testen ob WLAN dann wieder funktioniert.

Ja klar das muss man ebenfalls aber eben nur wenn man die "neue" auch injected was allerdings bei der vorliegenden config.plist nicht der Fall ist

Ich war ehrlich gesagt davon ausgegangen das das passiert ist (block) weil es ja vorher schon lief und nur mit dem "problematischen" 14.4er Upgrade nicht mehr...

Nun diese config dürfte zumindest im Bezug auf WLAN bzw. die OCLP Patches gar keine Probleme bereiten denn hier ist ja nix dergleichen überhaupt eingebunden ?!?!

Bist Du sicher das das die config.plist ist die die Probleme verursacht?

Lade die EFI einfach mal hoch ich schätze Du hast da irgendwo nen Bock drinnen...

184 neue Zähne...

... verteilt auf 10 Rädchen *gg*

Dem Logfile folgend findet OC nicht startbares in/auf Deinem Rechner...

Wie hast Du denn den Punkt ScanPolicy unter Misc->Security in der config.plist eingestellt (idealweise setzt Du hier erstmal den Wert 0 und passt den an wenn das System installiert ist)?

Ist eigentlich ziemlich einfach und straight forward...

1. IOSkyWalkFamily.kext austauschen gegen die Version von hier: https://github.com/dortania/Op…/main/payloads/Kexts/Wifi

2. IOSkyWalkFamily.kext in der OC Config.plist aktivieren

3. OCLP in der aktuellen Version (https://github.com/dortania/Op…atcher/releases/tag/1.4.2) installieren und RootPatches ausführen

4. Reboot und über laufendes WLAN freuen

Voraussetzung ist natürlich das WLAN vor dem Update auf 14.4 mal funktioniert hat was aber ja der Fall war soweit ich das überblicken kann.

Das habe ich mich allerdings auch schon gefragt

Wolfe Korrektur in welche Richtung schwebt Dir vor?

Viele, wenn nicht alle, WLAN Probleme lassen sich unter 14.4 mit der neuen OCLP Version (1.4.2) beheben. Am Elitebook läuft WLAN (Fenvi) damit nun wieder komplett rund will meinen keine "vergessenen" Autojoins mehr, kein vergessen des bekannten Netzwerks mehr notwendig usw...

Es gibt inzwischen eine neue Version vom Patcher (1.4.2) welche die Probleme mit dem automatischen verbinden mit bekannten Netzwerken beheben soll. Falls nicht schon automatisch passiert dann das Update installieren und die Rootpatches erneut ausführen. Soweit ich das in den Commits sehen kann ist hier insbedondere die Version der 3 Frameworks von 13.6.2 auf 13.6.5 gehoben worden (CoreWiFi.framework,IO80211.framework und WiFiPeerToPeer.framework)...

Verliert man am Hack leicht aus den Augen weil man sich hier manuell darum kümmern muss...

Bei alten Äpfeln macht der Patcher das ja direkt mit wenn die OpenCore Version auf den aktuellen Stand gebracht wird...

Hast Du den IOSkywalk.kext auch ausgetauscht? Die 14.4 braucht eine andere Version dieser Extension findest Du hier: https://github.com/dortania/Op…OSkywalkFamily-v1.1.0.zip

Manchmal kann es dann doch so einfach sein

Nice das die Kiste nun (wieder) das tut was sie tun soll.

Monchi_87 nur so eine Idee und bitte auf dem Stick zuerst testen aber nimm mal das BootArg agdpmod=pikera raus (nur testweise natürlich)...

al6042 Du hattest doch auch mal ne VEGA56 gab es da irgendwelche Tricks bzgl. Dual/Triple Monitor Setups ?!?

Die wird das Dock nicht wirklich verlangsamen vermutlich wird sie aber auch nicht (mehr) wirklich gebraucht...

Diese SSDT bzw. die Definition in der SSDT erweitert das Device AMDX (GFX0 intern) um eine Device Spezifische Methode (_DSM). in der DSM Methode werden Device Eigenschaften definiert bzw. näher beschrieben. Im vorliegenden Codeschnipsel wird dem Device die Information darüber hinzugefügt das es sich bei dem HDA Codec auf der AMD um einen onboard Codec handelt. Benötigt wird das unter Umständen dafür das die Audio Ausgabe über HDMI oder Displayport unter macOS wie vorgesehen funktioniert. Mit der Bildausgabe oder der Grafikbeschleunigung hat das rein gar nichts zu tun.

Das hört sich nach einer richtig guten Idee an Monchi_87

Wenn Du willst kannst Du schonmal vorab ein Backup machen damit man im Anschluss die Benutzereinstellugnen und Apps aus dem Backup zurückspielen kann (Timemachine oder so taugt dafür)...