Beiträge von donald451

Hey, das kam ja flott. Hier die Info:

Board revision: 1.0

BIOS: F12

Oz ist das von Sierra.

Bisher habe ich noch nichts verändert, weil ich erst mal sammeln und testen wollte. Dann fiel mir wieder ein, dass das Board ja ein zweites BIOS hat, damit müsste ich wohl beginnen (ich muss – je nach Dauer der Operation – mit Sierra weiter arbeiten können). Aktuell gibt es bei Gigabyte v. F8 bis F12.

Hallo, hat jemand das Z77X-UP5 TH Rev. 1.0 schon mit Mojave zum Laufen bekommen (die Suche findet nichts)? Im Prinzip ist mir egal, ob Oz, OC oder Clover zum Einsatz kommt. Wie soll ich am besten vorgehen? Ich versuche mal alles zu beschreiben, dann wisst ihr den aktuellen Stand (und worauf ihr euch ggf. einlasst). Der Rest wird dann - versprochen - knapper.

Meine Situation ist folgende: Arbeitsrechner wie links (plus einige weitere interne Platten), läuft mit einem ROM von griven (Z77XU5TH-F12-Sierra_iMac14_1.rom) und Ozmosis unter Sierra als iMac 14,1. Nun müsste ich auf Mojave umsteigen. Da meine letzten Basteleien 3 Jahre zurückliegen und ich auch nicht gerade tief in der Materie stecke, bräuchte ich wohl ein paar Schubse, um voranzukommen. Das habe ich bisher alles schon versucht:

Beim Versuch, Mojave von Sierra aus auf eine leere interne SSD zu installieren, hängte sich der Rechner nach dem ersten Reboot auf. Die normalerweise dort zurückgelassenen Installer-Files waren m.E. nicht ganz vollständig. War vermutlich mit dem alten Oz von vornherein zum Scheitern verurteilt.

Ich habe mir dann das Video von Titus Tech Tools zu OC angesehen und versucht es nachzuvollziehen, aber beim Installieren von SSDTTime bin ich in der Sackgase, da kein aktuelles python/homebrew/XCode mehr zu installieren ist und ich auch am Nutzen eines Linux Mint-Sticks scheitere. Er wird mir im Bootmenü nie angezeigt, ich vermute, auch da kommt ihm Ozmosis in die Quere. Und auch OpenCore Configurator läuft erst ab High Sierra.

Dann habe ich TINU mal angeworfen (obwohl ich schon einen Bootstick via Terminal erstellt hatte, aber gerne noch mal neu), was aber wiederum das aktuelle Clover-pkg nicht annimmt.

Nach drei Tagen des Lesens, Googlens und Scheiterns schon ganz zu Anfang, weiß ich nun wieder, warum ich nicht früher an ein weiteres Systemupdate gegangen bin.

Weil ich einsehe, nicht alleine weiterzukommen, stelle ich jetzt wieder mal einen Hilfsantrag inklusive Noob-Warnung. Mir ist klar, dass ich das BIOS flashen, Werte in plists eintragen muss und files auf die EFI-Partition kopiert werden müssen, das habe ich ja schon mal gemacht. Nicht klar ist mir die Reihenfolge der Arbeitsschritte, Bootprozesse, Abhängigkeiten, welche Tools in welcher Version am besten zu nutzen sind, woher ich jeweils die benötigten Infos nehme und ob meine alten .plist und .aml-files da weiter vonnutzen sind usw. Ich habe nicht viel Ahnung von vielen der Abkürzungen und Abläufe und bin sicher, dass ich etliches zwar aufgeschnappt, aber noch nicht verstanden habe, manche Zusammenhänge sind mir halbwegs klar, andere noch gar nicht. Ich bin aber kein Chaot und mache gerne step-by-step was gefragt ist. Falls also noch mal jemand bereit wäre, mich durch diesen Dschungel zu führen, bitte melden.

Die aktuell verwendeten kexts sind:

AppleALC-OZM.kext

AppleIntelE1000e.kext

FakeSMC_ACPISensors.kext

FakeSMC_CPUSensors.kext

FakeSMC_GPUSensors.kext

FakeSMC_LPCSensors.kext

FakeSMC.kext

IntelGraphicsFixup.kext

IntelMausiEthernet.kext

Lilu.kext Shiki.kext

USBInjectAll.kext

Zudem ist in S / L / E al6042s' Version der IntelFrameBufferCapri.kext aus diesem Thread installiert.

Bis auf HDMI, das sich trotz seiner Hilfe nicht stabil zum Funktionieren bewegen ließ, läuft Sierra gut, inkl. aller Apple-Dienste.

Im Anhang der Vollständigkeit halber mein Systemreport.zip (da ich gerade das schöne Kext Updater entdeckt habe) aus dem laufenden Ozmosis/Sierra-System.

Aufgefallen ist mir noch, dass in der defaults.plist in der Ansicht von Ozmosis Toolbox unter CSR-Active-Config ein Wert ausgelesen wird, der im Pop-up nicht enthalten ist (137) und dass dort für die ig-platform-id 0 ausgegeben wird. Aber nun geht es ja um Mojave.

Hallo und danke für deine Antwort. Der Prozess blieb nach dem ersten Neustart für die Neuinstallation stehen und anschließend landete ich dann gewaltsam im BIOS. Auf dem Zielvolume sind jetzt die ganzen Files abgelegt, die der installer braucht (InstallESD, BaseSystem, ApplleDiagnostics usw.).

Wahrscheinlich hast du Recht und ich habe mehr Glück, wenn ich es mal richtig herum angehe und erst einen OpenCore Bootstick erstelle. Möglicherweise ist das nicht sonderlich aktuelle Ozmosis gar nicht kompatibel mit dem mojave-Installer. Ich dachte, ich nehme vielleicht eine Abkürzung, aber da die Kiste sonst wieder läuft, ist für den Moment alles gut.

Der oben erwähnte Eintrag bei den Bootvolumes im BIOS stört mich noch. Weißt du, wie man den wegbekommt?

Hallo,

-----

Update: nach einem weiteren Versuch mit Boot Override komme ich wieder ins alte System. Puuuh. Und nach dem neu Setzen des Startvolumes über die Systemeinstellungen bootet er wieder wie gewohnt.

Jetzt bleibt zunächst nur die Frage: Wie bekomme ich die vom Mojave-Installer angelegte Partition wieder vom Rechner, die im BIOS auftaucht (Mac OS X HD o.s.ä.)?

-----

(Sorry, falls das jemand dann anschließend löschen möchte, ist das verständlich. Ich bin momentan noch nicht wieder so tief in der Materie drin, sodass ich hier wohl laut nachgedacht habe. Aber vielleicht hat es als Warnung für andere Dummies noch seinen Wert.)

-----

Ich habe versucht, Mojave regulär aus Sierra heraus (Ozmosis) auf einer leeren SSD zu installieren. Der Hinweis, dass das System mehrmals neu starten wird, hätte mich wohl gleich misstrauisch machen sollen. aber leider hatte ich nicht mit solchen Problemen gerechnet.

Der Status ist jetzt, dass nachdem der Installer nicht durchgebootet hat, ich auch nicht mehr in mein zuvor funktionierendes System booten kann. Der erste Boot hängte sich ziemlich früh (vor dem umschalten der Grafik auf HD) auf. Nach einem Neustart landete ich wegen fehlerhaftem Bootvorgang im BIOS. Von dort kann ich noch in die Recovery HD booten, booten vom alten System hängt immer und ich weiß gerade nicht, wie weiter.

Hat jemand Hinweise, was ich tun kann, um den Bootvorgang in mein altes System wiederherzustellen?

Bimmel: @al6042 | @griven

Nach langer Zeit noch mal ein Update:

Nachdem meine Frau in meiner Abwesenheit den Rechner kalt abgeschaltet hatte und ich ihn dann neu startete ging es! Aber genau nur ein mal. Ich hatte dann den Desktop wieder neu eingestellt (vom "Startmonitor" auf den, der jetzt wieder als einziger funktioniert) und die horizontale Anordnung des Desktops vertauscht. Nach dem Neustart wieder das alte Phänomen: erster Monitor wird nach der Hälfte des Bootvorgangs auf zweiten geschaltet und wird fortan nicht mehr erkannt.

Testweise habe ich auch die Monitorprefs des Users und des Systems gelöscht. Alles beim Alten.

Wo werden die Monitore denn sonst noch eingetragen? Kennt jemand eine Quelle, wo die Einträge für Monitore und zugehörige Einstellungen erläutert werden? Sonst eine Idee?

Hilft auch nicht außer, dass die Kiste jetzt wieder angenehm fluppt.

Ich habe vielleicht einen Hinweis auf das Problem gefunden, Apple schreibt zu Intel HD Graphics:

Zitat

Um die bestmögliche Grafikleistung zu erzielen, sollten im Computer zwei SO-DIMMs derselben Größe installiert sein, eines in jedem Steckplatz. Durch die paarweise Installation von Speichermodulen gleicher Kapazität kommt es zu einer leichten Leistungsverbesserung durch Speicher-Interleaving.

Achten Sie bei der Speicheraufrüstung Ihres Mac darauf, für eine optimale Grafikleistung in Speichergröße und -geschwindigkeit übereinstimmende SO-DIMM-Module in den Steckplätzen zu installieren.

Hat davon schon mal jemand was gehört? Da mir beim flashen des BIOS ein RAM-Modul als defekt angezeigt wurde, habe ich momentan nur noch eins installiert. Sobald ich wieder zwei habe, melde ich mich noch mal.

Okaaayyy, so doof ist also ein BIOS angelegt, dass es sich irgendeine EFI-Partition schnappt, nicht die des Bootvolumes. Danke für den Tipp, die DSDT wird geladen, die kexte teste ich morgen, aber das müsste dann ja auch gehen.

Update

Und die icloud-Accounts scheinen auch wieder zu laufen.
Das Glück war von kurzer Dauer, war wohl Zufall.

@griven Habe nun all diese Schritte unternommen:

- DSDT und folgende Extensions auf sämtliche EFI-Partitionen kopiert und aus S/E gelöscht:
AppleALC-OZM.kext
AppleIntelE1000e.kext
FakeSMC_ACPISensors.kext
FakeSMC_CPUSensors.kext
FakeSMC_GPUSensors.kext
FakeSMC_LPCSensors.kext
FakeSMC.kext
IntelGraphicsFixup.kext
IntelMausiEthernet.kext
Lilu.kext
Shiki.kext
USBInjectAll.kext

- @al6042s Version der IntelFrameBufferCapri.kext aus diesem Post installiert

An meinem (eigentlichen) Monitorproblem hat sich dadurch leider nichts geändert.

Hat noch jemand eine Idee? Ich kann auch gerne noch mal ein aktuelles Datenpaket zum aktuellen Stand zusammenstellen wie oben (Dateistruktur, ioreg, defaults etc.pp.)

Besten Dank, @al6042, offenbar werden nicht nur die kexte nicht geladen, unter PCI erscheint fröhlich das bekannte:

Zitat

In diesem Computer sind keine PCI-Karten oder -Geräte installiert. Wenn du eine PCI-Karte oder ein PCI-Gerät installiert oder angeschlossen hast, vergewissere dich, dass diese korrekt installiert sind.

al6042: "Da sollten ggf. mal @griven oder @Fredde2209 drauf schauen."

Dem würde ich mich gerne anschließen.

@al6042 Danke sehr, ich komme leider erst später dazu, sie zu testen.

Kurze Frage: Gibt es einen Weg um zu überprüfen, ob eine DSDT geladen wurde?

Hallo @al6042,

vom Clover Configurator habe ich meine SMBIOS-Werte würfeln lassen – oder wolltest du mich mit der Erwähnung auf etwas hinweisen? Falls ja, ist das bei mir leider nicht angekommen.

ich komme nicht weiter. Ich habe wie vorgeschlagen die kexte anhand deiner Aufzählung ergänzt und bis auf die INTEL1000 testweise wieder auf die EFI gepackt. Kein Ton mehr. Ozmosis lädt offenbar die kexte bei mir einfach nicht aus der EFI (dem richtigen Verzeichnis). Entweder ist da was faul oder ich kenne den heimlichen Befehl nicht, mit dem die kexte dort registriert werden. Kextutility läuft nach jeder Änderung an Extensions-Verzeichnissen vor dem Reboot.

Dann zunächst Shiki, Lilu und AppleALC-OZM wieder retour. Ton geht wieder, Grafik keine Änderung.

In weiteren Schritten habe ich auch die weiteren kexte nach L/E verschoben, vor allem weil ich nirgends einen Hinweis finde, wie ich kontrollieren kann, ob und welche kexte aus der EFI geladen werden. Im Ergebnis keine Änderung.

Dann habe ich testweise die defaults mit deinen Angaben zur AAPL/… ergänzt und ins NVRAM geladen. Keine Änderung.

(Auch mal wieder in L/Prefs/SysConfig die Networkinterfaces.plist und die preferences.plist gelöscht, aber Apple moppert weiter bezüglich der Apple-ID. Hier auch keine Änderung, muss wahrscheinlich noch mal auf sämtlichen Geräten durch die Authentifizierungshölle, bis es wieder geht.)

Könntest du bitte das Angebot mit der DSDT wahr machen? Ich verstehe nicht, warum eine Hardwarekombination, bei der eigentlich vieles OOB laufen sollte, mittlerweile derartige Probleme macht. Vielleicht hilft das ja. Im Anhang noch mal die aktuelle ioreg, falls sich dort etwas geändert haben sollte: iMac.ioreg.zip

Hallo @al6042,

ja, viel Text, entschuldige bitte, ich versuche es irgendwie zu komprimieren, erst mal zu deinen Fragen:

- das Chameleon-System ist mein altes, das ich via Dual-BIOS beim Sprung auf Ozmosis/Sierra als Backup benutzt habe, es liegt auf einer anderen Platte, die beiden Setups dürften sich also nicht in die Quere kommen.

- das "Clover-Gedöns" will ich nicht nutzen, das habe ich nur als Informationsquelle bei der Recherche nach AAPL,ig-platform-ids für die HD 4000 gefunden und dachte, daraus ergäben sich vielleicht Hinweise auf eine Lösung des Problems, weil viele daran herumdoktern, wenns bei der Grafik hakt - und dort geht es auch um mein Mainboard.

Damit ich sicher bin, dich richtig zu verstehen:
Das reine Öffnen einer DSDT mit dem falschen Tool – selbst ohne explizites Speichern – kann die Datei korrumpieren?

Zum aktuellen Stand:

Kexte, die ich auf der EFI ablege, werden nicht oder nicht alle geladen, aber aus L/E, was ich in der Hoffnung bevorzuge, dass Apple dort "fremde" kexte in Ruhe lässt. Ich habe sie nur als Gesamtpaket getestet, weil Apple seit dem Umkopieren auf die EFI wieder meine ID anzweifelt und der Sound nicht mehr ging.

Das Ozmosis, das ich verwendet habe, ist dieses: Mod für das Z77X-UP5TH Rev.1.x Version F11
Im BIOS werden folgende Werte angezeigt: Version F12, BIOS-ID 8A11AG06, besteht schon hier Konflikt?

Im BIOS-Mod ist 01 00 66 01 als AAPL,ig-platform-id eingetragen.

In der DSDT ist AAPL,ig-platform-id hingegen 0a 00 66 01. Ich hatte auch mal - ahnungslos - mit einem Eintrag in der defaults.plist gespielt, diesen jetzt auch wieder gelöscht.

Verständnisfrage: "AAPL,ig-platform-id" kann sowohl im Ozmosis-BIOS, als auch in der DSDT, als auch in der defaults.plist eingetragen werden? Stören sich diese Einträge oder überschreiben sie sich - und welcher Eintrag hat Priorität?

Die AppleIntelFramebufferCapri.kext von dir habe ich zunächst wieder durch das Backup ersetzt, da ich da aber auch schon Patches eingespielt hatte (s.o.), sollte vielleicht auch die sicherheitshalber noch mal geklärt werden?

Ich hänge jetzt noch mal alle Dateien und Screenshots in der aktuellen Version an, damit wir beide auf demselben Stand sind, in der Hoffnung, dass das irgendwie aufgedröselt werden kann. Falls es nützlich wäre, liefere ich auch gerne noch Fotos vom BIOS.

Oz 2017-06-18-20-00.zip

Sorry, vergessen: ioreg.zip

Zuletzt: Wie dokumentiert ihr eigentlich eure Experimente, haben sich da best practices herauskristallisiert? Ich stelle nämlich immer wieder fest, dass ich bei der Komplexität und meiner beschränkten Übersicht immer wieder an den Punkt komme, dass ich nach ein paar Tagen nicht mehr zweifelsfrei nachvollziehen kann, was ich wann, wo und warum gemacht habe.

Danke, dass du das mit mir durchstehst. Solange ich arbeiten kann, ist es ok, aber der Zweitmonitor hochkant fehlt mir schon sehr. Ich will endlich anständige Monitortapeten oder brauchbare AR-Tools, die ich im Raum verteilen kann, das ist doch so kein Zustand

Danke @al6042, das ist wirklich ein sehr nettes Angebot, aber vielleicht ist es gar nicht nötig, denn ich habe noch etwas bemerkt:

Wenn ich die DSDT.aml öffne, spuckt Chameleon Wizard folgende Fehlermeldungen aus:

Im logfile steht nur:

Irgendwas scheint da doch faul zu sein. MaciASL öffnet die Datei nicht, gibt nicht mal irgendein Feedback. Dasselbe passiert, wenn ich meine DSDT von hier wieder herunterlade, MaciASL öffnet sie nicht, Chameleon Wizard moppert.

Verstehe ich die Tools falsch oder stimmt wirklich etwas mit der Datei nicht?

Ich begreife die Tools und das Thema DSDT leider viel zu wenig, und noch weniger all die verstreuten Infos, die Autoren stehen offenbar auf den Schultern von Riesen, denen ich noch nie begegnet bin (von dir/euch wahrscheinlich abgesehen ).

Für den Fall, dass das hilfreich sein könnte, habe ich die von MaciASL aus dem laufenden System ausgelesene Datei angehängt. Vielleicht könntest du da noch mal einen Blick draufwerfen? MaciASL generated System DSDT.aml

//
P.S. Eine Ressource, die ich noch aufgetan habe, ist eine speziell für diese Reihe von GA-Mobos angepasste Clover-Distribution (nicht, dass ich wieder von 0 anfangen wollte, aber es gibt Quellcode und ein sehr übersichtliches Wiki.) Dort gibt es auch eine "minimale" ASL für mein Board.

P.P.S. DIe Einträge zur Grafik im Bootlog hat folgende Einträge:

Letzteres dürfte der Auflösung entsprechen, die der Bootscreen in der ersten Phase des Bootens hat, wird dann verzerrt. Die ig-platform-id entspricht angeblich einem mobilen Gerät, bei Clover wird für Desktops 01 66 00 0A genutzt und hier wird darauf hingewiesen, dass der im BIOS angegebene Speicher dann noch an die Konfiguration angepasst werden muss, er sagt aber auch, mobile oder desktop sei egal. In diesem post hattest du für die HD 4000 mal 01 66 00 09 empfohlen.

Vielleicht könnte das zumindest Teil der Fehler sein, je mehr ich google, desto breiter wird das Feld, und es ist spät …

Danke sehr @al6042, hab's gerade getestet, der senkrechte schmale Streifen der beim Switch des Monitors im rechten Viertel war, blitzt nun in blau eher mittig auf, der Rest ist dasselbe: Bootmonitor wird ausgeschaltet.

Bin praktisch bildbar:

Ok, das wäre erledigt. Ich werde mich wohl erst später am Abend noch mal melden können. Was benötigst du bzgl. der AppleIntelFramebufferCapri?

Hier sind sie:

Danke dir sehr, ich hatte fast das Gefühl, ich hätte irgendwas dummes gepostet, kein Thema.

Leider bringt auch das keine Änderung mit sich, ich habe die Befehle ausgeführt, aber es scheint sich nach dem reboot rein gar nichts getan zu haben.

Danke, wieder was gelernt.

Weil dazu nicht nur hier immer wieder unterschiedliche Beispiele zu finden sind:

Müssen die Dateien nun defaults.plist oder Defaults.plist und DSDT.aml oder dsdt.aml benannt sein?