Beiträge von griven

    EnderWalt das ja witzig :)


    Ich schreibe hier aktuell gerade mit einem Elitebook 840 G5 das aktuell mit Tahoe werkelt und ich denke meines ist bis auf ein paar Details (I7 anstelle von I5 und Broadcom WLAN anstelle von Intel) dem Deinen sehr ähnlich. Ich habe Dir mal meinen EFI Ordner angehangen zum testen und als Inspiration. Anpassungen an das Intel WLAN/BLuetooth musst Du selber vornehmen da habe ich keine Aktien drin allein schon deshalb nicht weil mir Airdrop und Co. wichtig sind was ja mit Intel WLAN nicht funzt. Berichte gerne mal ob Du so weiter kommst...

    Dateien

    • efi.zip

      (15,15 MB, 79 Mal heruntergeladen, zuletzt: )

    Warte mal auf 2026, da wird es interessant werden mit dem Snapdragon X2, dann noch Nvidia mit ihrem CPU für den Desktop Bereich.
    Da kommt noch was in dem nächsten Jahr.

    Das mag sein aber dazu müsste sich auch Microsoft bewegen und Win on Arm mal ein wenig mehr als nur halbherzig voran bringen woran sie aber zumindest bisher kein gesteigertes Interesse haben (passt ja auch irgendwie nicht in die Strategie den ganzen Ramsch als Service anzubieten). Am langen Ende nutzt der leistungsfähigste Chip rein gar nichts wenn das OS, das darauf laufen soll, keinen Gebrauch davon macht.


    Einer der größten Vorteile von Apples M und A-Serie SoC's liegt ja gerade darin das hier Hard und Software optimal zusammenwirken. In der Summe ist ein ARM SoC mehr als ein einfacher Prozessor zudem erlaubt die ARM Architektur eine Menge Freiheiten bei der konkreten Ausgestaltung des Chip Designs was auf der einen Seite gut ist, weil sich SoC's in der Weise optimal an unterschiedlichste Einsatzzwecke anpassen lassen (Mobil, Desktop/Workstation, KI Beschleunigt, Grafik usw.), auf der anderen Seite aber auch ein Nachteil darstellt eben weil sich das volle Potential nur mit speziell dafür entwickelter Software (OS) ausschöpfen lässt. Was bei Apple funktioniert weil beides aus einer Hand kommt muss nicht zwangsläufig auch auf dem freien Markt funktionieren bzw. wird nur dann funktionieren wenn sich die unterschiedlichen Hersteller auf einheitliche Standards einigen die dann idealerweise in einheitliche Frameworks, API's und Co. überführt werden können. Genau an der Stelle sehe ich aber die entscheidende Schwachstelle in dem gesamten Konstrukt denn gemeinsame Standards bedeuten eben auch Einschränkungen im Design die keiner der großen Player in Kauf nehmen wollen wird (schon gar nicht mit Blick auf den sehr lukrativen KI/ML Bereich)...

    Was eingermaßen logisch ist einfach weil sich iOS iCloud Backups auch nur auf die Version (oder eine neuere Version) wiederherstellen lassen mit der sie erzeugt wurden nicht jedoch auf ältere Versionen. Sofern Du nicht noch ein älteres Backup hast würde ich an Deiner Stelle wieder auf iOS 26.2 gehen und warten bis Nugget es auch unterstützt denn letztlich wird 26.2 in den nächsten Tagen (möglicherweise schon heute) released...

    Ich denke ebenfalls das wird ein Fork oder eine frühe Entwickler Version des offiziellen Patrchers sein bei dem, im Vergleich zum Dortania Repo, die Einschränkung bzgl. des Host OS gelöst worden ist. Das Github Repo aus dem diese Version stammt gehört zu lzhoang2801 (https://github.com/lzhoang2801/OpenCore-Legacy-Patcher), dem Autor von OCSimplify, und stellt einen Fork von crystall1nedev Tahoe Patchset Branch dar. Am langen Ende also alles andere als komplett oder fertig dennoch mit Blick auf die Hackintosh Community aber eben genau das was die meisten Hackintosh User wollen nämlich der Modern WIFI Patch in funktionierender Version.


    Streiten kann und muss man darüber ob es sinnvoll bzw. ob es der Patch einem wert ist AMFI komplett einzureißen denn exakt das ist eigentlich gar keine gute Idee. Wie immer gilt: mit solchen Dingen sollte nur "spielen" wer sich auskennt und sich der möglichen Risiken bewusst ist alle anderen sollten besser warten bis es was offizielles gibt. Wenn ich persönlich mir was wünschen dürfte dann wäre das eine Lösung die mehr auf die Bedürfnisse der Hackintosh Community zugeschnitten ist denn ich denke schon das 99% von uns mit etwas zufrieden wären das sich ausschließlich um Wifi und AppleHDA dreht und den Rest außen vor lässt...

    Das der Rechner nach dem Patch nicht (mehr) hochkommt liegt an AMFI bzw. am AMFIPass.kext schrup21 setzt man das BootArg amfi=0x80 dann bootet der Rechner wieder und WLAN funktioniert fein (hier am Elitebook getestet). Ich denke AMFIPass wird noch Anpassungen für das neue Patchset benötigen...

    Naja vermutlich war eine der Beiden EFI Partitionen korrupt und Du hast ausgerechnet diese erwischt ?!?


    Der Injector ist ein Plugin innerhalb von AirtPortBrcmFixup und somit sieht man den manchmal nicht auf den ersten Blick. Der Injector ist unter Umständen eher schädlich als nützlich (falsch verwendet) und wird daher gerne mal entfernt. Vielleicht hast Du exakt das irgendwann mal gemacht und schlicht vergessen. ?!?

    Naja booten ist nicht das Problem das hat ja durchaus funktioniert eben halt nur ohne USB Support was daran liegt das die von OCLP erzeugte USBMap eben noch nicht an die Tahoe spezifischen Spitzfindigkeiten bzgl. USB Port Nummerierung angepasst war. Mit den von mir in Post #15 vorgenommenen Modifikationen sollte aber auch das nun funktionieren und er somit zumindest ins System kommen. Sofern OCLP 3.0 dann irgendwann erscheint kann er die Rootpatches demnach dann auch nachziehen.

    Hum ob sich das am Ende lohnt ist schwer zu sagen und musst Du selbst entscheiden. Wenn Du den Rechner akut nicht brauchst kannst Du natürlich warten die Frage ist halt nur wie lange...

    Leider ist aktuell nichts darüber bekannt wann oder ob überhaupt eine OCLP Version verfügbar sein wird die mit Tahoe umgehen kann (es hieß mal nicht vor dem Winter). Alternativ kannst Du aber den iMac ja auch mit einem zweiten APFS Volume ausstatten und parallel zum nun vorhandenen Tahoe nochmal Sequoia installieren einfach damit Du den Rechner nutzen kannst und er nicht nur als Staubfänger da steht :)

    Hier mal mit einem an die Gegebenheiten von Tahoe angepassten USB Mapping damit sollte dann zumindest USB wieder gehen. Erwarte aber bitte nicht das Du mit dem Rechner dann ernsthaft arbeiten kannst denn für alles was abseits von USB auch nicht geht (WLAN, Grafikbeschleunigung usw.) gibt es einfach (noch) keine Lösungen. Die Kiste ist mit Tahoe leider mehr oder weniger nutzlos 🤷‍♂️ Immerhin Du kommst im Idealfall wieder rein und kannst zumindest Deine Daten wegsichern. Anschließend wäre es dann angesagt ggf. auf Sequoia zurück zu gehen (in dem Fall leider als neu Installation weil Downgraden lässt sich macOS ja nicht)...

    Dateien

    • OCLP.zip

      (13,65 MB, 55 Mal heruntergeladen, zuletzt: )

    Naja macht in dem Fall eigentlich keinen Unterschied denn der Rechner startet ja offensichtlich sowohl von der USB EFI als auch von der auf der Platte sich befindlichen. Wichtig an der Stelle wäre jetzt wirklich zu wissen auf welche macOS Version da versehentlich geupdated wurde denn wenn das möglicherweise doch Tahoe ist dann ist klar wo der Hase im Pfeffer liegt und warum wir das auch mit der vom OCLP erstellten EFI nicht gelöst bekommen (Thema USB Portmap und die Tahoe Besonderheiten)...


    Also Deppintosh Butter bei die Fische auf was hast Du geupdated ?!?

    Ich hab das mal fix gemacht scheint als wäre ST3R30 offline...


    Wie schon erwähnt Beide Verzeichnisse aus dem Archiv auf einen Fat32 formatierten USB Stick packen (direkt in dessen Root Verzeichnis) und den Mac damit booten. Ich drücke die Daumen das es so klappt. Wenn es nicht klappen sollte könntest Du auch mal versuchen einen USB Hub zwischen Mac und Maus und Tastatur zu packen zwar sollte der iMac davon eigentlich nicht betroffen sein aber man weiß ja nie...


    EDIT: Anhang gelöscht, aktualisierte Version siehe in Post #15

    Warum sollte man mit MIST eine ISO vom Installer erstellen wollen wo das Tool doch eine komfortable Möglichkeit darstellt direkt ein Installationsmedium aus der heruntergeladenen APP auf einen geeigneten USB Stick zu erstellen? Franziska1993 ich verstehe nicht so ganz was Du mit einem ISO vom Installer willst?

    Es gibt speziell für diesen Laptop ein Github Repo mit einer "fertigen" EFI im Netz (https://github.com/Baio1977/HP-250-G6-Kabylake/releases) die zumindest auf den ersten Blick so aussieht als hätte sie Hand und Fuß. Ich bin zwar generell ein Fan von selber machen allein schon weil es dazu beiträgt Dinge zu verstehen aber auf der anderen Seite muss man das Rad auch nicht immer wieder neu erfinden von daher teste es doch mal mit der "fertigen" und wenn es damit geht dann vergleich diese mit Deiner und guck wo die Unterschiede liegen....


    Von Deinem Screenshot ausgehend passiert die Panik relativ früh im Startprozess kann also gut und gerne ACPI bezogen sein (ein Kandidat ist hier gerne mal AWAC vs. RTC) hier wäre dann zu analysieren woran das liegt aber wie gesagt teste mal was schon gemacht wurde ist möglicherweise zielführender als jetzt lang in die Fehlersuche zu gehen :)

    Übergroße Extensions wie wie zum Beispiel den "IntelBluetoothFirmware", "AirportItlwm" usw kannst Du getrost aus dem EFI Ordner entfernen (nur die Dateien nicht den Eintrag in der config.plist) ebenso kannst Du einen evtl. vorhandenen Apple Ordner löschen vor dem hochladen :)


    Unabhängig davon möchte ich Dich bitten Dir einen anderen Avatar zuzulegen denn Frau Merkel brauchen wir hier nun wahrlich nicht auch nicht als Avatar (vgl. §6.2 der Forenreglen) ich Danke Dir.

    Wüsste jetzt nicht warum das nicht gehen sollte denn letztlich tunnelt der VPN ja "nur" die Verbindung in den internen Adressspace was ja erstmal keinen Einfluss auf die Art der übermittelten Pakete hat (magic packet). Ich kann mir aber auch vorstellen das WOL nicht auf der Prioritätenliste von Basti Wolf steht eben weil er ja das NAS esplizit als (i)Cloud Ersatz betreiben möchte und ihm ein nahtloser Sync zwischen den Geräten wichtig ist für den Zweck wäre es ja eher hinderlich wenn die "Cloud" für jeden Sync erstmal wieder aufwachen müsste...

    Basti Wolf ich nutze Wireguard auf dem iPhone um auf meine HomeAssistant Instanz zugreifen zu können und kann keinen Unterschied bei der Akkulaufzeit feststellen. Der VPN beschränkt sich in meinem Fall auf Zugriffe auf die 192.168.178er IP Range der restliche Traffic geht weiterhin ganz normal über den Provider (Vodafone in meinem Fall)...