Beiträge von mumsford

Auf der Suche nach dem Fehler bin ich auf den Hinweis gestoßen, dass dies an nicht vollständig oder gar nicht funktionierendem

NVRAM liegen könnte, weshalb ich nun OpenVariableRuntimeDxe.efi in meine Config eingebunden habe.

Nun komme ich jedoch nicht mal mehr in den Bootpicker... Config & Screenshot anbei.

OpenCore ist v 1.0.1 als debug Version und hinterlegt noch nichtmal ein Logfile.

Ich meine mich daran erinnern zu können, dass es auch eine andere Möglichkeit, vor OpenVariableRuntimeDxe.efi gab

um den NVRAM zu emulieren. Würde das ganze noch funktionieren (und wenn ja, wie?)

Update von heute Nachmittag: Nachdem ich nun verschiedene Informationen herausgefunden habe den NVRAM zu emulieren und

einige Anleitungen die OpenVariableRuntimeDxe.efi erwähnen und andere wiederum nicht habe ich folgendes getestet:

Boot ohne OpenVariableRuntimeDxe.efi OC funktioniert und lädt den picker

Boot mit OpenVariableRuntimeDxe.efi OC hängt beim laden des Treibers.

Nun also ohne OpenVariableRuntimeDxe.efi in den Installer und das Terminal geöffnet & versucht das Script
/LogoutHook/ ./Launchd.command install auszuführen was nicht geht, da es nur als non-root ausgeführt werden kann,

man aber offensichtlich in der Recovery direkt mit root Rechten ausgestattet ist...

Also folgenden command getestet:

sudo nvram myvar="$(date)" -> System friert sofort ein (wie bei der Installation)

Ich gehe also nun fest davon aus, dass etwas mit dem NVRAM nicht stimmt und ich eine Alternative benötige.

Obendrein ist das Problem, dass alles was per USB an den Laptop angeschlossen im Installer nicht mehr richtig funktioniert

mehr als hinderlich vorwärts zu kommen. Hierzu ist folgendes zu sagen:

Maus und Tastatureingaben von externen Geräten kommen gar nicht oder nur sehr langsam an (Geräte werden aber erkannt)

USB Sticks werden im Installer selbst praktisch gar nicht mehr erkannt, weshalb ich den Bootstick nach der Sprachauswahl ziehen muss, damit die Überprüfung der Volumes abgeschlossen wird. (Es macht allerdings keinen Unterschied, ob der Stick nun steckt oder nicht, selbst wenn ich den Installer direkt von der SSD ohne Stick starte, bricht die Installation an gleicher stelle ab bzw. friert ein)

Da ich mit den Recherchen nicht weiterkomme hoffe ich auf weiteren Input der Community nun folgende Probleme zu lösen:

NVRAM emulieren oder reparieren (ohne laufende macOS installation)

USB Geschwindigkeit

Folgende Fehler werden zur USB Thematik während des Ladevorgangs übrigens herausgeworfen:

USBToolBox: XHC2: waitingForMatchingService failed or timed out

USBToolBox: XHC3: waitingForMatchingService failed or timed out

USBToolBox: XHC4: waitingForMatchingService failed or timed out

USBToolBox: XHC1: waitingForMatchingService failed or timed out

USBToolBox: XHC0: waitingForMatchingService failed or timed out

Bis dahin, bastle ich weiter & freue mich über jede Idee

apfel-baum Danke dir! In der Hoffnung, dass der Kext mir hilft, sitzt er in der Config drin. Ob das ganze dann im OS auch klappt, steht noch in den Sternen.

Ich werde jetzt aus absoluter Ahnungslosigkeit heraus erstmal den Stick neu, mit vollständigem Installer, präparieren und das ganze dann nochmal versuchen.

Ich werde aus dem Installationslog einfach nicht schlau.. und natürlich muss nach jedem Neustart alles wieder neu heruntergeladen werden,

was jeden einzelnen Versuch nur noch unnötig in die Länge zieht. Dennoch würde ich mich wundern, wenn der Installer dann durchläuft.

Ich will doch nur einen Laptop mit aktuellem Xcode.

Hallo zusammen,

neuer Laptop, neues Glück könnte man sagen. Oder eben auch neuer Frust.

Ich versuche auf meinem HP Omen 16-n0076ng nun seit ein paar Tagen Sonoma zum laufen zu bewegen.

CPU: AMD Ryzen 7 6800H

dGPU: Radeon RX 6650M

iGPU: Wird wohl nicht unterstützt, würde ich gerne später vollständig deaktivieren (Sofern es zu Störungen durch die iGPU kommen sollte)

Es geht bis in den Installer, wo dann irgendwann ein Punkt kommt an dem es einfach nicht weitergeht.

Folgendes ist ebenfalls kurios:

Von USB in den Installer booten ist absolut kein Thema. Dafür funktionieren aber weder externe Maus oder Tastatur.

Im Installer selbst taucht der Bootstick auch nicht mehr im Disk Utility auf.

Foto vom Log während der Installation anbei, sowie der aktuelle EFI-Folder.

EFI.zip

Tag Zusammen,

mit neuer SSD und reichlich vergangener Zeit war mir mal wieder danach, den alten Lenovo zu entstauben.

Die letzte Installation lief noch per Clover und es war Catalina. Nun sitze ich an OpenCore und dem Versuch, Monterey zu nutzen.

Grundsätzlich stehe ich auf dem Schlauch. Die ACPI Errors unter OpenCore 0.9.4 sind identisch zu denen von Clover in 2019, aber weiter als:
[PCI configuration begins ] kommt der Gute nicht.

Vorab ein Auszug der Fehlermeldungen:

ACPI Error: no handler for Region [ERAM] ...
ACPI Error: Region EmbeddedControl (ID=3) has no handler ...

No local Variables are initialized for method [_STA]
No Arguments are initialized for method [_STA] ... etc. etc.

ACPI Error: Method parse/execution failed [\_SB.PCI0_GFX0._DSM] ..... AE_NOT_FOUND

Danach schmierts ab.

Unter clover lief das ganze noch per rename: GFX0 to IGPU worum sich nun ja Whatevergreen kümmern sollte, sowie _DSM to _XDSM und EC0 to EC (letzteres sollte durch die SSDT-EC aus dem Dortania Guide für laptops aber auch unproblematisch sein)

USB wurde unter Windows gemappt.

Lange Rede kurzer Sinn, anbei nochmal die EFI, vielleicht sieht jemand den Wald vor lauter Bäumen außer mir. Oder es wird Zeit, den Lenovo mal in Rente zu schicken!

Zitat von kaneske

Bei mir ist eher macPro7,1 die bessere Wahl bzgl. CPU Performance

Bei mir ist eher macPro7,1 die bessere Wahl bzgl. CPU Performance

Ich probiere auch nochmal den 7,1 - langsam muss ich mich aber auch mit den iServices befassen und mich daher auf ein System festlegen. Mit der Performance bin ich grad ganz zufrieden.

Zitat von kaneske

was darauf deutet, dass die DataProvider.kext nicht richtig ist oder inkonsistent ist. Hatte meine auch ur-plötzlich.

Ich habe per CPUFrindFriend die DataProvider.kext erstellt. 2x mit selbem Ergebnis.
Ist es normal, dass das Skript nur 1. nach dem LFM fragt und 2. ob ich bestimmte Power Saving Modes aktivieren möchte?

Zitat von kaneske

Auf was bezieht sich das??

Nunja, folgendes Szenario:

Ich boote per OpenCore in Ventura und fahre jetzt den PC herunter oder starte neu (spielt keine Rolle). Nun übergehe ich OpenCore indem ich über das BIOS die Windows SSD als Bootmedium nehme und starte ohne jegliche OpenCore Beteiligung -> Tastatur / Maus funktionieren erst nachdem Aus- und wieder Einstöpseln.

Führe ich obere Prozedur aus Windows heraus durch (Aus Windows heraus neustarten, Windows SSD als bootmedium etc. -> wie zu erwarten keine Probleme)

Windows muss also trotzdem, obwohl OpenCore beim Bootvorgang nicht beteiligt ist, informationen bekommen welche dazu führen, dass die Tastatur nicht funktioniert.

UTBMap.kext ohne USBToolBox.kext ist ein Versuch wert, löst aber glaube ich nicht mein geschildertes Problem. Es sei denn mir kann jemand erklären wie der genannte Kext Einfluss auf den Bootvorgang von Windows nehmen kann, wenn OpenCore daran absolut keine Beteiligung hat. Der einzige Anhaltspunkt wäre in meinen Augen eine Variable im NVRAM, oder?

>> Update: Das Tastaturproblem ist seit längerem "gelöst" bzw. hat mit OpenCore oder der Config nix zu tun.
Tastaturen von SteelSeries scheinen in dieser Hinsicht problematisch. Ich habe mittlerweile wieder Razer im Einsatz und hier funktionierts.

Jep, ziemlich wild! Top, sehr schön das du dein Windows noch retten konntest... ständige Neuinstallationen machen auch absolut keinen Spaß.

Werde beides nachher nochmal machen, wenn ich mit meinen Ersteinstellungen soweit durch bin. Irgendwie hab ich ja Hoffnung, dass es plötzlich klappt.

Ventura muss wohl beim Herunterfahren / Neustarten irgendwo Informationen setzen. Wenn ich den Neustart aus Windows heraus durchführe, passiert das ganze natürlich nicht. Wenn es ausschließlich beim Starten aus OpenCore heraus passieren würde, hätte ich wenigstens einen Anhaltspunkt

PassMark Software - Display Baseline ID# 5029216

Edit: PassMark Software - Display Baseline ID# 1711136

Zumindest die macOS / Windows Ergebnisse decken sich ganz gut.

USBToolBox hab ich ganz zu beginn entsprechend laufen lassen und eingebunden. Und das Mapping sollte ja nach einem Neustart in Windows, ohne das OpenCore involviert ist, eh irrelevant sein oder sehe ich das falsch?

Benchmark lasse ich nun auch mal unter Windows laufen - mit und ohne OpenCore beim Start.

Da bin ich wieder! hackmac004 Bios hab ich nochmal geprüft, das passt soweit.

Der Fehler ist nun auch weg, nachdem Ventura nun endlich auch die EFI erstellt hat und diese Partition mit OpenCore als Bootloader erkannt wird.

Wie du vorgeschlagen hast, habe ich auf das SMBIOS vom iMacPro1,1 gewechselt und der Geekbench sieht schon besser aus: https://browser.geekbench.com/v5/cpu/19678394

An die Richtwerte von KungfuMarek komme ich aber noch nicht ran.

Ebenfalls habe ich die CPUFriend.kext mit zugehörigem Skript eingebunden, was allerdings keine Besserung im Geekbench brachte (eher eine kleine Verschlechterung)

Das USB-Problem besteht weiterhin. Nach dem Neustart muss ich die Tastatur aus- und wieder einstecken. Die Maus, sowie etwaige externe Festplatten laufen so. Selbiges Problem besteht dann auch unter Windows. Und das auch, wenn ich OpenCore umgehe und direkt aus dem BIOS heraus den Windows Boot Manager ertüchtige.

Den Installer Stick hats übrigens gegrillt. Nachdem ich per Windows die Recovery neu auf den Stick ziehen wollte, hat sichs beim Kopiervorgang abgeschossen -_-.

Erste Installation lief noch mit Windows Installation. Das hat zumindest gepasst. Aber jetzt kommts: Ventura scheint sich anders zu verhalten. Ich habe lediglich die macOS SSD und den Stick drin.

Das recovery image auf dem stick hat sich jetzt verabschiedet (DMG altered, OC startet es nicht mehr)

Und mein BIOS meckert, siehe Screenshot. Ich klemm jetzt also die Windows Platte wieder dran, ziehe mir ein neues Image und probiere es nochmal.

Vielen Dank für deine schnelle Antwort. Na dann installiere ich den Spaß nochmal neu und mache mich dann ans aufräumen!

Nur um sicher zu gehen: Ich habe für die SSD als Formatierung APFS und dann GUID-Partitionstabelle gewählt. Das hab ich in der Vergangenheit immer so gemacht. Passt das?

Ebenfalls muss ich auch noch an die USB Ports. Nach einen Neustart aus macOS muss ich nämlich die Tastatur und Maus aus und wieder einstecken um das Ganze wieder zur Funktion zu überreden. Ker, und ich dachte es wird im Vergleich zu x79 einfacher

Jup, die ist richtig wild, da hast du Recht KungfuMarek !

Klar, ich hoffe ich komme schon morgen dazu, dann gibts den Geekbench 5 Score hier im Thread.

Wird Zeit, da jetzt richtig aufzuräumen. Zu bedenken ist zudem, dass Ventura grad auf einer Externen USB 3.0 Platte installiert ist, da die Post mal wieder auf sich warten lässt. Gut, den Feiertagen geschuldet sei es so . Hauptsache ist, dass der Boot-Stick erstmal funktioniert.

Update:

https://browser.geekbench.com/v5/cpu/19672222

https://browser.geekbench.com/v5/compute/6172917

Problem:

Ventura hat mir bei der Installation keine eigene EFI auf der SSD erzeugt und nutzt die EFI Partition meiner Windows Installation. Ich habe den EFI-Folder des Bootsticks nun in den EFI-Folder der Windows-Startpartition integriert. Problem: Mein BIOS findet nur den Windows Bootmanager.

Ich möchte eigentlich eine separate EFI Partition auf dem macOS Startvolume, nur wie komme ich nun dazu? Bei all meinen vergangenen Installationen, von High Sierra bis Big Sur, hat mir der Installer grundsätzlich eine EFI Partition auf der macOS SSD erstellt.. Käse! Jemand eine Idee? Ansonsten lasse ich den Installer nochmal laufen und klemme alle anderen Drives ab, dann sollte er ja keine andere Chance haben.

Besten Dank für die Hilfe! Die Installation ist durch - weiteres Feintuning folgt morgen. Ich schaue mir insbesondere nochmal deine SSDT-EC.aml an. Jetzt unter macOS funktioniert das mit den SSDTs eh am besten. Vor allem möchte ich wissen, was die aktuelle config bezweckt.

Treiber, iServices etc. sind der nächste Step =)

Guten Rutsch!

Komme mit deinem Update leider nur bis zur selben stelle.

Update:

Ich habe just Asus spezifische Z690 SSDTs bezüglich der zwei oben zu erkennenden ACPI errors entdeckt und in die EFI eingepflegt. Ich poste nochmal, wenn das Setup durchgelaufen ist

CFGLock ist erledigt, dank CFGLock.efi. ControlMsrE2 gibt nun "unlocked" aus.

Hier nochmal die EFI

So, BIOS Update auf 2204 und nur noch 14 USB Ports in der Map. Es gibt in meinem BIOS keine Einstellungen bezüglich des CFG locks. Und nun habe ich 2 ACPI errors.

Kann ich per

Kernel/Quirks/AppleXcpmCfgLock true

das ganze umgehen?

Passt. Ich schaue mir deine EFI mal genauer an und teste auch mal FakeSMC.kext.

Aber ich bin dennoch etwas verwirrt, ich habe doch OpenRuntime.efi sowie HfsPlus.efi unter Drivers?

Ich überarbeite mal alles und melde mich gleich zurück

Besten Dank schon mal für eure schnellen Antworten!

Mein Bios ist v1720 - my bad, das ist ziemlich alt. Ich werde direkt auf 2204 aktualisieren.

Die UTBMap.kext würde ich gerne auf weniger als 15 Einträge verringern, besonders die USB-C Ports benötige ich prinzipiell nicht. Hier muss ich wohl nochmal durch die Guides blättern, sodass ich mir nicht alle Ports zerpflücke.. Ich gebe euch ein Update, nach erfolgten Änderungen

Gibts Tips worauf ich beim USB Mapping besonders achten sollte? USB 2.0 und 3.0, je nach Gerät, sollte schon beides funktionieren.

Ach und PS: Das interne Wi-Fi kann ich deaktivieren, da ich eine nativ unterstützte Broadcom Wifi Karte nutze, auch unter Windows.

Hallo Zusammen!

Mein X79 Board wurde ausgetauscht gegen ein aktuelles Z690.

Seit einigen Stunden versuche ich nun Ventura dazu zu überreden auf dem Hack zu starten.

Ich habe den Comet Lake Guide auf Dortania, sowie Alder Lake spezifische Infos bei der Erstellung meiner config.plist berücksichtigt.

Ich komme jedoch nicht bis zum Installer bzw. der Recovery.

Wie es scheint, schalten sich im Startvorgang alle USB-Ports ab. Ich habe bereits per USBToolBox die UTBMap.kext erstellt und eingebunden, was jedoch keine Änderung brachte.

Bios Einstellungen hab ich entsprechend des Guides und wie in der Vergangenheit üblich vorgenommen.

Ich hab meinen EFI Ordner mal angehangen.

Ohne USBToolBox.kext & UTBMap.kext bleibt der Starvorgang kurz nach "DSMOS has arrived" stehen.

Mit beiden Kexts ist die letzte Meldung:

USBToolBox: XHCI: waitformatchingservices failed or timeout.

Hat jemand eine Idee, wo ich hier am besten ansetze?

Besten Dank!

Ich hab ein paar Updates bzw. weitere Infos zu meinem Problem.

1. Für den E5-1680 v2 gibts keine Daten im ssdtPRGen script... Trotz Einfügen in der User Defined.cfg mit folgenden Eckdaten:

"E5-1680V v2,140,1100,3000,4400,8,16,4,100"

(140W zieht sich der Gute, dank des OCs auf 4,4GHZ. Mag das OC schuld an der Misere sein?)

lässt sich das Script blöderweise nicht ausführen. Und das ist, denke ich, der Grund für die Meldungen beim booten und den sporadischen KPs.

Mal läuft das System ein paar Stunden, mal nur ein paar Minuten. Irgendwo muss der Bock ja sitzen. Hat jemand Tips für mich, bzgl. des Power Managements vom 1680v2?

Hallo Zusammen,

es ist mal wieder soweit und ich habe ein ruhiges Wochenende mal macOS Monterey gewidmet.

Clean Install ohne jegliche Altlasten von Grund auf alles neu eingerichtet.

Das System startet mittlerweile relativ zuverlässig, bis auf einige Kuriositäten.

USB Ports funktionieren nur bedingt. Der ASM1042 taucht unter IOReg und PEX0-PEX7 auf, Hackintool zeigt ihn auch. Onboard USB 3.0 ist aber außer Funktion und

USBMapTool erkennt unter macOS den ASMedia auch nicht. Das hab ich allerdings erwartet.

Die USB 2.0 Ports verhalten sich auch merkwürdig. Bis Catalina genügte in der Vergangenheit das Umbenennen von EUSB auf EH01 und USBE auf EH02. Unter Monterey

funktioniert dann allerdings nur 1 USB Port, weshalb ich mich für das Mapping entschieden habe. Dies scheint allerdings auch zu Problemen zu führen, die sich wie folgt äußern:

Maus und Tastatur sind wie Dongle Wireless verbunden. Schließe ich diese zusätzlich zum Laden an einen freien USB Port, gehts relativ zügig -> KP (Power Management)

Das passiert tatsächlich sowohl mit aktiviertem PM als auch ohne (Drop CpuPm; Drop Cpu0Ist)

Über eine PCIe Karte mit 4 USB 3.0 Ports wollte ich das Problem des ASMedia Controllers umschiffen. Ist irgendein Fresco Logic und funktioniert auch oberflächlich,

zerschießt bei angeschlossenen Geräten jedoch die WiFi Fähigkeit des hacks, was mich zum nächsten Problem führt:

BCM943602CS Bluetooth wird zwar erkannt, Adresse ist aber; NULL und aktiviert ists auch nicht. Aber das liegt wohl offensichtlich an Monterey.

Was mich aktuell am meisten ärgert, sind unvorhersehbare KPs, welche darin resultieren, dass der PC danach automatisch in Windows bootet.
(Bootoptionen sind so eingestellt, dass von der Windows SSD eigentlich gar nicht gebooted werden dürfte, nundenn...) Sobald der Hack einmal in Windows gebootet hast,

startet Monterey nicht mehr, es sei denn ich setze per OC den NVRAM zurück. Dann bekomme ich jedoch keinen Bericht mehr angezeigt, weshalb macOS ursprünglich abgestürzt ist.

Bin mit meinem Latein definitiv derzeit am Ende und freue mich über jede Idee, das Ganze zu optimieren. Meine EFI hab ich mal angehangen =)