Beiträge von hackintoshler1337

    Also, im OCAT hat er mir klar aufgezeigt, dass deine Kexte und Treiber alt waren.

    Hmpf. Irritiert mich tatsächlich :-D Das Repo ist schon der Ort, von dem man sowas herbekommt, oder? Vielleicht zwischendrin in den paar Tagen noch paar Updates rausgekommen? Keine Ahnung.


    Wenn das aber dann damit auch nicht läuft müsste ich jetzt konkret vor dem Rechner sitzen. Ich würde jetzt alle Bios Einstellungen durchgehen wollen, dann den Bootstick neu erstellen und danach mal versuchen


    Ich glaube das mach ich mal, also den gesamten Guide nochmal, auf einem anderen USB-Stick. Am besten komplett andere Voraussetzungen, also ich stell den EFI nicht hier am Rechner zusammen, sondern auf einem anderen Laptop, damit das als (eeeech unwahrscheinliche) Fehlerquelle ausgeschlossen ist.


    Eigentlich sehe ich dafür keinen Grund.

    Ja, ich finde das auch irritierend. Also dass das mal so überhaupt nicht mitspielt, das System.


    Sage mal, ist VT-D aktiviert? Er meckert nämlich über Apple VTD. Dazu miss zwingen VT-D aktiv sein.

    VT-d ist seit Post #10 aktiv, und DisableIOMapper aus.

    Das Framebuffer Thema ist bei Dir komplett egal weil Du die iGPU im Bios deaktivert hast und mit der RX580 fährst (zudem hat Dein gewähltes SMBIOS keine iGPU demnach auch kein Headless Betrieb der selben) ergo an dem Bereich bitte gar nichts machen und auch keine Properties mitgeben damit schleppt man sich nur unnötige Fehlerquellen ein...

    Good to know, alles klar. Ja dann...

    Ah okay das MT Modell mag wieder anders sein...

    Anyway würde ich den Kext zumindest testweise mal deaktivieren nur um sicherzugehen das der an der Stelle keine Probleme macht schaden kann es nicht :)

    Ich hab in der config.plist beim Realtek-Kext "Enabled" auf false gestellt und rebootet.


    Leider gleiches Fehlerbild... Aber einen Versuch war's auf jeden Fall wert.



    Edit: Ich seh in einem Reddit-Thread, dass da jemand das Problem hat lösen können mit Framebuffer-Zeugs... Eigentlich hab ich das ja bei mir in der Config auch so gesetzt wie im Thread gesagt, aber vielleicht hat das dann ja mal was mit der Grafik zu tun. Ich nehm das mal als Hinweis mit.


    Edit2:

    Da steht auch dabei:

    Code
    1. Headless framebuffers(where the dGPU is the display out) do not need framebuffer-patch-enable, framebuffer-stolenmem and framebuffer-fbmem

    Deshalb hab ich neben dem AAPL,ig-platform-id und der gefakten device-id (die ich glaube ich nichtmal brauche, aber geändert hat's auch nix) die ganzen framebuffer-{fbmem,stolenmem,patch-enable}-Sachen nicht in meiner config.plist.

    Was mir noch auffällt ist das laut Hersteller Seite (HP) das kleine Ding einen INTEL NIC hat (Intel i217LM-GbE) Du aber beharrlich den RealtekRTL8111.kext lädst schmeiß den bitte mal raus und ersetze den durch den IntelMausi.kext...

    Eigentlich sollte der RTL nix tun wenn kein Realtek Lan an Board ist aber man weiß ja nie...

    lspci auf Linux behauptet, ich hätte Realtek... Wahrscheinlich verschiedene Ausgaben des PCs? gewechselt hab ich nix.


    Code
    1. 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

    Ich hab mal eben meine Produktnr & Seriennr bei HP eingetragen, um da die genauen Komponenten zu sehen und euch da den Link oder ne PDF oder so schicken zu können, aber...



    Hier das gesamte lspci, falls es hilft:

    Unter den Kernel Quirks bitte auch AppleCPUPMCFGLock auf false stellen. Ist nur für IVY Systeme.

    Ah - ich kann dir sagen, warum ich das aktiv hatte, das steht so unter https://dortania.github.io/Ope…to-work-with-our-hardware. Hatten wir früher im Thread drüber geredet, dass das nur für Ivy-Systeme ist wusste ich nicht.


    die ganzen Kexte waren alt

    An dem EFI wurde zwischendrin immer mal wieder was geändert, ich hatte mir da am Anfang alles frisch vom Build-Repo https://dortania.github.io/builds/ runtergeladen - ich versuch so nebenbei mittels eines Git-Repos bisschen mitzukriegen, was ihr so alles an dem EFI ändert, um da up-to-date zu bleiben und keine falschen Aussagen zu treffen wenn ich über den EFI rede, den ich da unter meinen Post als aktuellsten anhänge, sorry, falls ich da etwas durcheinander komme :-D Wobei ich ehrlich gesagt nicht glaube, dass jemand von den Leuten hier mit Absicht irgendwelche Kexts älter macht... Also keine Ahnung, wie die da rein gekommen sein sollen. Wenn ich das diffe seh ich aber in deinem EFI auch gar keinen Unterschied in den Kexts zu meinem EFI in Post #24... nur, dass du da ein paar .efi-Dateien in Drivers ausgetauscht hast. Komisch.

    Mein Original-EFI zu dem ich restlos Stellung beziehen kann ist in Post #1, da hab ich den angehängt.


    Wozu nutzt Du den agdpmod? Hast Du Black Screen Trouble nach Boot?

    Den hat griven in Post #23 hinzugefügt, wahrscheinlich eher als Test, ob das was hilft. Das Ding bleibt bei mir nach der Fehlermeldung stehen, Black Screen bekomme ich keinen.


    Warum hast Du den ALC-ID einmal unter den Device Properties und dann noch unter den Bootargs?

    Das Bootarg wird im Guide unter https://dortania.github.io/Ope….plist/haswell.html#add-2 beschrieben - das unter Device Properties hab ich eigentlich gelöscht... Ich seh da auch nur noch dieses Framebuffer-Ding "PciRoot(0x0)/Pci(0x2,0x0)", also kann ich dir da nicht so zu 100% folgen, was du genau meinst...

    Der Key "Audio" unter UEFI ist dazu gekommen, als ich auf Anraten von Post #5 mit OCAT die Warnungen behoben hab.


    Ich hab ehrlich gesagt sowieso ein bisschen das Gefühl, dass grade für Anfänger wie mich so Tools wie OCAT, die vieles automatisch machen, eher nicht so super sind, weil ich dann einfach vieles was der ändert nicht so 100% nachvollziehen kann... vor allem frag ich mich dann, warum das da plötzlich drin ist, wo der Guide die Schlüssel doch gar nicht erwähnt hat. Aber da muss ich einfach noch ein Gefühl dafür bekommen glaube ich.


    Im besten Fall bin ich, nachdem wir hier die Fehler gefunden haben, in der Lage, meinen EFI aus Post #1 selbstständig so anzupassen, dass er funktioniert, und die ganzen Tipps die ihr mir über den Verlauf des Threads gegeben hat beinhaltet. Sonst steh ich da beim nächsten Problem wieder wie ein Ochs vorm Berg und weiß nicht, was da alles in meinem EFI drinsteht :-D


    So, ich habe mal deine EFI soweit upgedated

    Vielen Dank, die probier ich gleich mal aus :-)



    Übrigens, ich hab meine (wie von dir in Post #25 gesagt) SATA5 mal via BIOS "Device Security" virtuell abgesteckt (das ist bei mir das CD-Laufwerk) - das nimmt zwar die Warnung unten weg, weiter geht's trotzdem nicht. Ich hatte den Rechner für ca. ne Stunde in dem Zustand an gelassen, weiter geht's tatsächlich einfach gar nicht.




    Update: Ich hab mal dem von dir bereitgestellten EFI gebootet, leider trotzdem keine Änderung... Das ist wirklich 'n harter Knochen. 1:1 der gleiche Output wie im Bild in diesem Post.


    Was haltet ihr davon, wenn ich das Git-Repo mit all den Änderungen die bis jetzt gemacht wurden mal hochlade auf GitHub, damit ihr das auch so nachvollziehen könnt? Ich zieh da immer den aktuell genutzten EFI rein, änder die Intendation damit der das gescheit diffen kann (der erste EFI war mit Tabstops, alles was von euch kommt ist mit Leerzeichen) und mache einen Commit, damit lässt sich das über das GitHub-UI ganz gut vergleichen (z.B. Git Blame).

    Sieht doch ganz nach einem HDD Problem aus. HFSPlus.efi ist aktuell und installiert?

    HFSPlus ist das, was mit meinem OpenCore-0.9.5-DEBUG mitgekommen ist, und das liegt auch tatsächlich unter Drivers.


    Aber stimmt, AHCI weisst schon auf irgendwas festplattiges hin... Wobei ich ja noch nichtmal von einer Festplatte starte, sondern von einem USB-Stick... Gibt's da auch AHCI?


    Zitat


    und die nicht system spezifischen SSDT‘s rauswerfen

    Das versteh ich nicht ganz, sind nicht alle SSDTs im besten Fall systemspezifisch, weil direkt fürs gemeinte System kompiliert? Und wenn die systemspezifisch sind, ist das nicht gerade ein Grund, sie da rauszuschmeißen?


    Da sind vier Stück drin, EC-USBX, HPET, PLUG & SBUS-MCHC.


    Könntest du mir da bitte nochmal kurz weiterhelfen? :)

    Ich habe mit der von dir bereit gestellten config.plist gebootet, gleiches Ergebnis. Dieses DisableIOMapper hatte ich auch schonmal ausprobiert... Ja, das ist irgendwie alles nicht so wirklich stringent nachvollziehbar, warum sich mein Rechner jetzt plötzlich so dagegen stellt.


    Via

    Code: https://dortania.github.io/OpenCore-Install-Guide/installer-guide/linux-install.html#downloading-macos
    1. # Latest version
    2. # ie. Ventura (13)
    3. python3 ./macrecovery.py -b Mac-4B682C642B45593E -m 00000000000000000 download


    habe ich entweder Ventura oder die letzte Version Sonoma (was genau weiß ich auch nicht ganz... widerspricht sich ja) heruntergeladen, und auf den Stick gepackt. Jetzt ist die Fehlermeldung beim booten eine andere:



    Bei der bleibt es auch, also ich hab da wieder gute zehn Minuten gewartet und an dem Bild hat sich nichts geändert.

    Willst Du denn jetzt Monterey neu installieren oder einen bereits bestehende Monterey Installation mit OC starten

    Ich möchte Monterey neu installieren, ich habe keinerlei derzeit installierten macOS-e.


    hast Du vorher schon mal Monterey bis zu einem gewissen Punkt installiert (zum Beispiel mit Clover) und schwirren davon vielleicht noch Reste im System (NVRAM) rum?

    Ich hatte vor einer ganzen Weile wie gesagt Mojave & Catalina, davor mit Clover und später mit OC, aber den NVRAM hab ich schon geleert, das hat nichts geholfen.


    Dann bzgl. der Grafik wie hast Du die angeschlossen

    Ein Bildschirm hängt via DisplayPort, und ein anderer via DVI an der dGPU. Die iGPU ist derzeit deaktiviert, aber auch mit aktivierter iGPU startet der Installer nicht.


    Was auch nicht unwichtig ist aber gerne vergessen wird ist das die Serial Ports im Bios deaktiviert werden müssen die machen mit macOS nämlich auch relativ oft Probleme der diffusen Art...

    Danke für den Tipp! Ich habe im BIOS unter "Onboard Devices" tatsächlich den Serial Port auf "Disabled" setzen können - das hat aber leider auch keine Änderung erbracht. Gleiches Verhalten mit 1:1 gleichem Fehlerbild.

    ok, mitunter kommen da neue optionen zu, aber bedenke,-du hast quasi ein oem-board, das ist somit oft eine sache für sich. die biosinterna sind da meist nicht so zugänglich oder tauchen erst garnicht auf. selbst ein externes -modifizieren "kann" möglich sein -muß-aber nicht. ich wünsche dir weiterhin viel erfolg :)


    lg :)

    Neues ist da leider auch nicht dazu gekommen, zumindest nichts, das mir aufgefallen ist...


    Verstehe, dann bin ich damit so ein bisschen ein Sonderfall unter den Sonderfällen.. :-D


    Danke für deine Hilfe :-)

    Auf was steht in deiner EFI SetupVirtualMap?


    Und ja das Tool ist soweit gut, geht oder geht nicht…

    Booter.Quirks.SetupVirtualMap steht auf true.


    Soll ich das Tool dann einfach mal auf gut Glück ausprobieren? Oder hilft uns das mit dem Problem wahrscheinlich eher nicht weiter, weil die Quirks das System auch schon booten lassen sollten, und ist eher was für danach?


    Danke für deine Hilfe.

    Vielen Dank!


    VT-D habe ich jetzt angeschaltet und DisableIOMapper auf false gesetzt. Nach erneutem Ausprobieren hilft das dem System leider trotzdem nicht über den Error... Der bleibt da immer noch einfach stehen, nach den o.g. Fehlern.


    Mein HP-Bios-Setup ist ziiiemlich rudimentär, "Above 4G Decoding" gibt es bei mir leider nicht... Da gibt's auch keinen "Advanced" mode oder sowas, zumindest nicht, dass ich in den Jahren die ich den PC schon hab da was gefunden hätte...


    "MSR-Lock" oder "CFG-Lock" finde ich da auch nicht, leider.


    Ich hab mir also den Link angeschaut. Da wird von zwei Quirks geredet: AppleCpuPmCfgLock und AppleXcpmCfgLock. Letzteren hatte ich glaube ich schon am Anfang angeschaltet, ersteren hat glaube ich griven in Post #8 aktiviert. Jedenfalls sind in dem EFI den ich aktuell auf den Stick hab beide an. Damit ist das, was im Link zu der Methode mit den Quirks gesagt wird ja schon gemacht, oder? Oder überlese ich da was? Der Rest ist ja zu dieser Patchen-Methode, von der du ja nicht gesprochen hast, oder?



    Ansonsten: Grundsätzlich ist Patchen ja anscheinend die schönere Lösung - Ich hab noch Logs übrig von als ich die Debug-Version von OpenCore verwendet habe, da steht

    Code
    1. 00:343 00:019 OCCPU: EIST CFG Lock 1

    drin. Theoretisch wäre ich also mit "Disabling CFG Lock" im Guide fortgefahren, leider klappt dieses UefiTool nicht für HP-BIOSe.


    Was ich gefunden hab ist von Brumbaer das Tool CFGLock.efi (CFG Lock) - da haben anscheinend ne Menge Leute Erfolg damit gehabt. Wenn das einen Vorteil gegenüber den beiden Quirks verschafft, könnte ich das theoretisch auch ausprobieren, in der Hoffnung, dass das Tool weiß, was es tut... :-D

    Korrekt Haswell kann AVX2 von daher steht Ventura und Sonoma erstmal nichts im Weg :)

    iMacPro Smbios ist in dem Fall auch kein Problem bzw. bei der Plattform sogar eine gute Wahl (wegen der RX580). Probier mal hiermit: EFI.zip

    Vielen Dank erstmal! Das klingt sehr gut.


    Ich hab die EFI ausgetauscht (aber das Monterey-Bootimage da mal belassen, obwohl Sonoma gehen müssten - die ganzen Einstellungen wie SMBIOS & Co sind ja für Monterey getroffen) - leider bleibt er wieder beim gleichen hängen, ich hab 10 Minuten gewartet.


    Aber das OpenCanopy-Menü ist schön :)


    Edit: Ich schau grad mit diffoscope die Änderungen in der .plist durch, du hast da ja schon gut ein paar Sachen geändert...Auf die Schlüssel wäre ich wahrscheinlich im Leben nicht gekommen, gut, dass es euch in dem Forum gibt :-D


    Wenn das irgendeine Relevanz hat kann ich gerne mal den EFI hochladen der mit Mojave (& glaube ich Catalina) funktioniert hat, für mich sind das deeeeutlich zu viele Änderungen zu der .plist die ich jetzt hab, aber jemand erfahrenes wie du weiß ja vielleicht, wonach er gucken muss...?

    hackintoshler1337 wäre vielleicht ganz gut wenn Du Deine Hardware im Profil und/oder der Signatur ergänzen würdest damit wir wissen um welche Plattform es geht :)

    Die von Dir angesprochenen Probleme mit der RX580 und Ventura zum Beispiel treffen nur zu wenn Du die mit einer CPU kombinierst die den AVX-2 Befehlsatz nicht beherrscht (alles vor Haswell) um zu vermeiden das wir jetzt in eine vollkommen falsche Richtung rudern wäre es also gut zu wissen von was wir reden.

    Ach verdammt - die ist sogar im Profil (und war gestern auch noch sichtbar), aber ich hab mein Profil vorhin auf privat geschaltet... Da hätt ich mitdenken sollen...


    Sorry, sollte jetzt wieder sichtbar sein. Sag gerne Bescheid, wenn was fehlt, was von Relevanz ist.


    Ist eine Haswell-CPU - beherrscht also AVX-2? O.O Cool!

    Danke erstmal für die ganzen Tipps!


    Ich hab beides gemacht, via OCAT die Warnungen behoben und via OpenCore-Bootmenü den NVRAM zurückgesetzt. Da hat's meine EFI-Booteinträge mitgekickt, aber da wusst ich mir zu helfen :-D


    Nur leider hat das beides nichts gebracht, der Bootvorgang bleibt immer noch bei der exakt gleichen (naja, die Speicheradressen sind anders...) Meldung hängen...


    Edit 2023-09-30 13:57: Mir ist grade beim nochmal nachschauen, was sich zwischenzeitlich so geändert hat, aufgefallen, dass ich hier wohl nur die gleiche .zip hochgeladen hab, die ich auch in Post #3 hochgeladen hab... Sorry. 2023-09-29.zip hat die OCAT-Änderungen mit drin.

    Das denke ich nicht. Ich bin der mit Sonoma und einer RX560 unterwegs.

    Versuch es mal mit SMBIOS iMacPro1.1 und deaktivierter IGPU

    Das ist ja schonmal positiv, d.h. wenn wir das schaffen krieg ich vielleicht sogar Ventura (oder Sonoma O.O) - spitze!


    Das geänderte SMBIOS (+ via BIOS deaktivierte iGPU) haben leider keine Änderung gebracht... Hing wieder 5+ Minuten ohne Regung an der Stelle "vm_shared_region_start_address()".


    Passiert tatsächlich keine fünf Sekunden, nachdem der Mac-Verbose-Log anfängt - da rattert ein bisschen Text runter, und dann bleibt's da stehen.

    Hallo zusammen,


    das hier ist nicht mein erster Hackintosh - ich hatte früher schon Clover, und bin kurz danach auf OpenCore mit einem vernünftigen Vanilla Hackintosh der mit Mojave auch recht gut funktioniert hat.


    Irgendwann habe ich den dann geköpft. Die EFI habe ich immer noch, aber mit der bootet der Hackintosh natürlich kein Monterey, da passt schon das SMBIOS nicht, der eingestellte Mac unterstützt kein Monterey. Egal - so oder so würde ich das gerne nochmal machen, also richtig. Bei der EFI von davor war nicht wirklich unordentlich, aber ich habe jetzt einfach keine Ahnung mehr, was da alles drin war, und da dacht ich, wenn schon so ein macOS-Versionssprung, dann gleich dafür passenden EFI nehmen.


    Eigentlich würde ich sogar gerne Ventura haben, aber da hab ich im Guide gelesen dass es da wohl so ein paar Schwierigkeiten gibt mit der RX580 (AVX2? Irgendein Befehlssatz aus 2008? Keine Ahnung. Monterey reicht auch, dachte ich.). Auch hier im Forum gibt's mindestens einen, ich glaube sogar zwei Einträge dazu, dass jemand mit einer RX580 wohl nicht hingekriegt hat, auf Ventura zu aktualisieren. Das hat also keine wirkliche Priorität, wenn Monterey läuft freu ich mich auch schon. Und wahrscheinlich würde dann, insofern Ventura unterstützt ist, das mit einem bisschen Mühe auch laufen. :-)


    Den EFI, um den es geht, habe ich mit dem Guide von https://dortania.github.io/OpenCore-Install-Guide gebaut. Ich hab jetzt einen Bootstick, der so ausschaut:



    Wenn ich den boote, bleibt er leider bei folgender Fehlermeldung hängen:



    9x "vm_shared_region_start_address() failed". Dann passiert nix mehr. Mal ist das Licht an meiner Tastatur noch an, mal schon aus. Jedenfalls muss ich den Haufen Blech dann mit einem langen Drücken auf den Power-Knopf ersticken :-D


    Das Bild ist nicht ganz aktuell - z.B. habe ich da jetzt auch noch -igfxvesa dabei. Und ich hatte mal diesen Patch mit der device-id für die Intel HD von hier hinzugefügt. Hat aber alles nix gebracht. Ich hab VT-d abgeschaltet (was man sowieso sollte), die iGPU mal abgeschaltet, die iGPU mal als Hauptgrafikkarte gesetzt und den Monitor direkt am Mainboard angestöpselt, das ändert nichts. Ich hatte auch mal ein bisschen mit ein paar der Memory-Quirks rumgespielt, hat auch keine Änderung gebracht, aber das ist alles wieder zurückgestellt. Die Meldung kommt auch nur wenige (~15?) Sekunden nachdem die Verbose-Sache da startet, also ziemlich am Anfang vom Bootprozess. Scheint mir was grundsätzliches zu sein :-D


    Die beiden DSDTs die da drin sind hab ich mit der "easy Method" von hier selbst komplil(ert/eren lassen). Klappt aber genau so wenig mit den beiden precompiled DSDTs, die da auch angeboten werden. Von meiner unter Windows erstellten UTBMap.kext zurück auf die UTBDefault.kext zu wechseln ändert auch nix.


    OpenCore & alle Kexts (bis auf vielleicht meine USB-Map) sind die DEBUG-, nicht die RELEASE-Varianten, schon von Anfang an.


    Könnte einer von euch Experten da bitte mal drüberschauen, über das, was ich da fabriziert hab? Ihr findet da den Fehler sicher schnell, ich kann mir nicht vorstellen, dass das was großes ist. Ich weiß nur nicht, wo ich da den Fehler gemacht haben könnte, oder was ich noch ausprobieren könnte.


    Vielen Dank schonmal im Voraus!


    LG

    Jonas