Beiträge von Crom

Genau wegen Brumbaers Anleitung habe ich ja gefragt.

Nur mal so gefragt: kann man nicht den Namen der EFI-Partition ändern?

Prinzipiell würde ich gerne ohne Portforwarding auskommen. Da bleibt dann ja nur ein Broker wie Apple mit iCloud oder eben so was wie TeamViewer. Ich teste das mal die Tage mit ihr zusammen.

Hallo liebe Forianer,

mein Hackintosh (Gurke) wird die nächsten Tage ausziehen und sein hoffentlich noch langes Leben bei meiner Tochter verbringen. Wie kann ich denn trotzdem meine schützende Hand über das gute Stück halten?

Ich habe jetzt mal im lokalen Netz versucht, den Rechner zu erreichen. Was ich bisher gemacht habe:

• Auf Gurke: Systemeinstellungen - iCloud -> Zugang zu meinem Mac (aktiviert)
• Auf meinem iMac: Finder - Gurke -> Bildschirmfreigabe

Das Ergebnis ist soweit ganz gut. Ich kann auf Gurke dann ab dem Login-Screen alles machen, als wäre ich vor Ort. Jetzt zu meiner Frage:

Geht dass dann auch über Internet, wenn Gurke dann in einem anderen lokalen Netz (bei meiner Tochter) hängt?
Oder muss ich auf so unschöne Alternativen (siehe aktuelle Nachrichten) wie TeamViewer ausweichen?

BTW: ich habe bemerkt, dass nicht nach jedem Start die Gurke von meinem iMac aus zu sehen / erreichen ist. Ist das ein bekanntes Problem oder habe ich hier einen privaten Bug gefunden?

Bleibt nur die Frage, wie man da eine WiFi-Karte reinbekommt ...

Auf Github ist übrigens ein Fork von MaciASL seitens RehabMan zu finden. Abweichung zum Original sind minimal, es gibt aber eine command line Version 'patchmatic' von ihm. Hat das schon mal jemand verwendet?

Ok Leute, manchmal sieht man ja den Wald vor lauter Bäumen nicht mehr. Das war hier bei mir offenbar der Fall ... Aber der Reihe nach:

Ich boot meinen Hacki mit Clover. Die originale DSDT kann man sich da ja wunderbar mit einem beherzten Druck auf F4 nach EFI/CLOVER/ACPI/origin sichern lassen. Das gute Stück hat mir dann wie gesagt @al6042 netterweise schon vorher für meine WLAN-Karte angepasst.

Jetzt wollte ich die restlichen Fixes, welche ich per Clover aktiviert habe ja loswerden. (siehe 1. Post in diesem Thread). @rubenszy war so gut mir ein mundgerechtes Paket zu schnüren. Leider habe ich es nicht hinbekommen, die patches so anzuwenden, dass eine vernünftige DSDT rausgekommen ist.

Nach nunmehr einigen Tage der Suche hier und in anderen Foren, einer kleinen Lernaktivität, wie das ganze patchen genau funktioniert, wo ich die originalen Source der patches finde und dann diversen, unfruchtbaren weiteren Versuchen habe ich mich einfach mal wieder an Clover erinnert und die Nutzung der F5-Taste. Also, alle für mein Board relevanten fixes werden damit analog zu F4 an den obigen Ort verfrachtet und bekommen einen schönen Namen ala DSDT-<FIX-Maske>.aml.

Der restliche Weg war dann nicht mehr lang: das File in MaciASL geladen, Compile drüber gejagt, die Warning für die _WAK-Methode gesehen, den richtigen patch rausgesucht und angewendet, speichern unter dem richtigen Namen nach EFI/CLOVER/ACPI/patched und noch alle fixes aus der config.plist entfernt.

Reboot und es tut

Meine Gurke hat das Update auch soweit erfolgreich genossen. Keine Vorbereitungen oder Nacharbeiten nötig ...

Merci,
das löschen der beiden fies hat schon mal die gewünschte Benennung der Interfaces erzielt. Mir macht derzeit mehr Sorge, dass ich bei jedem booten die BIOS-Einstellungen neu machen muss. Wird doch nicht etwa die CMOS-Batterie den Geist aufgeben ...

Danke @rubenszy,

ich habe die Patches mal mit MaciASL in meine DSDT eingebaut und dann auch über Compiler kein Fehler angezeigt bekommen. Allerdings habe ich wohl irgendwas falsch gemacht.

Mein Vorgehen danach:

• DSDT.aml nach EFI/CLOVER/ACPI/patched kopiert
• In config.plist alle gepaschten fixes deaktiviert
• Reboot

Der Rechner startet hoch. Allerdings funktioniert Sound nicht. Dabei bemerke ich, dass alles sehr langsame vonstatten geht. Also Reblot und ab ins BIOS. Dort waren dann irgendwie ein paar Defaults zerschossen. U.A. AHCI deaktiviert.

Ich habe das ganze jetzt erstmal wieder rückgängig gemacht ...

Hallo zusammen,

nach meiner Vorstellung und ersten Erfolgen beim Anpassen meiner Gurke bin ich nun auf dem Trip möglichst viele der Clover Fixes obsolet zu machen und eine optimale DSDT zu erstellen.

Dazu vorab ein paar Infos:

• Unter obigem Link findet mal meine als Anhang im Beitrag meine aktuelle config.plist und etwas weiter unten die von @al6042 freundlicherweise schon für WLAN angepasste DSDT.
• Außer den fixes in der config.plist habe ich über Clover den FaxeSMC.kext geladen und RealtekRTL8111.kext in S/L/E installiert
• Nach meiner Einschätzung funktioniert damit alles soweit fehlerfrei. Allerdings gibt es zwei Unschönheiten / Probleme, die noch über sind:

• Meine Netzwerkkarte wird hinter WLAN (en0) als en2 eingebunden (hängt wohl mit der bereits gepaschten DSDT zusammen, oder?)
• Ein paar Meldungen im system.log zu Unsupported ioctl 156, 181, 230 (m.E. bug im Treiber von OSX)

Wo stehe ich nun? Im Wald mit vollen Hosen

Die FAQ habe ich gelesen, bin nun aber wirklich nicht sicher, wo ich die richtigen Patches für mein Board herbekomme (weil schon etwas älter) und wie ich die richtig anwende und dann erprobe. Mag mir da jemand einen Schubs in die richtige Richtung geben?

@al6042 und @YogiBear: Euch vielen lieben Dank für die Unterstützung bei meinen ersten Schritten

Weiter geht die Tour mit WLAN und einen erneuten Fortschritt gibt es auch.

Der "Atheros Locale Fix" von oben fixed ja nicht mein Problem, sondern die Fehlermeldung ATHR: unknown locale: 21.

Um nun die Fehlermeldung ATHR: unknown locale: 809c zu fixen, gibt es bereits einen config.plist patch zu finden auf insanelymac.com:

Faktisch wird also der HEX-String 0FB787DC040000 (BASE64: D7eH3AQAAA==) durch B8640000009090 (BASE64: uGQAAACQkA==) ersetzt. Die 64 in letzterem HEX-String ist nix anderes als die regulatory domain WOR4_WORLD für den amerikanischen Raum und definiert damit die locale: FCC. Nachlesen kann man das gut bei linuxwireless.org.

Und da wir hier in Europa sind, kann man an der Stelle auch z.B. die regulatory pair group 37 wählen. raus kommt dann die locale: ETSI und der patch sieht dann also so aus:

Ich hoffe, dass hilft mal jemandem. Mir hat es zumindest Ruhe im wifi-log, eine bisher stabile WLAN-Verbindung und eine vernünftige locale für WLAN im Systembericht gebracht.

Hallo nochmal,
eigentlich wollte ich erst morgen weiter machen. Aber die Neugier ..

Ich habe die DSDT nun in Benutzung. Vielen Dank dafür erstmal.

• Die Änderungen zu vorher sind zumindest erkennbar. Im Systembericht redet der Hacki jetzt von den richtigen IDs:
  Vendor, Device, SubVendor, SubDevice: 168C, 002E, 168C, 30A4
• Im IORegistryExplorer unter der Section IO80211Plane -> AirPort_ArtherosNewma40 lese ich jetzt pci168c,30. Alles also so, wie es der patch für die DSDT erwarten lies
• Status: WLAN geht, aber:
  Local stimmt immer noch nicht (Screenshot: Systembericht2),
  Fehler im system.log über ATHR: unknown lokale 809C
• Die gelegentlichen Verbindungsabbrüche muss ich noch abwarten

Ich schließe mich der Wünschelrunde mal und und sage: Alles liebe zum Ehrentag

Sehr hübsches Bild. Aber noch wichtiger: was ist in der Flasche und kann man das trinken?

Da komme ich doch gerne gleich drauf zurück. In der Zwischenzeit hat sich ein Erkenntnisgewinn eingestellt den ich erstmal verprobe.

Ich habe nochmal von vorn bzgl. des KextsToPatch den Boot-Prozess mit allen Debug-Optionen durchlaufen lassen:

Der Fehler an dieser Stelle war, dass im aktuellen Clover Configurator am Ende der Zeile noch von STRING auf DATA umgestellt werden kann. Die Version im Video hatte diese Einstellung aber gar nicht Nun steht im debug.log

Im Ergebnis kann ich nun mit Hilfe des IORegistryExplorer unter der Section IO80211Plane -> AirPort_ArtherosNewma40 den hübschen Eintrag pci168c,2e lesen. Vorher stand da natürlich der falsche pci168c,2a drin (Siehe Screenshot)

Ein Schritt in die richtige Richtung Jetzt warte ich mal ab, ob sich was verändert hat ...

EDIT und Update:

• Status: WLAN geht, Fehler im Log bestehen noch, Systembericht ist unverändert wie im Screenshot auf der vorigen Seite. Die Stabilität der Verbindung scheint mir jetzt etwas besser, aber ob es gut ist, dass kann ich noch nicht wirklich sagen.

Und im Anhang habe ich jetzt mal alles aus dem origin-Ordner verpackt. Zusätzlich dazu noch die aktuelle config.plist, damit man sich dazu mal ein Bild machen kann.

Feierabend und weiter geht es

Ich versuche es nochmal vollständig zu beschreiben, wo ich gerade stehe:

• die verbaute Karte TL-WN881ND (AR9287) hat original und ohne Patches die folgenden IDs:
  Vendor, Device, SubVendor, SubDevice: 168C, 002E, 168C, 30A4
• Status: WLAN geht nicht
• in config.plist habe ich dann u.a. folgende Fixes aktiviert:
  AddDTGP_0001, FixAirport_4000, ..
• danach meldet DPCIManager die folgenden IDs:
  Vendor, Device, SubVendor, SubDevice: 168C, 002E, 1068, 008F (Screenshot: PCI List)
• Status: WLAN geht, aber:
  Local stimmt nicht (Screenshot: Systembericht),
  Fehler im system.log über ATHR: unknown lokale 809C,
  gelegentlich Verbindungsabbrüche, die durch deaktivieren/aktivieren geheilt werden

Wenn ich es richtig verstehe, so ist damit gemäß der Anleitung von toleda die Karte trotzdem prinzipiell betriebsbereit. Sie hat aber noch die oben beschriebene Probleme.

• Der nächste Schritt war, KextsToPatch nach dem verlinkten Video zu erproben.
• Status: WLAN geht nicht

Also wieder zurück zur vorherigen Methode

• Den oben vorgeschlagenen Patch zum umschießen der locale habe ich nunmehr auch getestet und damit keine Änderungen festgestellt
• Status: WLAN funktioniert mit den oben angemerkten Fehlern

Danach hatte ich gemäß Clover-Wiki verstanden, dass ich die nunmehr erkannte WIFI-Karte auf eine nativ unterstütze Variante per FakeID umschießen kann. Hier bin ich mir aber nicht so sicher ...

• Zumindest habe ich mal testweise 0x002A168C eingetragen. Das hat aber keine Änderung gebracht.
• Status: WLAN funktioniert mit den oben angemerkten Fehlern

Alternativ kann ich auch das kext oder DSDT patchen. kext würde ich aber gerne wegen Systemupdates vermeiden.

"Was nun?", sprach Zeus, äh Crom, also ich

Hallo @al6042,

ich habe das mal nach dem Video umgesetzt, sehe aber bisher noch keinen Unterschied. Wie kann ich den Erfolg denn nun prüfen, außer zu warten, ob die Verbindung wieder abbricht?

Zumindest im system.log sind die Meldungen über das unknown lokale 809c nicht verschwunden und auch im Systembericht scheint sich nichts verändert zu haben. Insbesondere ist die Karte noch immer mit Länderkennung: CN und Locale: Unknown drin ...

Hier ist der Screenshot und dazu der m.E. passende Ausschnitt aus dem Systembericht