Welche Clover-Version hast du?
Ich habe mein Clover gerade geupdatet von Version 3726 auf Version 3994 und er bootet durch!
Manchmal liegen die Probleme nicht unbedingt bei Apple ...
Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenWelche Clover-Version hast du?
Ich habe mein Clover gerade geupdatet von Version 3726 auf Version 3994 und er bootet durch!
Manchmal liegen die Probleme nicht unbedingt bei Apple ...
Ich habe eben mal nach dem IOConsoleUser gegoogelt.
Um dem ganzen aber auf den Grund gehen zu können wären folgende Infos nötig:
- welche Clover-Version wird eingesetzt?
. ist der EmuVariablesUefi-64.efi im Ordner /EFI/CLOVER/drivers64UEFI vorhanden?
- wurden die RC-Scripte installiert?
Nachvollziehbar, in dem man unter /etc folgende Verzeichnisse und Dateien findet:
Hierbei ist der "70.disable_sleep_proxy_client.local" nicht wichtig und deswegen auch "disabled"
- befindet sich eine Datei namens "nvram.plist" im Hauptverzeichnis eurer versteckten EFI-Partition?
Der Hintergrund:
Mit diesen RC-Scripten, im Zusammenhang mit dem EmuVariablesUEFI-64-Treiber, kann Clover die Werte des aktuellen NVRAMs auslesen und in die "NVRAM.plist" schreiben.
Dies erfolgt über das Script "/etc/rc.shutdown.d/80.save_nvram_plist.local" beim Herunterfahren/Neustart.
Das Script "/etc/20.mount_ESP.local" wiederum mounted beim Starten diese EFI für kurze Zeit, um daraus die "NVRAM.plist" auszulesen und in den NVRAM zu injecten, so dass dessen Einstellungen auch wieder zur Verfügung stehen.
Der Fehler mit dem Hänger bei IOConsoleUser kann daran liegen, dass die NVRAM-Daten nicht alle nötigen Infos enthalten, die beim letzten Betriebsstatus dort hätten eingesetzt sein sollen.
Mit den Scripten und der NVRAM.plist stellt ihr sicher, dass beim Herunterfahren der tatsächliche Inhalt des NVRAMs gesichert und beim nächsten Starten auch wieder genutzt wird.
Checkt das doch bitte mal aus.
Bin auf Eure Infos gespannt...
Der Hacki fährt ja nicht hoch. Ich müsste die Platte ausbauen und per SATA-USB Kit anschließen, weil ich in Windows noch eine Virtual Machine mit macOS drauf hab. Im Grunde genommen kein Problem.
EmuVariablesUefi-64.efi ist aber definitiv drinnen, das weiß ich noch.
Die Scripts müssten ja auch da sein. Das Update von 10.12.2 auf 10.12.3 ging ja auch problemlos.
Das hätte früher ja schon auffallen müssen, dass da im Bootloader vielleicht Scripts fehlen.
Gibt es denn überhaupt eine Möglichkeit das zu fixen oder komm ich um eine Neuinstallation nicht mehr herum?
Ich hab das nämlich so verstanden, dass halt nötige Informationen in den NVRAM Dateien aus dem letzten Betriebstatus gesichert werden, wenn diese aber unvollständig sind, geht das überhaupt noch zu retten?
@McRudolfo
Den Gedanken hatte ich schon. Würde dann aber die Recovery HD nicht auch streiken?
Im Übrigen geb ich Apple da keine Schuld, was aus deinem Post für mich so hervorging.
1. Denk ich, dass ich was übersehen habe und 2. Ist die Rede von einem Hackintosh....
EDIT: Hab gerade nachgeschaut, bei mir läuft gerade Clover 3899, nicht die aktuellste. Lese aber auch häufig, das Leute wieder downgraden, weil irgendwas nicht läuft in den neusten Versionen.
Ich bin mir nicht sicher, ob ich dich das schon gefragt habe, aber kannst du den Hacki mit dem Boot-Argument "nv_disable=1" booten?
Update gemacht und meine Baustelle bleibt wie selbstverständlich einfach stehen. Warum denn auch nicht?
@al6042
Wäre das nicht das selbe, wie im Bootmenü bei Clover die Leertaste zu drücken und dann unter Graphic Injects beim Punkt Load VBIOS den haken zu setzen, was in meinem Fall schon so wahr?
@McRudolfo
Wollte dir auch nicht dumm kommen. Wollte selbst nur aussagen, ich bin verzweifelt... HILFE!!!!
Apple kann ich ja schlecht fragen
Tja...
wenn das da schon so steht, dann war das wohl nix...
Beim Skylake gibt es noch ne Besonderheit:
Wer das Workarount wegen der Booteinträge gemacht hat, kann nicht einfach das Clover-Update installieren. Falls jemand davon betroffen ist -> in der Sierra-Anleitung.
@al6042
Oh maaannn. Wobei ich die Theorie mit dem NVRAM teilweise nachvollziehen kann. Denn: Normalerweise beginnt der Ladebalken bei der Hälfte und läuft dann ganz schnell durch bis ich dann zum login Bildschirm kam.
Jetzt beginnt der Balken ab 3/4 und läuft langsam.
Boote ich nun die Recovery HD beginnt der Balken auch bei 3/4, springt aber dann zum Anfang und läuft neu durch.
Demzufolge, was du heraus gefunden hast: in den NVRAM Dateien werden Einstellungen vom letzten Betrieb gesichert, kommt mir das beim booten von der Recovery HD so vor, als wenn das System mir damit sagen will: "Scheiß drauf, im Recovery brauch ich die Einstellungen nicht"... Daher lädt der Balken wohl auch von vorne. <--- Wirres Gedankengulasch von einem Lehrling
Ich kann jetzt auch endlich Erfolg vermelden. Ich habe Clover und einige Kexts aktualisiert (auch die RC-Scripte installiert) und diesmal lief das Update reibungslos durch. Klasse!
Habe das auch so gemacht und mit Kext Utility die Kexte upgedadet.
aber immer noch schwarzes Bild..
Update hier auch ohne Probleme
Was willst du mir sagen? Meinst du an das Mainboard oder an die GPU?