Beiträge von Hausl

Zitat von al6042

Kannst du bitte noch mal den Inhalt des Ordners
/EFI/CLOVER/drivers64UEFI hier posten?
Eventuell ist da noch ein anderes EFI-File drinnen dass nicht rein müsste.

klar, hier bitte.

Hab vorhin mal einfach wieder den Befehl zum TRIM aktivieren ausgeführt, denn da scheint ja auch ein Cache erneuert zu werden, zumindest ist mir beim ersten mal aufgefallen, dass danach der Sound nicht mehr funktioniert hat, weil SIP auf 0x00 stand, und dann hat auch der normale OsxAptioFixDrv wieder funktiniert, daher sieht der Ordner nun so aus:

Zitat von al6042

@Hausl
Die .efi-Treiber werden im eigentlichen OSX nicht genutzt oder in den Kernel-Cache eingebunden, sondern nur beim Starten per Clover herangezogen.
Deswegen musst du an deiner OSX-Installation eigentlich nichts mehr anfassen.

Vielen Dank für die Info. Aber trotzdem muss es doch irgendwo haken, dass er mit dem normalen OsxAptioFixDrv den obigen Fehler ausgespuckt hat und erst mit dem 2er wieder booten konnte?

Ich habe wie gesagt unmittelbar davor mittles dem Terminalbefehl sudo kextcache -prelinked-kernel den Cache neu aufbauen wollen.

ok danke, dann werde ich es mal mit dem Wert 0x03 in Clover versuchen und sehen, wie es sich in Zukunft verhält.

Kann es durch die Kext Patches auch notwendig sein, dass man SIP für das Filesystem auch deaktivieren muss?

EDIT: au Backe, seh gerade, dass 0x03 eh für Kext + Filesystem steht, Kext allein wäre ja 0x11 gewesen. Ok Filesystem ist natürlich wohl der heikelste Punkt, der da nun ungeschützt ist, oder?

gibt es eine grundsätzliche Empfehlung, wie man die SIP einstellen sollte?

in meinem Fall ist es so, dass alle meine verwendeten Kexts in EFI/CLOVER/kextes/10.11 liegen.

Lediglich für den Sound und den USB 3.0 Ports habe ich ein paar Kext Patches in Clover (siehe Bild)

Im Grunde hat es auch schon funktioniert, dass ich die SIP wieder auf 0x00 einstelle, da ich ja mit dem Einrichten fertig bin. Doch letztens zB hatte im übers Terminal TRIM aktiviert, dann funktionierte nach dem Neustart der Sound nicht mehr. Vermutlich wurde der Cache neu erstellt und die Clover Patches konnten wegen dem aktivierten SIP nicht durchgeführt werden?!? Ok, dachte ich mir, das macht ,an ja nicht alle Tage. Also SIP auf 0x67, TRIM nochmals aktiviert, Neustart und Sound wieder da. Danach wieder auf 0x00 gestellt.

Nun hatte ich aber gröbere Probleme mit meinem Multiboot System (habe dazu extra nen Thread erstellt) und musste dabei öfters den Rechner vom Strom nehmen, da sich OSX nach Windows nicht mehr booten ließ. Ein paar Minuten ohne Strom, OS X bootete wieder normal und dann wieder kein Ton (SIP war auf 0x00). Wird dieser Cache nur temporär gespeichert und geht verloren ohne Strom?

Ups sorry, hier nochmal

EDIT: hatte nun das Glück, dass bei einem früheren Bootstick mit Clover der Treiber OsxAptioFix2Drv-64.efi installiert war anstatt dem normalen und mit dem konnte ich nun booten.

Hab dann im System EFI auch auf diesen Treiber umgestellt und läuft die Kiste wieder.

Aber muss da nun etwas bereinigt werden? Schließlich ist das System ja vor dem Cache neu aufbauen mit dem anderen Treiber normal gelaufen und ich als Laie sehe das nun eigentlich so, dass da nun unnötig Ballast irgendwo vorhanden sein muss.

image.jpeg

Habe es heute mal wieder versucht und hat dann wieder nicht geklappt. Ok, also hab ich mich geistig schon mal von Windows verabschiedet und wollte OS X wieder starten, nachdem ich die Kiste vom Strom genommen habe. Dann fiel mir auf, dass der Sound nicht ging. Hab dann gleich daran gedacht, dass ich ja SIP wieder auf 0x00 gestellt hatte und durch das Stromstecker ziehen eventuell die Audio Injection nicht mehr im Cache war?!? Hab dann wieder auf 0x67 gestellt und neu gestartet. Kein Sound. Hab dann einfach mal versucht, den Cache mit dem Befehl neu aufzubauen: sudo kextcache -prelinked-kernelNun kommt beim starten nur mehr folgender Screen Was bedeutet das nun für mich?

Ist das im Endeffekt nicht das gleiche, wie den Schnellstart in den Energieoptionen zu deaktivieren? Nur halt über die registry?

@derHackfan

ich muss ja BIOS nicht resetten, das dachte ich im ersten Post noch. Dann bin ich draufgekommen, dass schon ein einfaches vom Strom nehmen reicht, dass danach OS X wieder bootet. Von daher kann man eigentlich ausschließen, dass im BIOS etwas verstellt wurde.

@McRudolfowas meinst Du damit, welche Möglichkeiten ich ausprobiert habe? Also bisher habe ich nur den Schnellstart mal deaktiviert, sonst nichts. Dieser wird übrigens von Windows automatisch wieder aktiviert bei updates, zumindest bei dem großen Herbst Update

Nichts. Wenn ich den Rechner vom Strom nehme, dann startet ja OS X auch seltsamerweise wieder ganz normal. Als würde nach dem runterfahren von Windows irgendwas im Speicher bleiben, das OS X am Start hindert.

Hab das probiert mit dem Schnellstart in Windows zu deaktivieren. Hat mein Problem aus Post 1 nicht beheben können. Nach dem ausschalten und anschließendem Booten von OS X von Clover raus hängt der Boot wieder an der selben stelle wie oben.

mir ist aufgefallen, dass bei dem Vorgang die FakeSMC nicht geladen wird

oder kann die letzte Zeile vor dem Ntsf driver das Problem sein?

Habe SIP auf 0x00 gestellt falls das ne nützliche info ist

Danke @McRudolfo

hab in der Zwischenzeit genau den gleichen Tipp gefunden. Kann das dann morgen erst testen und berichten.

das wäre dann aber interessant, wieso das nur bei wenigen zu solchen Problemen führt. Immerhin nutzen ja viele dualboot Systeme, aber dass man das deaktivieren soll, wird eigentlich nie angeführt.

Und damit sollte beides möglich sein?

Per Terminal. Wie soll das denn per clover gehen?

Eventuell ist nach der Verwendung von Windows noch irgendwas im Speicher, dass dann den Start von OS X hindert?

Da es ja dann gleich wieder funktioniert, wenn man den Rechner vom Strom genommen hat.

EDIT: können etwas die NTSF erros ganz unten etwas mit dem Problem zu tun haben? Weiss jemand, was diese Errors bedeuten?

konnte ein paar mal das Betriebsystem wechseln mit Neustarts, das hat geklappt. Dann den Rechner mal von Windows aus ganz runtergefahren und dann beim Booten von OSX wieder das gleiche Bild wie oben.

Dann per Reset neu starten, von Clover aus OSX booten und dann kommen nur noch die ersten 2 Zeilen vom verbose mode, darunter die strichlierte Linie, und dann Stillstand (war so beim ersten mal auch schon)

Was ich aber gerade noch rausgefunden habe, dass ich gar nicht das BIOS zurücksetzen muss, sondern den Rechner einmal komplett vom Strom nehmen, dann bootet auch OSX wieder.

Also ich habe mit Bootflag -f nun keine neue Erkenntnis gewonnen.

Hi,

meine El Capitan Insatllation läuft mittlerweile perfekt und nun wollte ich das Thema Multiboot angehen.

Windows 10 ist auf einer extra SSD im UEFI Modus installiert. Die OSX Platte hängt an SATA0 und Windows Platte an SATA1.

Im Bios ist auch die UEFI Partion von OSX in der Bootreihenfolge ganz vorne. OSX starten geht ganz problemlos, einmal neustarten und dann Windows von der Win EFI Partition starten, alles Bestens. Aber dann kommt. Sobald ich Windows einmal gestartet hatte, reiht sich der Windows Bootloader im BIOS automatisch nach vorne und es startet wieder Windows. Ok, stell ich halt wieder um.

Dann komm ich ganz normal zum Clover Menü, starte OSX und dann kommt das

Ab da kann ich OSX nicht mehr booten, Abhilfe schafft nur das BIOS zurückzusetzen und die Windows Platte abzuklemmen.

Hat jemand ne Ahnung, was Windows da aufführt, dass danach OSX nicht mehr gebootet werden kann?

EDIT: Hab ja nach nach nem BIOS Reset OSX wieder booten können und hab den Text beim Booten im Zeitraffer aufgenommen und dann mit dem Foto des Screens verglichen, wo der Boot vorher stehengeblieben ist.

Da fällt mir nun auf, dass nach bei dem Fehlerscreen im Vergleich zum Video gar keine FakeSMC, die dazugehörigen Sensorkexte für HW Monitor, kein IntelMausiEthernet, usw.... ohne FakeSMC geht natürlich garnix. Jetzt stellt sich nur die Frage, WIESO diese kexte nicht geladen werden, wenn zuvor Windows lief.

Zur Info: mit dem AHCIPortInjector.kext wird TRIM deaktiviert.

Hab den kext daher wieder rausgeworfen, da ich die 2 ASMedia Sata Ports eh nicht verwende.

Ok, ich habe den kext in /EFI/CLOVER/kexts/10.11 abgelegt. Möchte das System weitgehend unverändert lassen, und so weiß ich dass alles nachträglich geänderte an einem Ort liegt.

Ok, und wenn der kext direkt ins System eingebunden ist, dann wird der auch in der Systeminfo angezeigt.

Also die von dir markierten Fixes hatte ich bisher definitiv nie aktiviert. Vielleicht hatte ich einfach nur Glück

Darf ich beim ALC1150 auch noch fragen, was du da in die DSDT integriert hast? Nur die Audio-Inject LayoutID 1 integriert oder noch was anderes? Denn die LayoutID 1 war meines Wissens schon drin, als ich die Datei hier gepostet hatte.

EDIT: habe jetzt nochmal testhalber den alten Ethernet kext eingesetzt, und die DSDT komplett entfernt. Die genannten Fixes sind nicht aktiviert gewesen und ich konnte nach dem Neustart die Stores ganz normal nutzen.

Zitat von al6042

Die Integration der Ethernet-Schnittstelle in der DSDT bezieht sich auf den Eintrag "BuiltIn" in den System Informationen:

Ist dieser Eintrag nicht gesetzt, gibt es Probleme bei der Nutzung vom App Store und iTunes.
In Clover gibt es dafür auch einen Fix:

Aber wie gesagt, ich habe das lieber zentral in der DSDT und muss mich dann nicht mehr um die Pflege kümmern.

Aah, ok. Super
Bei mir sieht das so aus, also von dem Kext sehe ich hier nix.

Kann es Probleme mit den Stores geben oder ist das dann fix? Denn ich konnte auch vorher den Store ganz normal nutzen, ok da hatte ich aber auch noch den AppleIntelE1000e.kext verwendet, falls das der Grund sein könnte.

@Boarder80 also meine GTX 770 läuft Out of the Box, die wird vom System automatisch erkannt, nur HDMI Audio ging nicht, da musste man nachhelfen. Ich denke, bei der 960 sind die Webtreiber notwendig.

Falls du auch den ALC1150 drin hast, den habe ich hiermit zum Laufen bekommen https://github.com/toleda/audio_CloverALC
Funktioniert echt perfekt, Soundqualität super und Frontaudio geht auch.

Danke für die Antwort

Dann werd ich die Patches lassen wie sie sind.

Wenn sie mit 10.12 was ändern an der AppleHDA, werden wohl sowieso beiden Methoden mit derzeitigen Stand versagen.

Darf ich noch fragen, was du damit gemeint hast, dass du Ethernet integriert hast? Meinst du damit etwas funktionelles oder nur, dass der Ethernet Controller in der Systeminfo nun mit richtigen Namen angezeigt wird?