FakeSMC in Ozmosis aktualisieren... die einfache Art...

Hab ich doch schon mal so ähnlich ohne English von Griven gelesen: http://hackintosh-forum.de/ind…&postID=149618#post149618
Nur dass Griven aus gutem Grund immer vor der zusätzlichen Installation von einem neuen, für das System zusätzlichen, FakeSMC warnt: Kann ne schöne Kernel-Panik geben..

Bei mir nicht ... alles gut und meine Lüfter sind endlich da

Oder man installiert das aktuelle HWSensors-Paket mit dem ganzen Inhalt einfach. So habe ich es bei meinen beiden iMac-Hacks gemacht und bis dato keine Probleme gehabt. Brauche dazu nicht im EFI-Ordner herum hantieren.

Die komplett Installation des HW Sensors Paketes hat bei mir zwar nie eine KP verursacht aber dafür ist der Rechner immer ca. 2-3 Minuten nach dem Boot abgeschmiert War bei jeder Version so, hab es dann aufgegeben. Werde mal den Tipp mit de aktuellen fakesmc versuchen.

@Higgings12: Wir haben ein identisches Mainboard, bei mir hat die Installation des aktuellen HWMonitors inklusive FakeSMC und den Sensoren geklappt, Abschmieren oder eine Kernelpanic blieb bis dato aus. Temperatur und Lüfterdrehzahl der GPU werden jedoch nicht ausgelesen!

Die Installation des kompletten Pakets nach /S/L/E ist im Kontext mit OZMOSIS ein ziemlich heikles Spiel das funktionieren kann aber in der Mehrzahl der Fälle nicht funktionieren wird. Begründet liegt das darin wie OZMOSIS das Thema KextInjections handhabt. Grundsätzlich gilt, dass OZMOSIS Extensions, die es vorfindet in der folgenden Reihenfolge in den KernelCache injiziert

und genau hier kann es insbesondere bei der FakeSMC und den Sensoren zu Konflikten kommen wenn die Extensions auch nach /S/L/E installiert werden. Hat man zum Beispiel eine aktuellere Version der FakeSMC nach /S/L/E installiert als die in der Firmware enthaltende wird OS-X immer die aktuellste Version aus dem Cache laden und die jeweils ältere ignorieren blöderweise weiß OZ das aber zu dem Zeitpunkt zu dem die Extensions in den Cache injiziert werden nicht bzw. verlässt sich darauf, dass OS-X automatisch die jeweils aktuellste Version wählt. Im Falle der reinen FakeSMC (ohne jegliche Plugins) funktioniert diese Strategie auch ohne weiteres scheitert jedoch schnell bei den Sensoren denn die gibt es in verschiedenen Branches mit komplett unterschiedlicher Versionsnummer und komplett unterschiedlichen Abhängigkeiten und so kann es passieren, dass OS-X versucht einen Mix aus all dem zu laden was zwangsläufig zu einer Kernelpanik führt denn zumeist werden eben nicht nur die Sensoren installiert, die bereits in der Firmware enthalten sind sondern darüber hinaus auch noch andere die dann nachgeladen werden sollen was scheitert. Der von AL beschriebene Weg über die EFI Partition ist demnach wohl doch der Beste. Hier mal ein Ausschnitt aus BDMESG der den Prozess der Kext Injection ein wenig verdeutlicht:

Ok, das leuchtet ein

Nachdem die FakeSMC von al6042 bei mir nicht zum Erfolg führte, probiere ich es einmal damit, die FakeSMC inkl. Sensoren, die HWMonitor nach /S/L/E installiert hat, in den Pfad auf der Efi-Partition zu verschieben. Vielleicht funktioniert der kext an dieser Stelle ja genauso!

Kann mir evtl. jemand kurz auf die Sprünge helfen, wie ich die Ozmosis EFI Partition mounte um die fakesmc darauf zu schieben? Such mir gerade einen wolf oder ich seh den Wald vor lauter Bäumen nicht.

Habe jetzt selber kein Ozmosis aber vielleicht hilft das:
http://hackintosh-forum.de/ind…ntryID=312#profileContent

Hallo,

muss leider meine Aussage von oben revidieren. Auf Grund der zahlreichen Installationen in letzter Zeit muss ich zugeben, dass ich was verwechselt habe. Ich habe das HWSensors-Paket unter Clover komplett installiert und dafür die FakeSMC aus dem EFI Ordner geschmissen. Bei meinen Ozmosis-Boards ist natürlich die FakeSMC drinnen und laufen damit auch alle Sensoren.
Sorry, dass ich da was falsches ins Spiel gebracht habe.

So gerade mal versucht. Haut bei mir leider nicht hin. Alles wie zuvor. Lediglich HDD + CPU werden bei mir angezeigt. Keine Lüfter und/oder GPU

Wie gesagt, auch bei mir leider nur die Standard Anzeigen. Festplatte, CPU, Trackpad Batterie.
Board: GA-Z97X-UD5H
1479er Ozmosis BIOS
Fakesmc.kext Kopiert nach /EFI/Oz/Darwin/Extensions/Common

Die fakesmc aus dem EFI scheint bei mir auch gar nicht geladen zu werden. Da die SMC Version im Kext Wizard immer noch mit 1290 angezeigt wird anstatt 1364

Ich reihe mich einmal ein:

Board: GA-Z97X-UD5H
Ozmosis 1479, Bios F9
FakeSMC + Sensoren aus dem HWMonitor 6.14.1364 in /S/L/E (laut KextWizard org.netkas.driver.FakeSMC 1364)
mit org.hwsensors.driver.CPUSensors 1364
org.hwsensors.driver.LPCSensors 1364
org.hwsensors.driver.ACPISensors 1364
aber _kein_ GPUSensors geladen!

Angezeigt wird:

/Verschieben der FakeSMC auf die Efi-Partition testweise steht noch aus.

boot into your windows installation, use google to find out how to mount an EFI partition, delete the sensors or add the corresponding FakeSMC and perform a NVRAM reset, .. (cmd-alt-p-r) ..

FakeSMC and its sensors always belong together, and they are to be seen as one package, .. so do not mix them up.

Übrigens, wenn auch in englisch trotzdem ein wichtiger Hinweis von h0belware bzgl. des NVRAM resets, danke hierfür

OZ hat die Angewohnheit Dinge, die schon im NVRAM stehen nicht mehr zu hinterfragen sprich alles was OZ sich einmal einverleibt hat bleibt auch da und wird nicht überschrieben. Von der Logik her sieht das im Falle der FakeSMC wie folgt aus:

- Check: FakeSMC in /EFI gefunden -> prüfen ist eine Instanz bereits auch schon im NVRAM vorhanden (nicht der Kext selbst nur der Hinweis darauf) dann ignorieren
- Check: Sensoren in /EFI gefunden -> prüfen schon vorhanden falls ja ignorieren, falls nein hinzufügen ( -> hier knallt es dann wenn FakeSMC aus der Firmware und Sensoren nicht passen)

Der NVRAM Reset lässt OZ all diese Dinge vergessen und zwingt es sich neu zu initialisieren. Im Prozess der Initialisierung wird dann den in /EFI liegenden Inhalten immer der Vorzug gegeben sprich es wird zuerst die EFI Partition untersucht (üblicherweise die erste verfügbare FAT32 Partition in Idealfall also die an SATA0 ist wichtig, wenn man mehr als ein LW im Rechner hat und OS-X nicht auf dem ersten Installiert ist) und alles was da gefunden wird übernommen. Mit alles ist wirklich alles gemeint was OZ da finden kann also neben dort abgelegten Extensions auch eine dort ggf. abgelegte Defaults.plist. Nachdem alle auf /EFI gefundenen Komponenten gefunden sind und registriert sind geht es mit den in der Firmware enthaltenen Dingen weiter. Alles was da noch schlummert aber noch nicht im NVRAM präsent ist wird von dort genommen. Sofern Euer Rechner den NVRAM permanent hält (ist eigentlich bei fast allen OZ1479 Firmwares der Fall) passiert dies genau einmal, nämlich beim initialisieren von OZ (HermitCrabs splash) und danach nur noch, wenn etwas neues hinzugekommen ist wobei neu wirklich namentlich neu meint und nicht neue Version.

ACHTUNG bedenkt bitte, dass ein NVRAM Reset auch die SMBIOS Settings und sämtliche anderen Settings die Ihr ggf. über das Terminal vorgenommen habt putzt sprich wenn es doof läuft und Ihr Euer SMBIOS sowie die Boot-args nicht fest in der defaults.plist verankert habt sondern über die Terminal Befehle ins NVRAM geschrieben habt ist das nach einem NVRAM reset alles weg und Ihr müsst es neu setzen (much trouble mit iCloud, iMessage, FaceTime und co sind vorprogrammiert). Am Besten lest Ihr vor einen NVRAM Reset all diese Werte aus und baut euch daraus eine defaults.plist die Ihr ebenfalls auf /EFI ablegt um dem zu entgehen.