bluebyte Die EDID ist in den Device-Properties eingetragen. Abgesehen davon: sellbst wenn er deinen EFI Ordner verwendet hätte – meine Anpassungen da drin sind nur Aktualisierungen deiner EFI – wäre das nach hinten losgegangen wegen der Installation von Sonoma und der Root Patches mit OCLP, solange die NVIDIA GPU an ist.
Beiträge von ST3R30
-
-
In dem Fall iMac20,2 oder MacPro7,1, weil es für 12th Gen Intel kein SMBIOS gibt.
-
Du hast macOS Sonoma installiert und danach Root Patches mit OCLP angewendet, ja? Dann im Safe Mode booten (Shift drücken, im OC Bootmenü und dann macOS auswählen). macOS startet dann so, dass auf jeden Fall ein Bild angezeigt wird im VESA mode. Danach die Root Patches deinstallieren mit OCLP. Unter "Post-Install Root Patches" gibt es die Option "Revert Root Patches". Vor dem Reboot die letzten Anpassungen in der Config wieder rückgängig machen.
-
Siehe post #35. Booten vom USB stick mit der funktionieren config.
-
Ich habe die ganzen Anpassungen, die da aufgeführt sind bereits in die Config und in deinen EFI-Ordner eingebaut, den ich Dir in Post #35 bereitgestellt habe.
Ich nehmen an, der black screen kommt davo, dass macOS die on-board-grafik abschaltet, wenn er versucht macOS zu booten, um die NVDIA Karte zu verwenden. Aber daf gibt es glaub ich keine macOS-kompatiblen Treiber.
Deswegen config anpassen:
Unter DeviceProperties/Add/PciRoot(0x0)/Pci(0x2,0x0) hinzufügen :
AAPL,snb-platform-id | 00000100 (Typ = Data)
In den boot-args hinzufügen:
-wegnoegpu
(deaktiviert die GPU in macOS)Und dann nochmal testen.
-
Die vorangegangen Beiträge verweisen auf IT-News-Beiträge. Ich habe den Login getestet.
-
-
-
macOS Monterey benötigt Metal 2 und da das nicht von deiner GPU unterstützt wird, wird dafür die on-board grafik der CPU verwendet.
Testtool:
metalgpu.zip -
Naja, das kommt davon, weil du versuchst, macOS ohne OpenCore Bootloader zu starten. Daher einfach vom USB-Stick mit OpenCore starten (via F11 Bootmenü). Dann bootet er auch wieder durch. Und danach würde ich mir überlegen, warum du den EFI ordner nicht auf EFI-Partition der Festplatte kopierst…
PS: Um die Vorauswahl des OS im OpenCore Bootloader zu ändern, den Eintrag,der default sei soll auswählen und STRG + Enter drücken. Beim nächsten Reboot ist das dann voreingestellt
-
Es kommt halt darauf an, welche macOS unterstützt, bzw, wofür es kexts gibt. Für Intel I225 NICs gibt es eine Kext namens AppleIGC. Die verwende ich mit meinem Z490 Mainboard.
Auch wichtig: Die LAN-Kabel Katergorie (min. Cat 6a, besser Cat 7, denn Cat 6a findet man kaum). Einen Router/Switch mit 2.5 gbit support benötigt man ebenfalls. Wird halt oft vergessen.
-
Habe bei Github eine Repo gefunden: https://github.com/crazyi/Hackintosh_Thinkstation_P910
Die entält Clover und OpenCore EFIs. Allerdings sind sie 6 Jahre alt. Daher habe ich mir mal die OC Config geschnappt und auf den aktuellen Stand gebracht.
Da da Kiste ja eine NVIDIA grafikkarte hat, erstmal nur gucken, ob Du High Sierra damit starten kannst.
-
Hallo zusammen,
ich verwende die EFI von Schmockloard für mein Z590 Vision D – läuft wirklich super! Seit dem Update von macOS 15.1 auf 15.3.2 bleibt mein Hackintosh jedoch beim Herunterfahren hängen (Hardreset), und beim Starten gibt es eine Kernel Panic. Der Rechner bootet zwar trotzdem ins System, aber das Ganze ist ziemlich störend.
Ich habe bereits versucht, OpenCore zu aktualisieren und die Config mit dem OpenCore Configurator anzupassen, jedoch ohne Erfolg. Momentan fehlt mir ein guter Plist-Editor, und da ich auf einen Mac Mini spare, möchte ich keinen neuen kaufen.
Ich habe auch versucht, die Kexts über OpenCore Config zu aktualisieren. Im Anhang findet ihr die letzte funktionierende OpenCore 1.01 Version ohne Updates.
Ein weiteres Problem ist, dass seit Sonoma mein WLAN nicht mehr funktioniert. Ich würde mich freuen, wenn mir jemand weiterhelfen könnte. Eine kleine Spende fürs Forum ist natürlich drin.
Vielen Dank schon mal im Voraus!
Beste Grüße,
Clemens
Das Problem hatte ich bei frühen betas von Sequoia. Hab mal Kexts und OpenCore aktualisiert und den ACPI Quirk "FadtEnableReset" aktiviert. Das hat's bei mir gelöst
Um die Fehlermeldungen wieder loszuwerden nach dem reboot, die Logs löschen:
sudo rm -rf /Library/Logs/DiagnosticReports/*
-
ST3R30 Ja, den nutze ich. Aber die Veränderungen haben nur dafür gesorgt, dass beim Start ein TimeOut kam und die Boot UI nur nach Text aussah, also ohne grafische Elemente wie davor.
Die Images hat er auch nicht gesehen. Ich habe auch auf einen zweiten Stick einen offline Big Sur installer geflasht, was aber auch nicht geklappt hat. OpenCore erkennt es auch mit den alten und neuen NVRAM Einstellungen nicht.Ich habe Bluebytes EFI und Config überarbeitet und auf den neusten Stand gebracht und forward-kopatibel gemacht für Monterey und neuer.
- Auf FAT32 formatierten USB Stick kopieren
- Von USB starten
- Im OC boot menü Leertaste drücken
- Reset NVRAM auswähen
- Nochmal von USB Stick starten
- macOS booten
- Falls sie funktioniert auf die EFI partition der Festplatte kopieren (und den Apple Ordner löschen, falls sich da einer befindet)
-
Probier's mal mit dem Standard-Framebuffer-patch:
-
- Wenn 7MB VRAM angezeigt werden, funktioniert die iGPU Acceleration nicht!
- Der Framebuffer Patch in der config von Max 1974 ist ne Intel HD 520. Aber Deine CPU verwendet eine Intel HD 530!
- Cryptexfixup.kext hat nix zu suchen in EFIs für Haswell und neuer!
- Das macOS Update wird angezeigt,da ein Board-ID-Check Skip und RestrictEvents kext mit sbvmm eingebunden sind. Erläuterungen gibt es auf meiner Repo
- Wichtig: im BIOS iGPU nicht auf AUTO stellen, sondern auf ON. Denn falls es noch eine GPU geben sollte, wird die iGPU ansonsten deaktiviert!
-
Die eigentlich relevante Frage ist: unterstütz das alte Board UEFI boot oder nicht?
-
Nutzer Du nutzt doch den EFI Ordner von Bluebyte zur Zeit, oder? Darauf habe ich mich bezogen.
-
Bevor ihr weiteremacht würde ich ein Paar Dinge in der Config von Bluebytes EFI aktualisieren.
- Die Konstruktion zum bypassen des board-id checks ist nicht mehr zeitgemäß. Das macht man heute mit 'ner Kext und NVRAM Parametern. Der folgende Booter Patch sollte deaktivert und ersetzt werden:
- Reroute HW_BID to OC_BID --> deativieren/löschen
- Stattdessen, diesen Board-ID-Skip-Patch in die config einbauen – am besten mit ProperTree: https://github.com/dortania/Op…ig/config.plist#L220-L243
- Als nächstes folgende Kernel Patches deaktiveren/löschen:
- Force IOGetVMMPresent
- Reroute kern.hv_vmm_present patch (1)
- Reroute kern.hv_vmm_present patch (2)
- Reroute kern.hv_vmm_present patch (3) Ventura
- Folgende Kexts einbinden
- RestrictEvents.kext einbinden. Die Kernel Extension regelt dann den board-id check Skip und ändert die Board-ID, sodass macOS denkt es würde in einer VM laufen, sodass System Updates funktionieren und BT. Denn bei den alten Kernel patches gabe es das Problem, das macOS sagt: "Ahh, ich lauf ja als VM, dann soll sich das host system um's Laden der BT firmware kümmern…" Deswegen macht man es jetzt via RestrictEvents
- AMFIPass.kext – Wird benötigt damit Apple Mobile File Integrity Check funktioniert. Denn, wenn man SIP ändert funktioniert das nicht mehr richtig. AMFI ist unter anderem dafür zuständig, dass man pop-ups erhält von (3rd party) Apps, die Zugriff auf das Mic oder eine Webcam z. B. möchten, sodass man sie erlauben kann. Ansonsten funktioniert das nämlich nicht mehr.
- NVRAM: benötigt folgend zusätliche Einträge:
- NVRAM/Add/4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102
- OCLP-Settings | String | -allow_fv -allow_amfi
- revpatch | String | sbvmm,asset
- revblock | String | media
- NVRAM/Delete/4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102
- 0 | String | OCLP-Settings
- 1 | String | revblock
- 2 | String | revpatch
- NVRAM/Add/4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102
Danach NVRAM resetettn und Recovery starten. Und LAN benutzen, nicht WLAN! OCLP Settings sind nicht zwingend erforderlich, außer man möchte Ventura und neuer installieren.
Viel Erfolg!
- Die Konstruktion zum bypassen des board-id checks ist nicht mehr zeitgemäß. Das macht man heute mit 'ner Kext und NVRAM Parametern. Der folgende Booter Patch sollte deaktivert und ersetzt werden:
-
Da aber VMware doch recht tief ins System eingreift…
Wie kommst du darauf? VMWare fusion ist ein Typ 2 Hypervisor. Es läuft als app im Userspace von macOS, nicht im Kernelspace. Es ist technisch gesehen eine normale Anwendung, die du wie jedes andere Programm installierst und startest. Es benötigt keine tiefgreifenden Änderungen am macOS-Kernel oder an Systemdateien, um zu funktionieren. Bei nem Typ 1 Hypervisor (Hyper-V, Proxmox, Xen) wäre das was anderes.
Es wäre vielleicht auch möglich, den Scanner mit nem Docker-Container zu betreiben. Docker virtualisiert halt Anwendungen statt ganzer betriebssysteme. Spart halt ne Menge Ressourcen.