Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Big Sur kann ich auch mal probieren
damit könntest du zumindest gucken, was geht, könntest dir einen efiordner für die hardware optimieren, und dann gucken, ob der auch mit mojave funktioniert. für den anfang solltest du aber versuchen soviele schwierigkeiten wie irgendmöglich zu vermeiden.
Moin Leutz, wenn ich da paar Ansatzpunkte bringen darf...
Mojave auf Comet Lake
Das kann auch nicht normal laufen... MacOS 10.15.6 ist hier das mindeste...
alles andere müsste erstmal einen sauber funktionierenden EFi haben vorauf man bauen und eben "nicht unterstütztes" später testen kann.
Ausserdem sind die meisten SSDT`s im Ordner ACPI vom ersten Posting gar nicht für diesen Platform.
Die sind für die bisherigen Standard Acpi`s Pfade zbspl. auf _SB_.PCI0.XHC_.RHUB aufbauen.
RocketLake`s bauen aber auf \_SB.PC00.XHCI.RHUB, müsste man also diese korrigieren oder im original DSDT nachgucken was hier sache ist. Hier kann man nicht einfach Stock SSDT`s benutzen oder sollte zu denen greifen die mehr oder weniger alle optionen beinhalten wie zbspl. die im Anhang SSDT-EC-USBX-DESKTOP.aml.
Es wird hier versucht 2x Embedded Controller zu laden, aber 2x mit falschen Pfaden.
SSDT-SBUS-MCHC.aml ist nicht für dieses Platform.
Weiter geht es mit dem IGPU, das wird auch nichts mit der ID 07009B3E, wie schon erwähnt wurde, auf einem RocketLake Board funktioniert die CometLake IGPU nicht. Wenn schon mit einem passenden SMBIOS Headless ist da zu konfigurieren (0300C89B).
Unter Bios ist "Resizeable Bar" no go, das verhindert immer den MacOS start.
Die Fehlermeldung auf dem Bild "End Randomseed" zeigt das dein Efi schon gar nicht mal bis zum MacOS Initialisierung geschafft hat.
Bei den SSDT`s musst du zuerst mal an das nötigste halten...
zbspl. RHUB fix ist auch nicht für dein Platform.
Auch bei den Kexte, zunächst mal nur das nötigste bis es startet.
Gruss Coban
cobanramo Mit Fake-Id soll es einigermaßen laufen, Keksfamilie hat soweit ich weiß Mojave auf Comet Lake am laufen, da musste aber so gut wie alles mit einer Fake-Id versehen werden, damit es überhaupt irgendwie läuft. Der TE hat noch Glück mit dem LAN, das sollte laufen, ein I225-V würde nicht laufen.
Klar, mit genug zeit und elan kann man sicher vieles noch gerade biegen.
Ich würde aber für den anfang doch noch Catalina mind. Build 15.6 empfehlen,
weil gerade beim anfang weiss man echt nicht woran das ganze eben scheitert und schnell den spass daran verdirbt.
Sobald man ein stabiles Efi in der hand hat und das ganze einigermassen läuft kann man sicherlich experimentieren bis es nicht mehr geht. Manches ist es ganz banal aber kann dir tagelang beschäftigen 
Gruss Coban
Je nachdem, um welche 32BIt-Apps es sich handelt, könnte ja auch Rectroactive funktionieren. Deshalb wäre auch meine Empfehlung, dem Tipp von cobanramo zu folgen und das System erst einmal mit 10.15.7 an den Start zu bringen. Danach kannst du schauen, was geht und was nicht.
Du lädst immer noch einen SSDT-RHUB.aml den du nicht brauchst.
Und nochmal, der ist zu 100% auch falsch weil es falsche Pfade beinhaltet.
Du brauchst den nicht, wenn schon muss es für dich so aussehen.
Wenn du dir folgendes Bild anguckst heisst es nicht das du den 1:1 übernehmen musst.
Nur die Rot markierten sind für dich relevant.
Wenn auf dem Bild jetzt aber ein "SetupVirtualMap" auf Yes steht du aber den unten folgenden Teil ausser acht lässt...
Passieren dir eben solche kleine Fehler die das ganze versauen 
Im Detail steht dann auch was schief läuft
Bei einem Hackintosh ist Lilu.Kext priorität 1.
Ohne Lilu kannst du mittlerweile so gut wie nichts laden. Daher sollte der an erster stelle stehen.
Alles was du vorher lädst wird nicht geladen und landet in nirvana.
Bei dir steht Lilu im abseiht.
Halte dich mit den ladefolgen der Kexte an den SAMPLE.plist
Ich persönlich rate dir ab vom OpenCore Configurator, dieser Fehler ist genau dem zu verdanken.
Laut Anleitung sollte der "DisableRtcChecksum" zwar auf No stehen aber das Anleitung wiederum ist für einen CometLake.
Du aber hast fast das gleiche "RocketLake" daher sollte der "DisableRtcChecksum" bei dir auf Yes stehen.
https://dortania.github.io/hac…21/04/24/rocket-lake.html
Bedenke einfach das ab BigSur 11.3+ die XhciPortLimit wertlos und nicht funktional ist.
Unter BigSur kannst du den USBInjectAll.kext auch kicken, ist auch nicht zuverlässig.
Unter Catalina wiederum ist es wiederum beides einsetzbar aber wenn du XhciPortLimit einschaltest ist der Kext überflüssig.
Für USB Port patschen gibts auch andere Wege, dazu aber später.
Unter PlatformInfo für den SMBIOS ist die "Generic" auszufüllen und völlig ausreichend.
Die beiden rot durchgestrichenen "DataHub" & "SMBIOS" sind meiner Meinung nach überflüssig und macht mehr Fläche für Fehler.
Also beides löschen, Halt dich an den SAMPLE.Plist und nicht irgendwelche Tools die eh keiner dir erklären kann was was ist und wofür das da steht. Configuration.pdf ist dein freund.
So, teste mal mit diesen korrekturen, denke du wirst weiterkommen.
Gruss Coban
Hab mal versucht alles rein zu bekommen was du angesprochen hast. Gestern war es wohl definitiv zu spät. Schaut so aus als käme er zwar weiter, ab so wirklich startet es leider noch nicht. Bin mir aber ziemlich Sicher mit Hilfe des Forums den Hackintsoh ans Laufen zu bekommen. Im Anhnag der geänderte EFI-Ordner sowie der Log von OC. Vielen Dank schonmal für deine ausführliche Antwort cobanramo
Hier noch der Screenshot wo es aktuell hängen bleibt:
Versuch mal mit dem gleichen efi aber mit diesem Config.plist.
Wenn es immer noch nicht startet musst du dich dem BIOS konzentrieren, dann hängt es fast sicher am Bios.
Gruss Coban
Die Meldung kommt vom ungepatchtem oder noch nicht gepatschtem USB Ports, ist aber nicht relevant.
Wenn du per USB starten versuchst; versuch mal andere USB Ports. Ansonsten wenn das wegen der USB Ports anhält müsste man dies vorher erledigen.
Kannst du mal mit dem letzten Config den hingestellt hab ein Bild vom verbose Boot zeigen?.
Gruss Coban
Ist das Catalina die du versuchst? wenn nicht versuch mal Catalina Installer stick.
Wenn das geht können wir sehr einfach usb Ports patchen, danach sollte dan auch BigSur oder Monterey gehen.
Gruss Coban
Bin leider erst jetzt dazu gekommen. Mit Catalina kommt es nicht ganz so weit wie mit Big Sur:
Ist da irgendwas von Tony eingeflossen? Ich wundere mich zumindest, dass hinterm LucyRTL8125Ethernet ein Support Hinweis zu ihm steht, obwohl der Kext eigentlich von Mieze ist.
KextUpdater liefert übrigens bereits eine neuere Version 1.1.0d12 von dem Kext direkt von Mieze.
Am Ende Deiner Bilder taucht immer RTL8125 auf, wo es nicht weiter geht.
Ich habe mir mal zwei Deiner EFI's von oben angesehen. Die Kext-Reihenfolge geht jedesmal wild durcheinander, finde ich zumindest.
IntelMausi.kext ist zusätzlich aktiv. Ist dies so gewollt?
AppleALCU (only Digital Audio) statt AppleALC ist auch so gewollt?
Muss alles nicht die Ursache sein, es sind nur Dinge, die mir aufgefallen sind.
Edit:
sorry, falsch gelesen (falsche Verdächtigungen gestrichen)
Da steht das man Tony nicht unterstützen soll. Das ist teil das Codes. https://github.com/Mieze/LucyR…RTL8125Ethernet.cpp#L1064
Natürlich, richtig. Mal wieder zu schnell und nicht alles gelesen, bzw. die Brille nicht geputzt.
Danke
Am Ende Deiner Bilder taucht immer RTL8125 auf, wo es nicht weiter geht.
Eigentlich ist es recht häufig der SMCSuperIO, bei dem es nicht weiter geht. Hat das mit der Netzwerkkarte zu tun?
Ich habe mir mal zwei Deiner EFI's von oben angesehen. Die Kext-Reihenfolge geht jedesmal wild durcheinander, finde ich zumindest.
Welche Reihenfolge empfiehlst du?
IntelMausi.kext ist zusätzlich aktiv. Ist dies so gewollt?
Sollte auch mit drin sein, ist das nicht gut?
AppleALCU (only Digital Audio) statt AppleALC ist auch so gewollt?
Das ist in der Tat so gewollt da ich das HDMI-Audio nutzen wollte. Besser das AppleALC probieren?
Ich versuche heute mal sorgfältiger zu sein. Gestern Abend war es nach einem langen Büro-Tag nur noch eine Null-Nummer von mir.
sorry dafür
Ich hatte die Bilder nur überflogen und auch die EFI's nur kurz betrachtet.
Ich fang mal von hinten an bei den Zitaten:
1.
HDMI-Audio bekommt man ja auch mit der AppleALC, sofern die Einstellungen passen.
Das analoge Audio (die internen/externen Anschlüsse), sowie Optical/SPDIF (digital) werden in einer hoffentlich gut erstellten LayoutID der AppleALC geregelt.
HDMI hat mit dieser LayoutID nix zu tun, sondern die Grafikkarte sollte erst einmal richtig funktionieren und es braucht evtl. Einträge wie hda-gfx, etc..
Der Grafik-Controller sollte kein Exot sein, was die RX 580 aber wohl nicht ist.
Den Sinn der AppleALCU habe ich selbst noch nicht ganz verstanden, bzw. getestet (muss ich mal machen), allerdings könnte ich mir vorstellen, dass es hier um ein altes SPDIF-Problem geht.
Dabei ist es so, dass auf Hacki's per SPDIF immer nur Stereo am Receiver (oder anderem Empfänger) ankommt. Dieses Problem haben wir früher schon gelöst, in dem man die LayoutID anders konfiguriert.
Hierbei passierte aber, dass zwar SPDIF nun z.B. 5.1 lieferte, aber das normale Onboard-Audio gebrochen wurde und nicht mehr ging.
Ich habe die AppleALCU selbst noch nicht getestet, aber vielleicht ist hier ja bereits ein User, der Licht ins Dunkel bringen kann.
Im Normalfall verwenden aber alle die AppleALC und haben dennoch HDMI-Audio.
2.
betreffs IntelMausi ist halt die Frage, welche und wie viele LAN-Controller Du im Rechner hast?
Wenn Dein Lan-Anschluss die LucyRTL8125Ethernet braucht, dann ist doch jeglicher weiterer LAN-Kext überflüssig, bzw. sinnlos.
Diesbezüglich meine ich ja nur, Fehlerquellen ausschließen und eingrenzen.
3.
Ich hatte in den beiden EFI's nur kurz gesehen, dass die Reihenfolge jeweils anders war und immer irgendwie quer Beet.
Eine perfekte Reihenfolge habe ich sicher auch nicht, aber ein Rechner der auf Lilu angewiesen ist, da sollte Lilu ganz oben stehen, gefolgt von WEG für die Grafik, zumindest wird es häufig empfohlen.
Vielleicht gefolgt von AppleALC oder AppleALCU und/oder VirtualSMC, der auch super wichtig ist für den Hacki.
Wenn es sich um ein Install-Versuch handelt, dann würde ich alles überflüssige erst einmal weglassen, wie die PlugIns von VirtualSMC (wieder der Zweck, Fehlerquellen minimieren).
Treiber-Kext's wie Intel-Wlan oder vergleichbares immer erst danach.
Usb-Treiber wären zeitnah auch wichtig, besonders wenn man versucht von einem Stick zu installieren.
Hierbei ist mir aufgefallen, dass in einer EFI der USBInjectAll.kext drin ist, in der anderen EFI gar nichts diesbezüglich, was mich zu Punkt 4 kommen lässt.
4.
Ich habe hier im Moment noch den Verdacht betreffs USB. Du hast ja USB für den Desktop nicht gemappt, verwendest in einer EFI den USBInjectAll.kext, in der anderen EFI gar nix diesbezüglich.
Beide Rechner bleiben, je nach Version, so ziemlich an der gleichen Stelle hängen.
Ich nehme mal an, dass jegliche Versuche von den Bildern oben mit einem USB-Install-Stick gemacht worden, oder?
Wenn ja, dann habe ich dieses Verhalten auch schon erlebt, auf einigen alten Rechnern von mir, Verbose-Mode bleibt einfach stehen und nix geht mehr.
Ich vermute, dass er an dieser Stelle die Verbindung zu USB verliert, also zu dem Stick, so wie ich es damals oft erlebt habe.
Ich habe mir damals immer so geholfen, dass ich eine alte Platte entsprechend formatiert habe, den Installer statt auf USB-Stick auf die Platte installiert habe und den Bootloader dann auf die EFI-Partition dieser Platte.
Mittels Rechner-Bootmenü diese Platte gebootet. Damit bist Du frei davon, falls es ein USB-Problem ist, worum man sich auch später noch kümmern kann.
In der Regel wurden die USB-Tastatur/Maus komischer Weise immer erkannt, so dass man auf diese Weise durch den Installer kam.
So, letztendlich beruht alles nur auf Erfahrungswerte und ich kenne Deinen Rechner nicht wirklich, daher kann auch alles unwichtig/unrichtig sein, was ich schrieb.
Du musst selbst sehen, was davon ein Ansatz sein könnte, bzw. bei Dir nicht zutrifft, ggf. bei anderen Usern weiter um Hilfe bitten.
