Beiträge von griven

cobanramo denke weil es gezielt um die LTSC Version von Win11 on Arm geht und die gibt es soweit ich weiß nicht so ohne weiteres direkt bei Microsoft bzw. muss man sich registrieren um das LTSC ISO von Microsoft zu laden (https://info.microsoft.com/ww-…&culture=en-us&country=us) was möglicherweise nicht jeder möchte

Ist in dem Fall richtig schrup21

Der TE sagt bzw. schreibt ja das er weder den Bios Splash noch den OC BootPicker zu sehen bekommt wenn der dritte Screen via HDMI/DVI angeschlossen ist hier liegt also der Schluss nahe das das Problem auf der BIOS/UEFI Ebene liegt. Ich tippe auf die HDMI zu DVI Geschichte als Verursacher und würde vorschlagen zumindest testweise mal ein Gerät als dritten Screen anzuschließen das ohne Adapter auskommt also direkt HDMI unterstützt.

In der Theorie sollte das Board und die CPU 3 Displays unterstützen in der Praxis hängt das unter anderem auch davon ab wie die Bildschirme angebunden sind. Wie hast Du die Monitore angebunden (einmal HDMI nehme ich spannend sind die anderen beiden)?

Weil es offensichtlich leider nie an Aktualität verliert sei Diesem Thema ein Push gegönnt auf das es in künftigen Diskussionen beherzigt wird...

Ein bisschen was aus der guten, alten Zeit

Man muss hier denke ich differenzieren bzw. wirklich beachten auf welche Weise man den Assistenten verwendet. TM Backups scheinen der bessere/goldene Weg zu sein die anderen Möglichkeiten und hier insbesondere der Weg von einem "anderen Startvolume" schlägt sehr oft schon direkt in der ersten Phase der Migration fehl (läuft sich tot beim Vorbereiten der Migration) oder, sofern die erste Phase doch sauber durchläuft, landet der Assistent gerne in einem Bootloop. Die Probleme bei anderen Quellen als einem TM Backup gibt es mit dem Assistenten schon länger mal mehr mal weniger ausgeprägt.

Ersatz für meine (Ich habe schlechte Laune, weil ...) vor dem Schwimmbad geklauten Sachen...

Der Migrationsassistent ist offenbar kaputt Arkturus hatte am Elitebook das gleiche Problem und es zunächst auf die mit dem OCLP veränderte Installation geschoben (das Ziel war noch ohne Patch) allerdings war das nicht der Grund denn auch eine Migration von einem "sauberen" macOS 15.1 auf 15.2 Beta 3 funktioniert nicht und endet zuverlässig im Bootloop beim letzten Step der Migration. Fazit: Finger weg vom dem Assistenten :p

Naja der Assistent war eh schon immer eher auf wackligen Beinen unterwegs keine Ahnung was da die beste Strategie ist vielfach wird ja der Weg über ein TimeMachine Backup empfohlen und von dem Weg über ein StartVolume (hatte ich gemacht) abgeraten...

Mit der Beta3 waren die Probleme dann verschwunden nehme ich an

Wenn man von Fanprojekten spricht darf man meiner Meinung nach auch das großartige Zak Mc Kraken - Between Time and Space nicht vergessen (gibt es hier: http://www.mckracken.net/)

Naja hast Du nicht irgendwo noch eine einfache USB Maus (mit Kabel) rumfliegen die Du bis dahin benutzen kannst? Einfache, kabelgebundene USB Geräte haben zumindest bei mir am Laptop mit der Beta2 funktioniert wohingegen alles was dafür gesorgt hätte das die Interne Tastatur sowie das Trackpad funktioniert hätten zuverlässig dazu geführt hat das die Laube einfriert bzw. neu startet.

Wie schon geschrieben die Beta 3 ist raus und räumt einen Haufen Probleme aus die in der Beta 2 gerade mit sogenannten HID (Human Input Devices) Geräten bestanden haben. Mich würde es gar nicht wundern wenn Dein Problem mit dem Receiver eben genau daran liegt und sich in/mit der Beta 2 schlicht nicht lösen lässt...

Zudem ist inzwischen die Beta3 raus und die hat einige Probleme beseitigt die es mit der Beta2 gab...

Bevor Du jetzt anfängst Deine laufende config auseinander zu pflücken würde ich empfehlen die Beta3 zu testen denn zumindest an der Laptopfront haben sich damit alle Probleme die die Beta 2 verursacht hat in Wohlgefallen aufgelöst

Leider kann ich diesmal nicht dabei sein allen Beteiligten wünsche ich aber einen gelungenen Stammtisch

Kann ich bestätigen die Beta3 ist locker aufs Elitebook geflutscht und alles ist (wieder) schick

Das sieht doch aber so aus als würde BT genau das tun was es tun soll...

Die Airpods sind da wo ist denn dann noch das Problem?

Kabel wird dran sein der BCMHub wird ja im Hackintool am USB gelistet demnach daran wird es nicht liegen...

Meiner Erfahrung nach bocken die Dinger nur wenn die entweder wirklich nen Hau weg haben (daher die Frage nach anderem OS) oder in der config noch irgendwas aktiv ist das sich an dem BT Gedöns zu schaffen macht (BRCMPatchRam und bei nativ unterstütuten BT Lösungen ggf. BlueToolFixup wobei das eigentlich unkritisch ist). Ich selbst habe einen Fenvi im Elitebook laufen und der BT Teil der Karte läuft unter Sequoia ohne das dazu irgendwelche Eingriffe nötig wären (Plug and Play). Allerdings habe ich für das Elitebook auch zwei Anläufe gebraucht bis ich eine Karte hatte die vollständig funktioniert. Die erste hat zwar funktioniert aber im USB/BT Teil einen Fehler gehabt der dazu geführt hat das der Rechner unregelmäßig komplett eingefroren ist (ließ sich zuverlässig verhindern indem an einen USB Stick angeschlossen hat) ich vermute das die Karte irgendwelche Störungen am USB Bus verursacht hat die zu den freezes geführt haben und die der gesteckt USB Stick "absorbiert" hat...

Der BT Teil bei der Fenvi benötigt keine Modifikationen am NVRAM und auch keine FixUPs (BRCMPatchram und Co.). Alles was es braucht ist ein funktionierender und korrekt konfigurierter USB Port denn das BT auf der Fenvi wird von macOS (inkl. Sequoia) nativ unterstützt...

Wichtig ist auch das nicht mehrere BT Lösungen parallel betrieben werden denn das kann dazu führen das macOS der nicht unterstützten Lösung den Vorrang gibt und somit BT nicht zur Verfügung steht. Aber mal eine andere Frage funktioniert das BT auf der Fenvi unter anderen Betriebssystemen (Windows, Linux)? Ich frage das deshalb explizit nach weil ich schon mehrfach Fenvi Karten hatte bei denen der BT Teil defekt war. Je nachdem wo bzw. von welchem Händler man die Karten bezieht scheint die Qualität der Karten stark zu schwanken...

Im Grundsatz hast Du schon recht der Patcher ist in erster Linie für alte original Apple Hardware gemacht allerdings ist das Tool unter Umständen auch für uns nützlich wobei es hier ganz auf die im Hackintosh vorhandene Hardware ankommt. Der Patcher ist nützlich für Leute die

1. Ein System verwenden das mit einer eher betagten Grafikkarte ausgestattet ist (iGPU kleiner Intel (u)HD6XX, AMD kleiner Polaris, NVIDIA bis Pascal)
2. Eine WLAN Lösung von Broadcom verwenden (Fenvi oder vergleichbar) und macOS Sonoma oder Sequoia nutzen möchten
3. Unter Sequoia eine Intel WLAN/BT Lösung verwenden wollen sich aber nicht mit ITLWM und Heliport anfreunden wollen oder können

In Deinem Fall wäre also der Patcher ggf. allenfalls dann interessant wenn Du planen solltest auf Sequoia zu wechseln und eben nicht ITLWM und Heliport nutzen möchtest sondern AirportITLWM. In dem speziellen Fall wird der Patcher dann verwendet um die WLAN Komponenten auf die Versionen von Ventura bzw. Sonoma downzugraden was dann dem AirportITLWM erlaubt zu funktionieren.

Vermutlich zwar nicht Auslöser des Problems aber generell entweder AMFIPass.kext oder amfi=0x80 BootArg niemals beides zur gleichen Zeit...

Zusätzlich frage ich mich warum Du überhaupt AMFIPass/BootArg nutzt denn wenn ich es richtig sehe benötigst Du doch den OCLP nicht und nimmst damit auch keine Veränderungen am RootVolume vor die das aushebeln von AMFI notwendig machen würden?!? Demnach wenn man etwas gar nicht benötigt sollte man es auch nicht in der config haben daher bitte beides einfach entfernen (Kext und BootArg). Zudem würde ich an Deiner Stelle testweise mal alles aus dem Rennen nehmen was nicht unbedingt benötigt wird hier insbesondere alle Sensoren und ggf. auch das Intel WLAN/BT Gedöns wenn die Möhre dann durchmarschiert kann man Dinge stück für stück wieder aktivieren bis man herausgefunden hat was für die BootLoops verantwortlich ist.

Generell scheint 15.2 sich zu einem Problembären zu entwickeln da hakt es offenbar an diversen Stellen ganz gewaltig...