WWDC 2025, macOS 26 & Hackintosh

Habe es auf meinem Fujitsu Esprimo Q958 Mini-PC zum Laufen bekommen (Coffee Lake mit iMac20,2 SMBIOS). Der VMM board-id spoof bzw RestrictEvents kext scheint aktuell nicht zu funktionieren. Es kam das Forbidden symbol als ich versucht habe mit iMac19,1 zu booten

Intel Wifi funktioniert natürlich nicht

Und, was irgendwie neu ist: LAN funktioniert nicht. Verwende IntelMausiEthernet. Probiere es gleich mal mit IntelMausi

Ich muss sagen, dass ich den ganzen glass look und die icons furchtbar unprofessionell und anbiedernd finde.

Weitere Erkenntnisse:

• Block com.apple.iokit.IOSkywalkFamily scheint zu funktionieren (System crasht nicht)
• IOSkywalkFamily.kext und IO80211FamilyLegacy.kext lassen sich injecten ohne zu crashen
• Danach habe ich das Kernel Debug Kit für macOS 26 (ist übrigend Kernel Version 25.0) installiert
• Danach OCLP

Danach wollte ich WiFi patching probieren, aber:

Kann man das irgendwie overrriden, damit ich's zumindest testen kann?

Ich habe vermehrt Meldungen von Usern gesehen, bei denen das Netzwerk mit Tahoe nicht mehr funktionieret. Das kann mehrere mögliche Ursachen haben:

1. Der Inject der Kext mit OC funktioniert nicht mehr richtig? Bitte kurz mit IORegistryExplorer oder kextstat prüfen, ob die Kext geladen wurde und an das Gerät gebunden wurde.
2. Es könnte auch sein, dass Apple das traditionelle mbuf-basierte Interface für Netzwerktreiber aus dem Kernel entfernt hat. Deprecated ist es ja schon seit einiger Zeit. In diese Falle würden wir auf dem Schlauch stehen, da dann nur noch die IOSkywalk-basierten Treiber unterstützt würden, was u. a. auch bedeuten würde, dass ohne AppleVTD kein Ethernet mehr möglich wäre. AMD und Intel-Boards ohne AppleVTD-Support wären damit raus. Ich möchte auch drauf hinweisen, dass ich in diesem worst case Szenario auch kein Update für Tahoe bereitstellen kann.

Zur Fehlersuche könnte es hilfreich sein evtl. SIP auszuschalten und die Treiber in /L/E zu installieren, damit Debug-Meldungen in den Kernel Logs auftauchen (geht beim injecten mit OC nicht).

Quote from f10

Also bei mir funktionieren beide Ethernet Buchsen nicht (intelmausi und smalltree intel kexte), oder brauche ich da noch ein beta boot-arg?

Eben getestet LAN am Elitebook (Intelmausi) läuft bei mir BootArgs habe ich lediglich -lilubetaall drin sollte aber für Lan keine Rolle spielen...

So nun auch vom Elitebook aus unter Tahoe geschrieben

Das UI ist definitiv gewöhnungsbedürftig und bei so mancher "Neuerung" frage ich mich schon was das wohl soll (Der Launchpad Ersatz zum Beispiel) anderes finde ich aber auch ganz gelungen trotzdem wird es Zeit brauchen sich an das neue Look and Feel zu gewöhnen...

MacGrummel läuft alles ohne Probleme (sowohl intern weil ist ja nen Laptop) als auch via BT (Logitech MX Keys + MX Master) und auch ein eben mal kurz via USB Kabel angestecktes Keyboard läuft. Der Umstieg von USBMap.kext auf die SSDT Lösung hat den Erfolg gebracht. Bis auf das WLAN Gelump löppt das Elitebook mit Tahoe recht gut bislang...

Quote from cobanramo

Bei mir hängsts an;

" kernelmanagerd is not active "

und

" Loading Pageable KC from file /System/LLbrary/KerneLCollect Lons/BaseSystemKernelExtensions.kc "

Das gleiche auch bei mir. Auch mit der OC Version von griven die weiter oben verlinkt ist. Habe es probiert mit MacPro7,1 SMBIOS und auch mit iMac20,1 SMBIOS, die plist von meiner USBPorts.kext jeweils auch angepasst auf MacPro,7,1 und auch auf iMac20,1 beim jeweiligen Neustart. Hängt immer an der gleichen Stelle. -lilubetall und -amfipassbeta sind gesetzt gewesen und auch nur die essentiellen kext's (Lilu, VirtualSMC, AMFIPass, RestrictEvents und Whatevergreen), auf true gestellt. Muss dabei jedoch noch erwähnen, dass ich erst gar nicht zum Installationsmenü von Tahoe kam. Habe mit der jeweilig angepassten EFI in die Recovery von 15.5 gebootet und von dort aus dem Terminal heraus die Installation mit 'startosinstall' angestoßen und beim reboot dann die Installationspartition genommen. Ich denke, dass hängt bei mir, bei Arkturus und auch anderen Usern von der verwendeten CPU (KBL) ab. Auch hatte ich nach längerem warten auf einmal das Verbotsschild, wo ich den Output dann aber nicht mehr lesen konnte, weil der Screen-Output total zerfetzt war. Ich überlege noch, ob evtl. ein CPU Spoofing für die KBL CPU's mit gleichzeitigem USBMap per SSDT was bringt. Oder auch mal die iGPU im BIOS mit einzuschalten und in den Properties wieder zu aktivieren Aber ganz ehrlich Kinners? In diesem frühen Stadium dieser Beta, fehlt mir einfach die Lust und die Geduld, viel was weiter an meiner alten Möhre weiter herum zu experimentieren. Dafür ist mir meine Zeit - sogar als Rentner - zu schade...

Edit: Zum erstellen einer SSDT für USB haben wir doch hier im Forum eine sehr gute Anleitung vom Oktober 21' von apfelnico -> USB mittels SSDT deklarieren

Es ist schon eine Weile her (5-6 Jahre??? weiß nicht mehr genau wie lange, ist auch Wurscht), als ich mein USB Mapping gemacht habe, aber ich meine mich zu Erinnern, dass das altbewährte Hackintool, außer der USBPorts.kext, auch eine SSDT auf dem Desktop beim exportieren erstellt hat, welche man dann anstelle der kext einbinden konnte. Das mit Hackintool von mir beschriebene Szenario und dem erstellen einer SSDT, dürfte auf älteren macOS Versionen, bevor Apple die 15 Port Beschränkung eingeführt hat, noch funktionieren. Oder liege ich mit meiner Vermutung falsch?

Wollte gestern noch Tahoe auf meinen T490 installieren, was noch nicht funktioniert hat. Dabei habe ich bemerktt: sollte RestrictEvents und der der board-id VMM spoof in Zukunft nicht mehr funktionieren, bleiben nur noch 4 SMBIOS-Varianten zur Installation: imac20,1/20,2 sowie MacBookPro16,1/16,4 (die für die 16" MBP Varianten). MBP16,2 und MBP16,3 sind raus.

Das Elitebook läuft mit dem MBP 15.2 SMBIOS so wie vorher auch schon mit Sequoia. Ich habe hier in OC unter Booter den Skip ID Check patch aktiv und ansonsten RestrictEvents mit SBVMM...

Installiert habe ich aus dem laufenden Sequoia heraus mit der App wobei das Ziel ein leerer APFS Container war. Ich checke gleich aber auch ob der USB Installer so auch starten würde ein solcher wird eben erstellt...

EDIT: funktioniert mit dem Patch auch vom USB Installer aus demnach zumindest aktuell müssen wir uns darüber wohl keine Sorgen machen

Quote from JustFun

Gerne helfe ich dir aber erst du musst mir helfen und ein paar Fragen beantworten:

• Willst du Tahoe auf extra Festplatte testen oder direkt Update durchführen !
• Wenn du direkt Update machen möchtest und auf MacPro7,1 umwechselt dann musst du alle deine Programme, die mit einem Produkt-Key aktiviert sind, neu aktivieren, da sonst sind sie nicht mehr zugänglich !
• OCLP läuft noch nicht, um Fenvi Karte zu patshen und wie ich hier mitlese, InteMausi.kext läuft auch nicht d.h. du bleibst ohne internet
• Brauche ACPI-Dump von deinem System, um SSDT für USB zu erstellen.

Gruß

JustFun

JustFun danke

Ja ich denke das MacPro7,1 Bios macht bei mir sicher Sinn, weil ich auch die Radeon VII an Board habe. Die wird ja nach wie vor unterstützt.

Ich müsste mir dann nur für die CPU eine passende kext machen. Dies war auch der Grund glaub ich für mein 19,1 BIOS.

Möchte nur das System testen ob mein Notationsprogramm (Finale 27) noch läuft. Finale wurde eingestellt. Sollte es an Tahoe nicht laufen muss ich eh am Aktuellen bleiben.

Hab leider keine Zeit für ACPI-Dump gehabt. (Vielleicht am Abend)

Hab mit dem Hackintool kurz ein paar Files rausgelassen. Kann man Diese auch verwenden?

Dank Dir

Quote from guckux

Theoretisch sollte sie unterstützt werden. Laut Apple soll Tahoe MacPro ab 2019 unterstützen. Laut everymac.com gab es da noch ein Modell - aber mit einer einer Radeon Pro 580X - welche wenig später gegen modernere ausgetauscht wurde.

wäre es eine Option das bislang genutzte SMBIOS - hier iMacPro1,1 - beizubehalten und anstelle dessen das Bootarg -no_compat_Check verwenden?

Warum verwendet Ihr nicht einfach den in Post #90 genannten BooterPatch zusammen mit RestrictEvents und dem SBVMM arg? Das -no_compat_check arg hat einige weitere Nachteile gegenüber der genannten Lösung da es nicht nur den Booter betrifft sondern auch im System selbst greift...

Hallo Griven,

zum mitschreiben: Booterpatch von Post 90, RestrictEvents.Kext und das SBVMM arg?

Richtig?

Was war nochmal das SBVMM arg?

LG Franziska1993

Quote from Arkturus

wäre es eine Option das bislang genutzte SMBIOS - hier iMacPro1,1 - beizubehalten und anstelle dessen das Bootarg -no_compat_Check verwenden?

Hatte es bei mir erst mit SMBIOS MacMini8,1 und dem Bootarg probiert, da hat der Installer bei mir ins Verbotsschild gebootet.

Musste dann auf iMac20,1, damit das System bootet.

Franziska1993

das bootarg ist für den restrictevents.kext

- > https://github.com/acidanthera/RestrictEvents

und bewirkt, das osx meint es wäre in einer virtuellen maschiene

lg

Richtig einfach unter den boot-args im Bereich NVRAM->ADD->7C436110-AB2A-4BBB-A880-FE41995C9F82 folgendes hinzufügen: revpatch=sbvmm

Der SkipBoardIDCheck patch gehört analog dazu unter Booter->Patch eingetragen. Hat man beides in Place dann braucht sich, stand jetzt, um das SMBIOS nicht zu kümmern und kann es lassen wie es ist.

griven Stimmt, der board-id skip war nicht in der Config. Jetzt geht's wieder.

Mieze

Wegen LAN: habe mal ein paar Screenshot unter Tahoe gemacht von iOReg-Einträgen. Sieht aus als sollte es funktionieren, tut es aber nicht (I219-LM)

LAN.zip

Gibt es mittlerweile schon dedizierte GPUs die funktionieren? Weil entweder habe ich nur die HD530 oder die R9 270X und beide laufen nur mit OCLP oder richtigem framebuffer, oder läuft die HD530 mit Tahoe?

LG

Der eigentliche Grund, warum man RestrictEvents und das sbvmm boot-arg bzw. NVRAM parameter verwendet, ist, dass es eine spezielle board-id für VMs aktiviert, die es erlaubt, weiterhin Updates herunterzuladen und installieren zu können – was ansonsten nicht möglich wäre, wenn man den Board-id Skip verwendet, um macOS mit einem nicht unterstützen SMBIOS zu booten.

Triso01 Bei der Intel 530 könntest Du es mit einem Framebuffer-Spoof versuchen, weil Root-Patches lassen sich aktuell nicht triggern mit OCLP ("Unsupported Host OS")