Beiträge von griven

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

Vermutlich hat er einfach entweder unbedacht ein Windows Update installiert was gelegentlich zur Folge haben kann das Windows die EFI überschreibt oder aber er halt einen NVRAM Reset gemacht was ebenfalls gelegentlich zur Folge haben kann das der UEFI Booteintrag für OC flöten geht....

Egal wie es dazu gekommen ist wenn Windows startet kannst Du mit Tools wie BootIce, EasyBCD oder EasyUEFI ziemlich einfach wieder einen UEFI Booteintrag für OC erstellen

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...

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...

Weil nach einiger Fummelei (typischer Fall von kaum macht man es richtig geht's auch) nun auch ein Open Thread Border Router mein Smarthome Gedöns bereichert

Das Ganze läuft parallel zu einem Matter Server und Homeassistant Core in Docker und nutzt ein Sonoff Dongle E als Funkmodul. Schöne, neue Welt und so

Vorsicht! Die Kompatibilität von WLAN Karten mit macOS ist ziemlich fragil das läuft längst nicht alles so wie gedacht gerade im Bezug auf die Apple Services (Airdrop und Co.). Die von mit verlinkte Karte läuft aber auch mit Windows ohne jegliche Probleme die passenden Treiber gibt es auf der FENVI Webseite (habe die Kiste im Dualboot mit Win11 laufen). Was Deine Frage bzgl. der Grafik angeht läuft Deine Kiste aktuell sehr wahrscheinlich ohne jede Grafikbeschleunigung (erkennt man unter anderm auch daran das das Dock und die Menuleiste nicht transparent sind bzw. auch unter  -> Über diesen Mac -> Weitere Infos -> Systembericht -> Grafik/Displays) also ja da passt was mit Deiner Konfiguration bzgl. der Grafik nicht. Ich habe mich. mal ein wenig durchs Netz gewühlt und die folgenden DevieProperties scheinen bzgl. des 840 G5 Konsens im Netz zu sein:

Ersetze testweise einfach mal den gesamten Key in Deiner config.plist und teste es damit (Falls Du nicht weißt wie lade Deine config.plist einfach hoch das erledige ich das schnell für Dich).

Bzgl. Dualboot ist Deine Strategie soweit schon ganz richtig wobei OC nicht auf eine eigens erstellte Partition gehört sondern auf die zum GUID Partitionsschema gehörende ESP (EFI System Partition). Ich bin dabei wie folgt vorgegangen:

1. SSD mit dem Festplattendienstprogramm des macOS Installers als APFS/GUID partitioniert.
2. Im Festplattendienstprogramm unter Partitionen die nun vorhandene APFS Partition so verkleinert das ausreichend Platz für Windows verfügbar ist
3. Windows Installation gestartet und als Ziel den freien Platz auf der SSD ausgewählt
4. Windows Installation abschließen
5. macOS Installation starten und macOS in den in Punkt 1 erstellten APFS Container installieren
6. Installation abschließen (Beim boot vom USB Stick sollte OC nun Windows und macOS als Optionen anbieten)
7. EFI vom Stick auf die Platte bringen hierzu folgenden beachten:
   - ESP mounten z.B. mit OCAT
   - vom USB Stick die Ordner Boot und OC in den schon vorhandenen EFI Ordner auf der ESP kopieren den schon vorhandenen Microsoft Ordner bei in Ruhe lassen
   - Rechner nun von der SSD Neustarten und OC sollte beide Systeme zum starten anbieten

Also alles kein Hexenwerk

Joa mit der geht Airdrop und auch alle anderen Apple Features ohne jegliche Probleme

Ab Sonoma braucht es OCLP um WLAN zum laufen zu bringen aber das ist ja ein Manko das auf alle anferen WLAN Lösungen am Hackintosh auch zutrifft.

An Deiner Stelle würde ich die EFI aus dem von mir verlinkten Thread nehmen und aus der dieser Device Properties für die Grafik stibitzen (immerhin ist für die ja bekannt das sie funktioniert) zudem stell aber bitte auch sicher das im Bios unter Advanced -> Built-In Device Options der Wert für Video Memory auf 128MB oder höher eingesellt und, sofern bei Dir vorhanden, das Mobile Network Device deaktiviert ist.

Oha Schande über mich *duck*...

Meine EFI wird Dir möglicherweise doch nicht so richtig viel bringen denn ich habe hier in der Tat ein G6 und gar kein G5 sehe ich gerade. Das G5 und G6 unterscheiden sich zwar nur marginal aber dafür an entscheidenden Stellen (HD620 vs. uHD620 usw.) dennoch wir haben hier schonmal an einem G5 gewerkelt und waren dabei sogar erfolgreich schau mal hier: Hilfe bei HP EliteBook 840 G5 da sollte es eine passende EFI zu Deinem Gerät geben die Du als Basis hernehmen kannst.

Ich habe jetzt keine besonderen Einstellungen im Bios vorgenommen steht also demnach mehr oder weniger auf den default Einstellungen (Secure Boot ist aus). Hast Du denn mal versucht mit dem EFI Ordner zu starten den ich Dir in Post 3 angehangen hatte denn damit läuft mein Elitebook ja absolut ohne jedes Problem ?!?

Auf meiner Seite auch von einigem Erfolg gekrönt da ich endlich mal die Zeit gefunden habe an meinem Elitebook mir die Framebufferpatches nochmal genauer anzusehen und nun endlich sowohl der USB-C (ging immer) als auch der HDMI out (ging nie) funktionieren

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...

Zitat von Bob-Schmu

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 ich bin dabei, wer noch ?!

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...

Keep in mind that AppleVt-d has to be disabled and probably also dart=0 has to added as well to make it work (see here: https://forums.macrumors.com/t…ion.2458481/post-34312593)

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.