Naja, das ist jetzt beides nicht wirklich so vorgesehen 
Du solltest mal herausfinden ob du jetzt gerade APFS oder HFS oder einen MischMasch nutzt 
Außerdem wäre interessant zu wissen, ob der BootEintrag einen NVRam reset überlebt 
Update bzw. Neubau OzmosisBios
-
- Erledigt
- crazycreator
- Erledigt
-
-
Was ist beides nicht so vorgesehen? Den kext in Ozmosis zu nutzen, den Terminalbefehl zu nutzen oder die Installation durch löschen des Ordners anzuhalten?
Wie finde ich das heraus was du wissen willst?
Hier der aktuelle bcfg boot dump
bootdumpwith-hs.txt@NVRAM Reset
Mhhhh ... Du willst das ich schweißnasse Hände bekomme, weil ich ja nicht weiss wie ich es hinbekommen habe das es drinnen steht.Was mir aufgefallen ist: Im bcfg boot dump steht eine andere UUID als im Clover Configurator zu sehen ist. Die die im Clover Configurator angezeigt wird, ist auch die die ich per Terminal diskutil list info bekommen habe.
Die einzige Ähnlichkeit:
ClCo = 72411890-C628-31F5-8E47-3D93FD7C672D
bcfg =
08. PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x2,0x0)/HD(2,GPT,27029f0d-f6ed-4eb4-845f-77bf3622ce4e,0x64028,0xee12e10)/VenMedia(be74fcf7-0b7c-49f3-9147-01f4042e6842,9018417228c6f5318e473d93fd7c672d)/\System\Library\CoreServices\boot.efi "HS" -
Naja ich hoffe mal du hast keine Daten zu verlieren...
Die Kext kannst du schon mit Ozm nutzen, aber ich würde sagen entweder Terminal oder Kext.
Zudem sind beide Wege für eine Neuinstallation gedacht, nicht als nachträgliche Therapie bei einem APFS SystemEin Ozm System zu haben, bei dem ein NVRam reset zu völliger Zerstörung führt (kann ja auch mal nach einen CMOS reset sein), ist nicht wirklich erstrebenswert. Wenn der BootEintrag nach einem Reset noch da ist, ist ja alles super. Wenn nicht würde ich dir raten nochmal ganz normal neu zu installieren aber vor der Installation den Unsolid.kext in die EFI zu legen. Nach der Installation kannst du ihn wieder löschen.
Oder mit APFS und Clover zu installieren.
-
So ... Ich habe es getan
und habe nochmal NVRAM-Reset gemacht.Ergebnis: Die HS-Platte ist noch zu sehen, aber die Sierra-Platte (10.12.3) war nicht mehr zu sehen
Habe die Recovery gestartet -> Sierra als Startvolume ausgewählt -> Komplett hochfahren lassen -> Login -> Restart -> BIOS ->
Freuen, denn der Sierra Eintrag war wieder da.Also scheinbar liegt es wirklich an dem Kext in der EFI, oder der Ausführung des Terminalbefehls *Schulterzuck* ... Aber ich habe ja keine Ahnung.
Ich lebe nach dem Prinzip Try and ErrorAber ich habe da nochmal eine eher komische Frage, zwecks dem kext und der EFI in die ich ihn lege.
Woher weiss ich in welche EFI ich die kexte lege, denn irgendwie sind die Platten ja nach jedem Neustart anders eingebunden.
Das an sich ist ja auch bekannt, aber wie finde ich jetzt raus wohin ich den kext nun amtlicherweise lege.
Aktuell habe ich ihn nämlich den Kext in zwei EFI's liegen, einfach weil ich mir nicht sicher war, welche nun die erste ist. -
Im Terminal mit diskutil list arbeiten verschafft Gewissheit.
-
Das ist schon klar, ich schaue vorher immer mit diskutil list, aaaaaaaber ... Ich habe 4 Festplatten, auf einer sind nur Daten und auf den anderen Sierra, Sierra Beta und HighSierra
Wenn ich jetzt per diskutil list reinschaue dann ist meinetwegen die Sierra die disk0 und ich schmeiße meine Dateien auf diese EFI.
Beim nächsten Start ist dann aber die Sierra Beta Platte als disk0 eingebunden. Womit dann ja, zumindest theoretisch laut diskutil die
Daten auf der "falschen" EFI liegen. Ich hoffe ich konnte einigermaßen erklären wie ich das meine -
Was ist das denn für ein zickiges Verhalten, gehört habe ich das schon mal aber noch nie erlebt, Frechheit.
Edit: Ich würde für das Feintuning die anderen Platten temporär abziehen, dann bleibt ja nur noch eine EFI übrig.
-
Lege die Dateien immer in der EFI der Start-Festplatte, bzw. der Platte auf die gestartete Partition liegt.
Solltest du jetzt noch Ozmosis nutzen, habe den Faden über die Zeit verloren, dann sollte die Platte, welche am SATA-0-Port auf dem Mainboard sitzt, mit den Dateien in der EFI ausgestattet werden...
Solltest du mehrere EFIs haben, lösche bei den anderen den EFI-Ordner, damit die Bootloader auf Dauer nicht durcheinander kommen.Das die die Disk-Identifier sich von Start zu Start ändern, ist seit Ewigkeiten kein Geheimnis mehr.
-
Schau mal hier unter Punkt vier: https://www.hackintosh-forum.d….php/FAQ/180-EFI-mounten/
Auch Tags können bei sowas helfen.
-
-
So ist es.... Die Platte wird nur als disk0 angezeigt, wenn sie alleine im System ist, ansonsten wechselt das gerne lustig vor sich hin.
-
@kuckkuck Danke, wieder was gelernt
die Bezeichnungen bleiben nach einem unmount und neuem Mount aber erhalten?Jetzt da endlich der Eintrag für meine HighSierra im BIOS erscheint, können wir also wieder da anfangen bzw. weiter machen wo wir vor 2 Tagen aufgehört haben
Wer mag sich mal meine DSDT anschauen und mir sagen was da wie getan werden muss?
-
Was heißt schon "getan werden muss"
Die DSDT an sich ist super, die Frage ist da eher ob du irgendwelche Bugs oder Probleme hast... Ansonsten kann man ein paar Renames reinmachen und das ein oder andere Device und _DSM Methode für einzelne Geräte wie SATA, HDEF, HDAU, GFX0, etc. hinzufügen.Das hier solltest du dir auch nochmal durch den Kopf gehen lassen: Da du ein sehr geräumiges Z77 ROM hast, würde der ACPIPatcher da super Platz finden
Wenn du die DSDT im BIOS mit einer MacOS DSDT austauschst, manipulierst du so auch automatisch die DSDT, die zB Win oder Linux laden würde... Es ist schlauer die ihr eigenes Ding machen zu lassen und die DSDT entweder über die EFI zu laden oder NOCH BESSER mit ACPIPatcher und SSDTs (oder DSDT) zu arbeiten. Bei letzterer Lösung umgeht man alle möglichen ACPIErrors und lässt alles schön Vanilla. ACPIPatcher macht nur Renames, die SSDTs fügen beim Laden von OS X die nötigen Patches hinzu, nicht aber beim starten von Win o.ä.
-
Also mal abgesehen davon das diese Kiste hier in ihrem langen leben noch nie was anderes als Mac OS gesehen hat, klingt die Geschichte mit diesem ACPIPatcher sehr interessant. Nur habe ich davon noch nie was gehört, ich bin froh das ich die DSDT fehlerfrei aus der AmiBoardInfo holen kann
Was müsste denn für oder mit diesem ACPIPatcher so ungefähr getan werden?
@Probleme/Bugs
Ich habe Probleme mit meinen USB3 Port's, die erkennen nicht immer alle Sticks und auch der Power an diesen scheint nicht wirklich ok zu sein.
Des weiteren sollte noch der Sound gepatcht werden, damit ich auch mal das 2.1 System anschließen kann
UND
Was machen wir mit der Disco meiner ATI Radeon 5770 ... gibt es einen anderen Weg als mit SwitchResX? -
Die Unterstützung der AMD HD 5000 Serie ist leider nicht besser geworden, entweder eine neue (gebrauchte) Grafikkarte, HD 6000, HD 7000 Serie oder die Intel HD-Grafik 4000 von deinem Intel Core i5-3570K verwenden.
-
Angehängte Datei müsste dann ins BIOS... Im nächsten Schritt musst du dann eine AcpiPatcher.plist erstellen, welche die für dein System/deine DSDT nötigen Patches beschreibt, die Patches aktivieren und im Nachgang überprüfen ob sie zuverlässig durchgeführt werden.
Funktionieren die Renames zuverlässig, checkt man nach ACPIErrors, aber da die der Patcher nicht nur Renames in der DSDT, sondern in allen ACPI Tabellen vornimmt, entstehen im Gegensatz zum bloßen Patchen der DSDT praktisch nie ACPI Errors.War das alles erfolgreich, kann man sich daran machen SSDTs mit den für die verbauten Geräten nötigen _DSM Einträgen zu erstellen. Außerdem SSDTs, die Fake-Devices hinzufügen, damit bestimmte AppleTreiber laden. Dazu gehört beispielsweise das Gerät ALS0 (AmbientLight Sensor), das häufig bei Sleep hilft oder das Device EC (Embedded Controller) das dafür sorgt, dann alle USB Ports ihren benötigten Strom bekommen. Der Sound lässt sich durch den passenden _DSM Eintrag über eine SSDT fixen. Zu der GPU kann ich nichts sagen, habe mich noch nie mit dem Thema befasst.
Letztendlich hat man dann verschiedenste SSDTs (die man auch zu einer großen zusammenfassen kann) und das sieht dann zB so aus: -
Bewusst eine 100%ige DSDT zu erstellen und wirklich zu wissen was da wo passiert, ist mindestens genauso komplex wie das Vorgehen mit ACPIPatcher...
Ich habe dann also im BIOS nur eine Datei die vom ACPIPatcher ihre Instruktionen erhält, dieser wiederum bekommt seine info's aus vielen ssdt's
Den ACPIPatcher selber integrierst du ins BIOS. Es ist ein Treiber und ich habe ihn oben angehängt. Die Informationen, was der Patcher machen soll erhält er von der ACPIPatcher.plist, die man nach EFI/Oz legt...
Hier ist mal ein Beispiel wie die Plist aussehen kann:Normalerweise schreibt man _DSM Methoden in die DSDT, wenn man sie bearbeitet. Hier ein Beispiel:
Anstatt diese Methoden direkt in die DSDT zu schreiben, kann man sie auch einfach in SSDTs nach Oz/ACPI/Load packen. Diese setzen die Methode dann beim Laden. Bringt keinen unbedingten Vorteil, ist aber übersichtlich -
Da läuft schon alles wie es soll nur ist der NVRAM in Deinem Fall nicht dauerhaft beschreibbar sprich ein Reset oder Exit in der Shell führt dazu das der Rechner neu startet und in dem Zuge alles vergessen hat was Du da mühsam eingetippt hast.
Der NVRAM ist aus dem uefi immer beschreibbar. Sonst würde keine uefi firmware funktionieren.
Du musst Dir als Basis eine Bios Version suchen die den NVRAM offen hält beim Z77-DS3H ist das zum Beispiel die vorletzte also die F10f die F9 oder auch die F11a haben hingegen einen gesperrten NVRAM.Es gibt keinen gesperrten NVRAM. Siehe oben. Mit aptiofix gehts auch aus OSX auf allen mobos.
Bis HighSierra war das nicht wirklich wichtig da OZ beim Start eben die Geräteliste immer wieder neu erstellt hat...Welche Geräteliste?
-
@kuckkuck
Also hab ich das richtig verstanden, zumindest vom Grundprinzip, auch wenn ich es vielleicht falsch formuliert habe
Aber wenn ich ganz ehrlich sein soll, was ich eigentlich meistens versuche, dann glaube ich das mir das Zuviel wird. Da bin ich nicht fähig genug.
Ich bekomme schon nen halben Herzkasper wenn ich an meinem BIOS eine ffs einfüge, geschweige denn wenn ich anfangen muss in 2 oder 3 Dateien alles richtig zu machen.Wenn du jetzt sagst ich erstelle dir das alles so das du es nur noch auf die Platte schieben musst. Her damit, ich probiere gerne rum.
Aber ich befürchte um da selber im Code Hand an zu legen ist mein Bit&Bite-Horizont zu begrenzt.Vielleicht wäre es doch das beste wenn sich jemand erbarmt und mir meine DSDT Zeitgemäß für Sierra + HighSierra patcht und aus die Maus.
Auf der Kiste wird sowieso nichts anderes gestartet als MAc ...
