Beiträge von griven

    Passieren kann da nichts es eliminiert einfach eine Fehlerquelle die besonders bei älteren Macs im Zusammenhang mit USB und neueren MacOS Versionen auftreten kann (der Patcher behebt das aber eben erst nach der Installation). Die Idee USB als mögliche Fehlerquelle aus dem Rennen zu nehmen ist gar nicht schlecht :)

    Bei meinem 2015er MacBookPro musste ich erstmals auch OC manuell as Standard Bootoption setzen will meinen nach der Installation von OpenCore auf der SSD halt mit Option das Bootmenu aufrufen und dann EFI Boot markieren und mit Control+Enter als Standard definieren erst dann hat das Book das auch so übernommen. Manchmal scheint da der Teufel echt im Detail zu stecken :)


    Solange OC noch nicht auf der internen Platte installiert ist muss man halt echt aufpassen das man bei jedem Reboot peinlich darauf achtet EFI Boot zu wählen weil andernfalls halt eben der Apple eigene Loader startet was man ja nicht (mehr) möchte wegen der gegebenen Einschränkungen.

    Ja damit das geht muss der Rechner über OpenCore gestartet werden Du musst also den Stick noch mit einer OC EFI bestücken (kannst Du mit dem Patcher unter dem Punkt Build and Install OC machen). Der Rechner wird dann mit dieser EFI gestartet (Option Taste und EFI Boot wählen) anschließend kann der Installer ausgeführt werden. Wichtig ist das Du sicherstellst das EFI Boot während der gesamten Installationsdauer also auch bei den anstehenden Neustarts immer wieder ausgewählt wird (ggf. immer mit Option Taste wählen) denn andernfalls bricht die Installation ab weil der Mac eben nicht kompatibel ist.


    Ist ein wenig doof gelöst aber eigentlich easy wenn man es weiß. Wenn die Installation durch ist und Du OpenCore auch auf der Festplatte des iMac installiert hast kannst Du EFI Boot dann, falls nötig, mittel druck auf control+enter im Bootpicker als default setzten damit immer OpenCore zuerst gestartet wird.

    Wobei ich hier schon wieder das Problem nicht verstehe...


    Die Telefonnummer in der AppleID ist der zweite Faktor für die Zweifaktor Authentifizierung und dient letztlich der eigenen Sicherheit hier sollte man sich vielleicht doch zweimal überlegen ob man da irgendeine "dubiose" Wegwerfnummer verwenden möchte von der man im Zweifel nicht weiß wer darauf eingehende SMS mitliest und zu was die darin enthaltenen Informationen dann ggf. benutzt werden. Ich habe schon Verständnis dafür das man seine Handynummer nicht überall preisgeben möchte aber an Stellen wo es darum geht einen Account bei einem renommierten Anbieter wie zum Beispiel Apple abzusichern finde ich das übertrieben zumal Dich Apple weder anrufen noch mit SMS bombardieren wird. Manchmal macht man sich echt Probleme wo keine sind...

    Am langen Ende ist Gravis die eigenen gefühlte Exklusivität zum Verhängnis geworden. Wenn man sich komplett auf eine Brand spezialisiert die inzwischen auch gefühlt überall sonst zu haben ist dann steht man nunmal auf wackligen Beinen. Das Geschäft mit Apple Produkten war für Gravis auskömmlich solange es für die Kunden keine alternativen Anlaufstellen gab. Wer Apple im stationären Handel wollte der musste halt zu Gravis und genau das ist halt heute eben nicht mehr der Fall. Was Gravis echt verpennt hat ist sich weitere Standbeine zu schaffen und sich breiter aufzustellen. Es gibt heute kaum noch Gründe gezielt zu Gravis zu gehen Apple Produkte kann ich bei MediaMarkt, Saturn, Cyberport oder im schlimmsten Fall sogar beim Lidl um die Ecke kaufen und wenn ich was repariert haben muss gibt es inzwischen auch reichlich Alternativen...


    Anders als Gravis müssen die anderen Händler nicht vom Verkauf von Apple Produkten leben sondern für die ist das ein willkommenes Zubrot. Mit Masse und mit einem breiten Sortiment generiert man Laufkundschaft die dann ggf. auch ein Apple Produkt kauft (Impulskauf) gibt es nur eine Brand gibt es eben keine Impulskäufe und es gibt eben auch wenig Laufkundschaft. Niemand geht nur mal um zum gucken eben zu Gravis sondern wenn dann geht man da zielgerichtet und mit gefasster Kaufentscheidung hin...

    Eigentlich sollte das mit der Maschine schon klappen...


    Wie bist Du vorgegangen? Hast Du das Bootmedium auf der Maschine selbst erstellt oder am gepachten Macbook (ist wichtig zu wissen weil der Patcher ja spezifisch für das jeweilige Zielmodell arbeitet)? Hast Du sichergestellt das Du in jeder Phase vom Stick aus startest solange bis die Installation komplett durch ist (Auf dem Desktop angekommen)?

    Naja die OCLP Leute sind an der Stelle dann doch mal ein wenig über ihren Schatten gesprungen und haben den Patcher so angepasst das er auch die nicht nativen Karten erkennt und den Patch anbietet wohl halt schon mit blick auf die eigentlich nicht gemochte/unterstützte Hackintosh Community ;) In einem hast Du aber recht es wird halt durch das mehr an Abhängigkeiten nicht unbedingt einfacher...

    Die nicht nativen (DW1550, DW1560) gehen inzwischen auch da ist auch nicht viel Magie dabei...

    Am langen Ende ist es eine Frage der richtigen Reihenfolge der Extensions denn das eine bedingt mitunter das andere und umgekehrt...


    Zweifelsfrei muss die IOSkywalkFamily.kext als erste geladen werden die ist die Basis für alles weitere als nächstes dann AirportBrcmFixup.kext (nur die nicht den Injector der wird nicht benötigt) und zu guter Letzt die IO80211LegacyFamily.kext und Ihr Plugin. Damit sollte seitens der Extensions alles erledigt sein und von der Reihenfolge her sollte es passen. Im nächsten Step muss dann ggf. einmalig das BootArg amfi=0x80 gesetzt werden zusätzlich schadet es auch nicht das Arg -amfipassbeta mit aufzunehmen. Das Arg amfi=0x80 aus der Erfahrung heraus das manchmal der amfipass.kext nicht gleich beim ersten mal greift und macOS somit die vom Patcher eingebrachten Files abweist....


    Wenn alles soweit parat ist kann sicherheitshalber der RootPatch mit der neuesten Version des Patchers nochmal ausgeführt werden und sofern WLAN dann tut was es soll kann das amfi=0x80 Arg wieder entfernt werden. In der folge kann nach einem Update einfach der Patch wieder angewendet werden und es sollte dann einfach laufen.


    Native Lösungen für M.2 oder PCIe gibt es unter Sonoma nicht mehr hier muss im Falle von Broadcom IMMER mit dem Patcher gearbeitet werden im Falle von Intel halt mit den dazu gehörenden Kexten. Es gibt aber dennoch Lösungen die zumindest bis Sonoma ohne irgendwelche zusätzlichen Extensions (AirportBrcmFixup und BrcmPatchRAM3) auskommen hier wären zum Beispiel die Fenvi Karten zu nennen...

    Die Frage wäre auch warum die ID am Hack nicht erkannt/gewollt wird wie sieht denn das Fehlerbild aus?

    Klassischerweise würde ich ja drauf tippen das der Hack kein Netzwerkgerät hat welches die Eigenschaft EN0 und BulldIN hat (war früher immer, wirklich immer, der Grund warum der Store nicht wollte)...

    Du kannst die EFI Partition schon vergrößern macht aber meiner Meinung nach wenig bis keinen Sinn...


    Was die Logs angeht schau mal in der config.plist unter dem Punkt Misc->Debug hier musst Du bei Target den Wert 3 einstellen (Onscreen Log eingestellt wird vermutlich 67 sein) bzw. wenn Dein OpenCore so läuft wie erwartet kannst Du auch 0 (deaktivieren) einstellen denn was funktioniert muss ja nicht (mehr) debugged werden :)

    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?