macOS 26 Tahoe auf den Hackintosh

Es gibt bereits eine Korrektur, Root Patch kann ich wieder ausführen:

https://github.com/laobamac/OCLP-Mod/releases/tag/3.1.5

⚠️ Do not install the sound card patch or the old version of the USB patch before the release of 26.4B1's own KDK! 26.4B1 is not compatible with the old KDK!

• Apple deleted the HFS+ file system in macOS 26.4B1, and this version is all replaced with APFS to be compatible with the new system.
• Apple has increased the hdutil permission in macOS 26.4B1, and it is not allowed to mount without root. This version has been fixed.

Gut zu wissen. Auch für echte Macs. Ich hab ja u.a. einen Mac Studio (Signatur), und da hängt ja noch ein externes RAID5 via Thunderbolt dran. Ist natürlich seit je her als Mac OS Extended (Journaled) formatiert und fasst 96 TB, fast voll. Das wäre ein SuperGau, wenn ich nach einem Update nicht mehr drauf zugreifen kann und ne Rolle Rückwärts der Mac nicht akzeptiert. Was denken die sich eigentlich? Wurde das kommuniziert? Da kommt mir eh keine Beta rauf, aber wenn das im Release auch so ist – muss man echt drauf achten.

alle Lazy People, die Warnungen (do not install sound card patch) nicht lesen, dürfen den Snapshot über Recovery aktiveren:

mount -uw "/Volumes/Macintosh HD"

bless --mount "/Volumes/Macintosh HD" --bootefi --last-sealed-snapshot

Edit: zu früh gefreut, zumindest bei mir schlägt der root patch fehl - scheinbar ist mein Drucker der Bösewicht

Edit2: tatsächlich lagen da in /L/E zwei Canon USB Treiber - Danke Apple, dass du mich zum Aufräumen zwingst 😂

Nach Löschen der Altlasten und X-ten Mal Revert / Reboot / Root Patch funktioniert BCM Wifi - für Audio muss jetzt mal wieder Voodoo ran.

Möglicherweise stelle ich mich ja auch nur dumm an aber irgendwie finde ich jetzt zumindest keinen direkt offensichtlichen Weg den Audio Patch nicht zu installieren (OCLP-Mod lässt einem da ja nicht unbedingt die Wahl)...

Was muss man den tun um den besagten Patch nicht zu installieren ?!?

Nevermind, einmal die Brille geputzt und nochmal durch die APP geklickt und da war sie dann die Option um den Patch abzuwählen

Ein erstes Fazit meinerseits zu macOS 26.4 bzw. iOS 26.4:

Entweder sind die .4er Updates mit extrem heißer Nadel gestrickt und massiv fehlerbehaftet oder aber wir werden künftig noch viel viel Freude damit haben. Neben den ja bereits bekannten HFS+ Thematik gibt es, zumindest auf meiner Seite, auch reproduzierbar Probleme bzw. Merkwürdigkeiten mit oder besser gesagt im Umfeld von WLAN (MacBookPro M1, iPhone 15Pro). Konkret geht es mir um Apps die Websockets nutzen (in meinem Fall die HomeAssistant Compaingnion App) zur Kommunikation mit einem Server nutzen. Mir ist heute morgen aufgefallen das meine HomeAssistant App auf dem MacBook sich totgelaufen hat (Loading Data) und irgendwann dann anzeigt "Verbindung wurde getrennt" und sich dann weigert sich erneut zu verbinden gleiches Verhalten auf dem iPhone. Ich habe zunächst gedacht das mein Homeserver offline ist was aber nicht der Fall war denn über den Browser funktioniert der Zugriff vollkommen normal. Der nächste und eigentlich ja auch nachfliegende Gedanke war dann das die App vielleicht einfach nicht mit 26.4 kompatibel ist das scheint aber nicht der Fall zu sein denn unter iOS 26.4 funktioniert die App solange normal wie das iPhone nicht im WLAN ist (Mobilfunk) die Verbindungsabbrüche treten erst im WLAN wieder auf zudem kann ich am MacBook ein Verbinden reproduzierbar "erzwingen" indem ich die WILAN Verbindung kurz trenne und anschließend wieder verbinde. Das HackBook mit dem OCLP-Mod Patch zeigt sich von alldem unbeeindruckt hier läuft die App exakt so wie immer...

Apple was immer Ihr da geschraubt habt schraubt es bitte wieder zurück weil so ist das Murks oO

Hat ausser mir jemand ähnlich merkwürdiges Verhalten von Apps die Websockets nutzen festgestellt ?!?

Auf keinen Fall 26.4 installieren, wenn man Root Patches für Sound benötigt (also eigentlich alle)! Das System startet danach nicht mehr – acuh wenn man OCLP-Mod 3.1.5 zum Patchen verwendet. Aus dem OCLP-Mode Changelog:

Ich finds so krass, wie Apple auf den letzten Metern Usern von Intel Systemen das Leben schwer machen und alles extra rauspatchen, um die Leute so dazu zu bewegen, zu Apple Silicon zu switchen. Das hätte man auch alles auf macOS 27 vertagen können…

Achso: da jetzt natürlich einige anfangen werden, nach Lösungen für Ihr Audio-Problem zu suchen, kann ich dazu sagen: diese funktioniert schonmal nicht:

https://github.com/hnanoto/SSDT-Audio-Universal/tree/main Kompletter Humbug, der da verzapft wird.

Der Dude ist auch verantwortlich für einen "neuen" Qurik in Clover genannt "AutoModernCPUQuirks". Das ist aber im Grunde nur ein Preset, dass die ganzen Quirks für Comet Lake plus die FakeCPU-ID aktiviert, damit man 11th Gen+ und AMD CPUs verwenden kann (die ganzen AMD Kernel Patches muss man trotzdem noch selbst hinzufügen)

Die Aussichten auf baldige neue Patches für OCLP schwinden derweil:

https://forums.macrumors.com/t…st=34428425#post-34428425

ST3R30 ,

> Die Aussichten auf baldige neue Patches für OCLP schwinden derweil:

Liest sich nicht gut, hatte auf eine Lösung für meine Haswell - und Ivy PC's gehofft.

Letzt endlich heißt das, daß bei den Ivy's bei Sequoia Schluß ist und das die Haswell PC's

nur noch mit den beiden RX 560 dGPU's laufen.

Auch mit den Hfs Treiber ist wieder mal so ein Ding, was man hätte auf macOS 27 verschieben können.

Wieso die Eile?

Mit Software dürfte das nicht passieren, daß man nicht darauf Aufmerksam gemacht wird, daß es sich

ausschließlich um Silicon Software handelt.

Mal abwarten, was noch alles kommt!

LG Franziska1993

Den Audio Patch kann man abwählen, dann fehlt natürlich AppleHDA - in diesem Zustand kann man aber ohne weitere Schritte VoodooHDA nach /L/E kopieren und gut.

AppleALC dient dann nur als “Blocker” für AppleGFX.

Sollte bei den meisten problemlos funktionieren - jedenfalls wäre das ein brauchbarer Workaround

Das HFS+ Thema ist natürlich eine Frechheit

Ich hab nochmal nachgeguckt:

• HFS+ ist noch da, aber disks im macOS Extended Format werden tatsächlich nicht automatisch eingehangen.
• Ich hatte zudem das Problem, dass ich Logic 12.0.1 bei der Installation aus dem App Store immer fehl schlug. Ich glaube, weil es die ARM Version war. Prüfen konnte ich es nicht. Nachdem ich Restrict Events deaktiviert habe, ging die Installation Problemlos. Ich denke, es lag an der VMM board-id, die RestrictEvents dem Download-Server weitergereicht hat.

Wieso wird immer sofort los gewettert? X.4 sind seit Jahren “Halbzeitmeilensteine”, wo nochmal gut im Unterbau rumgerührt wird (oft gerade im GPU-Bereich, Whatevergreen hat es manchmal gut abbekommen). Der HFS+-Bug kann alle möglichen Gründe haben, von Änderungen an einem Kernelinterface bis hin zu FSKit-Experimenten (würde mich nicht wundern, wenn HFS+ wie FAT32 als Legacy demnächst ins Userland verbannt wird). Gefühlt will man gerade zu vom bösen Apple unterdrückt werden, das sich nach der eigenen Hardware richtet und sich in einer Beta 1 moderate UX-Bugs erlaubt.

Für das Ärgern von Hackintoshern läuft es im Preboot erstaunlich stabil. Die letzte ärgerliche Änderung in OpenCore gab es in macOS 13.

Ich persönlich habe eher den Eindruck, dass die Verbannung ins Userland nichts mit technischen Gründen zu tun hat, sondern dass auf diese Weise unerwünschte Technologien aussortiert werden sollen, wie z. B. Netzwerktreiber für 3rd Party Hardware. Mit Sicherheit hat das jedenfalls nichts zu tun, da mit Tahoe ein Skywalk-Treiber für RTL812x (AppleEthernetRL) hinzugefügt wurde, der natürlich im Kernel läuft und darüber hinaus auch noch grottenschlecht programmiert wurde. Obwohl jeder, der schon mal einen Treiber programmiert hat, weiß, dass man bei der Initialisierung prüft, ob die vorhandene Hardware unterstützt wird und bei einem negativen Ergebnis der Prüfung die Initialisierung ordnungsgemäß abbricht, ohne eine KP zu fabrizieren, passiert genau das bei AppleEthernetRL, wenn in dem Rechner ein RTL8125/RTL8126 steckt, der nicht von Apple verbaut wurde. Das hatten die beim Aquantia-Treiber besser hinbekommen. Oder wollten sie es in diesem Fall garnicht besser machen, um der Hackintosh-Community Probleme zu bereiten? Dieser Eindruck drängt sich mir jedenfalls auf, weil es sich bei diesem "Bug" eigentlich nur um grobe Fahrlässigkeit oder Vorsatz handeln kann, es sei denn der AppleEthernetRL wurde maßgeblich von einer KI geschrieben?

Noch was zur Softwarequalität bei macOS: Mir ist bei meinen Tests aufgefallen, dass Netzwerkverkehr über IPv6 fast die doppelte CPU-Last im Kernel Task verursacht, als der gleiche Netzwerkverkehr über IPv4. Sowas lässt sich nicht mehr mit dem zusätzlichen Protokoll-Overhead gegenüber IPv4 erklären. Das ist schlechte Programmierung! Wer es nicht glaubt, der kann es gerne mit "iperf3-darwin" überprüfen.

OT

Mieze is it in your hand a rtl 8126 ethernet?

fabiosun Unfortunately no, because Amazon rescheduled the delivery date:

MacGrummel Ich nehme das nicht persönlich, aber schlechte Programmierung ist und bleibt schlechte Programmierung und es gibt keinen vernünftigen Grund hier Apple zu entschuldigen. Die behandeln den Bereich Netzwerk, von WLAN vielleicht abgesehen, schon seit über 10 Jahren, sehr nachlässig, so als ob es eine lästige Pflichtaufgabe wäre.

Hi liebes Forum,

Wieder mal eine Frage.......

Habe ja 2 Hacks am Laufen.......

Der Unterschied ist:

ASUS-Z390-F, 9600K und eine RX580

(statt ASUS-Z390-E, 9900K und Radeon VI)

verwende fast die selbe EFI.....ausser USB-Mapping, und andere CPU-Friend....

Leider hab ich am 9600K System ab und zu freezes....

Bin aber noch nicht dahinter gekommen was es ist.

Derzeit läuft auf allen Systemen Tahoe 26.3

Wie gesagt am 9900K wirklich perfekt, aber am 9600K immer wieder Freezes. Oft täglich, aber oft auch nur jedes Monat mal

Dank Euch

DerTschnig OpenCore Debug version installieren, Bootlog aktivieren dann analysieren. Das bringt meistens Hinweise. Mit dem LLM deiner Wahl – ich bevorzuge Claude– und den richtigen Prompts kommt man da ziemlich weit.

Mieze Das potentielle Verschieben eines antiquierten Dateisystems ins Userland kann mit Sicherheit nichts zu tun haben, weil es einen neuen Netzwerktreiber im Kernel gibt und die Entwickler ein bisschen rumgepfuscht haben. Ich kann langsam nicht mehr. Natürlich kommen ungeliebte Technologien ins Userland, gerade wegen des Sicherheitsaspekts - muss man sich weniger Mühe mit geben. Und die API bleibt stabil, während sie im Kernel flexibler werden kann. Und es steht ja nicht mal fest, ich habe doch nur geraten, warum es bzgl. HFS+ auf einmal Bugs geben könnte.

MacGrummel Mein Post ging doch in die komplett andere Richtung. Apple programmiert ausschließlich für die eigene Hardware und Apple hat im Detail nicht die höchsten Qualitätsstandards. Ist nichts Neues und erst recht nicht erst seit Apple silicon. Wie man daraus Jahr für Jahr eine persönliche Agenda der Führungsriege gegen ein fast schon bedeutungsloses Hobbyprojekt machen kann, entbehrt sich mir dieses Jahr zum Glück zum letzten Mal.

Bzgl. OpenCore gab es übrigens beidseitige Rücksichtnahme und Kompromisse. Man kann mir als jemandem, der direkte und indirekte Apple-Kontakte (ge)pflegt (hat) und die Interna diesbzgl. kennt einfach mal glauben - oder eben auch nicht. Dinge kritisieren ist doch ok, aber hier werden derart abwegige Schlüsse gezogen, dass das doch fast nur Ragebait sein kann.

mhaeuser Ich glaube Du verstehst nicht, was ich meine. Mangels verfügbarer Dokumentation habe ich mir mein Wissen über Netzwerktreiber für macOS im Wesentlichen durch Reverse Engineering von Apples Treibern für deren eigene Hardware angeeignet und was ich dabei gesehen habe, hat meine Meinung über Apples Softwarequalität nachhaltig und äußerst negativ geprägt.

PS: Die Probleme mit Netzwerktreibern betreffen nicht nur uns, sondern auch echte Macs mit 3rd-Party-Netzwerkkarten, die per Thunderbold angeschlossen sind und mit Apples Treibern laufen.

PS2: Ich gehe mal davon aus, dass Du meinen Post lediglich überflogen hast, denn bei genauem Lesen wäre Dir aufgefallen, dass ich das auch garnicht behauptet habe. Diese Aussage bezog sich ausschließlich auf die Netzwerktreiber im Userland.

Quote from mhaeuser

Mieze Das potentielle Verschieben eines antiquierten Dateisystems ins Userland kann mit Sicherheit nichts zu tun haben, weil es einen neuen Netzwerktreiber im Kernel gibt und die Entwickler ein bisschen rumgepfuscht haben.