Beiträge von Maddeen

Danke - und schon läuft mein alter Freund wieder tadellos

Update: Bin wieder auf den originalen OC (0.5.5) zurück und siehe da - Fehlermeldung von oben ist damit auch verschwunden. Soweit so gut

Was mir aber gerade noch einfällt, wie kann ich über OC eigentlich die SIP deaktivieren? Ich weiß zwar den Parameter csr-active-config aber ich finde in der Doku keine Referenz dazu.

Nur eine Info bei einem anderen Eintrag... was wäre denn der korrekte Wert?

Zur Info ... ich nutze seit Jahren den TotalFinder, da das Original einfach schlecht ist und die Alternativen entweder mit unsinnigen Funktionen überfrachtet (Pathfinder) sind oder die Integration nicht nahtlos (ForkLift) ist.

Sascha_77 - wie ich dein Tool liebe.

Habs gemacht - scheint auch funktioniert zu haben, da der Kextupdater jetzt anstatt dem grünen Haken (vermutlich das Zeichen für ist gefixt) in ein rotes X (Originalzustand) gewechselt hat.

Ich werde dann mal über die Logs die o.a. Recherche in Angriff nehmen und gucken, wer meinen Hacki immer nach ein paar Sekunden aufwachen lässt

Hätte denn noch einer eine Idee zu der Fehlermeldung, die ich seit dem NVRAM Reset bekomme (aber die keine Auswirkungen, außer der Meldung an sich, zu haben scheint) ?

OCS: Failed to parse real field of type 1

Danke und schon mal einen schönen Feierabend

Ahhh also doch kein gemurkse mit einem Schreibschutz? Ich bin unsicher, weil das Image ja 0kb hat?

Im Netz finde ich aber hunderte Infos, dass bei den Usern das Sleepimage mehrere Gigabyte groß ist

Zitat von kuckkuck

Die beste Herangehensweise in so einem Fall ist über das Terminal im Log die Wake Reason zu finden und sich dann das entsprechende Gerät anzuschauen. Meistens ists USB, da hilft dann ne USB Dummy Kext.

Fix Sleepimage ist mehr Dirty Hack als Fix. Was da wahrscheinlich gemacht wird ist, dass das Sleepimage erst gelöscht wird, dann ein leeres Sleepimage erstellt wird und dieses schreibgeschützt wird. Dafür gibts auch Terminal befehle mit denen (leicht angepasst) du das einfach rückgängig machen kannst.

Dank dir kuckkuck für die Info. Hätte ich mal besser vorher fragen sollen - leider konnte man so nichts über die Funktion ergoogeln. Du hast offensichtlich Recht, wenn man sich den Screenshot anguckt oder? Haken bei "gesperrt" ist drin - aber angeblich hat der User "System" weiterhin read und write?!

Die gute Nachricht ist, dass der Sleep jetzt funktioniert. Die Schlechte ist jetzt aber wohl deine Info - sofern der Screenshot deine Vermutung bestätigt.

Sollte dem so sein, kann man das sleepimage bei deaktivierter SIP wohl einfach löschen - macOS legt es dann selber wieder an, mit den richtigen Rechten.

Danach würde ich dann deine "Ursachensuche" durchführen -- ist denn dieser Befehl den ich gerade gefunden habe, noch Up2date?

log show --style syslog | fgrep "Wake reason"

JimSalabim - super - vielen lieben Dank für die Erklärung!!!

Ich probiere gerade etwas mit meinem Sleep-Problem rum, da der Rechner von alleine ca. 2-5 Sekunden nach dem er in den Ruhezustand gewechselt ist, automatisch aufwacht.

Ich habe dazu mal folgendes versucht

1. Ausführung des "Fix Sleepimage" via Hackintool.

Resultat:

Der Eintrag "proximitywake" (Register "Power") ist von rot markiert mit einer "1" auf eine grüne Markierung mit dem Wert "0" gesprungen, ABER ca. 10 Sekunden später habe ich einen sofortigen Freeze (vermutlich Kernel-panic)

Wenn ich jetzt reboote, erscheint kurz vor dem Bootpicker folgende Meldung, die ich nur mit einem Video überhaupt erfassen konnte

OCS: Failed to parse real field of type 1

Kann damit irgendeiner was anfangen? Danach erscheint der Bootpicker und ich kann normal in mein mac bzw. Windows booten

Dummerweise konnte ich keine Info finden, was der "Fix Sleepimage" genau macht und somit verstehe ich auch nicht, warum nach der Durchführung mein OC jetzt meckert. Ich sehe da keinen Zusammenhang

Herzlich Willkommen ...

zu dem Post von psy möchte ich noch kurz was ergänzen. Du solltest dich aus meiner Sicht erst mal fragen, wie TIEF du dich mit dem Thema beschäftigen willst.

Möchtest du ein System mit wenig Aufwand erstellen und pflegen und dafür auf das "Wissen dahinter" verzichten?

Oder magst du Rätsel, Denksportaufgaben und ähnliches?

Vorweg - ich habe mich vor drei Jahren für das Tor "schnell ein lauffähiges System mit wenig KnowHow lernen" entschieden.

In diesem Fall empfehle ich dir, gar nicht erst mit Hardware anzufangen, die du mal gerade "rumfliegen" hast.

Da kommen nämlich sehr viele Rätsel auf dich zu...

Für diesen Fall empfiehlt sich ein Blick in die lauffähigen Konfigs hier im Forum zu werfen und zu schauen, welche Systeme mit den wenigsten Anpassungen laufen.

Das trifft z.B. für Notebooks meines Wissens nie zu, weil die Hersteller eben nicht identische Hardware wie Apple verbauen. Da muss man dann im Worst-Case mit externen WiFi-USB-Dongles hantieren und die dann z.B. die ganzen Continuity Features nicht leisten (können)

Daher habe ich damals nur Hardware gekauft die - wie man so schön sagt - OOB (out of the box) läuft. Sprich man braucht keine speziellen Treiber oder ähnliches.

Bedeutet du guckst auf everymac.com oder via google, aus welchen OEM-Teilen der iMac besteht und kaufst dann exakt das.

Sprich gleiche CPU, ein Mainboard mit dem gleichen Chipsatz (z.b. 100er), eine identische Grafikkarte (AMD VEGA 56/64), identischen RAM und eine PCI Karte für WLAN/BT (z.B. Fenvi T919). Damit reduzierst du das Fehler und Herausforderungspotenzial enorm.

Oder aber du hast willst direkt auf die vollen gehen ... In beiden Fällen bist du hier aber genau richtig.

Viel Spass beim stöbern.

Alles klar.. dann werde ich das mal am Wochenende austesten, wie es sich damit lebt, einfach gar kein Bootpicker mehr zu haben und das nativ in macOS zu steuern.

Lt. Doctor muss ich ja nur ShowPicker = No und Timeout = 1 setzen, sodass ich dann das bootpicker-freie mac-Feeling bekomme

Bin gespannt...

Stimmt auch wieder.. ich habe ja auch die Hoffnung, dass die die nur bei mobilen Geräten einsetzen.

Im Desktopbereich hat der ARM keine Existenzberechtigung, da sein einziger Vorteil gegenüber Intel/AMD die Energieeffizienz ist - die mir aber bei einem Desktop-PC, wo eine 300 Watt fressende GFX drin ist, mal völlig wumpe ist

Es bleibt spannend

Danke - wie gesagt überlege ich, ob ich dann kurzfristig auf den "native-mac-modus" wechsle -- dann sind auch die Einträge egal, wenn er eh ohne Picker direkt ins macOS bootet.

Der Rest vom Fork interessiert mich eh nicht bzw. ist bei mir nicht wichtig, weil ich meine Systemkomponenten ja nach "was läuft OOB" ausgewählt habe

Mhh .. keine Ahnung wo ich das mit dem Bootcamp gelesen habe. Aber - und das habe ich gestern gemerkt - wenn ich Scanpolicy auf 0 setze, habe ich einmal "Win10" und einmal "Bootcamp: Win10"

Sprich das ist nur eine andere Anzeige - aber das System wird trotzdem nativ gestartet - also ohne irgendwelche Apple-Sachen, die das Windows irgendwie verbiegen und "kompatibler" für Apple-Hardware machen sollen?

Ist unser aller (Hackintosh-)Ende nicht eh bald in Sicht?

Aktuell sieht doch alles so aus, als würde Apple mittelfristig wieder den Fehler machen und zu irgendwelchen ARM-CPUs wechseln.

Für mich wäre das Thema mit dem Wegfall der x86/x64 Architektur definitiv erledigt - macOS ist ne feine Sache - aber für Desktopbetrieb will ich nichts von ARM-CPUs hören und sehen.

Den Powermac und wie das ganze proprietäre "Gelumpe" früher hieß, hätte ich niemals gekauft oder empfohlen.

Die gleiche Architektur wie Windows und somit auch von 98% aller Softwarehersteller zu nutzen, war aus meiner Sicht der wichtigste Schritt, dass heute überhaupt viele Leute auch ein Macbook usw. haben wollen.

Ich hatte mal ein Synology-NAS mit ARM-CPU -- da war der Name leider Programm. So eine ARMe Performance hatte ich schon lange nicht mehr. Gleiche Modell mit Intel-CPU - Faktor 2-3 schneller.

Zitat von Download-Fritz

Maddeen Kleine Beschreibung ist hier, vielleicht grad der Nachricht befügen: https://www.insanelymac.com/fo…ndComment&comment=2707673

Dank dir mhaeuser -- also wenn ich deinen Post richtig verstehe, ist mein "Problem" ein Resultat des eigentlichen "Fork-Features" bzgl. der eigenen Reihenfolge?

Es liest sich so, als wenn ich OC (origin) ohne bootpicker und macOS als Startvolumen nutze, es sich so verhält, wie ein echter Mac - wo er im Neustart direkt ins Update bootet, oder?

Übrigens interessante Info - NDK hätte also auch einfach die zwei "interessanten" Features als eine Art "addons" für OC liefern können ohne einen kompletten Fork zu machen?

Die Entscheidung verstehe ich dann allerdings auch nicht...

Und als letztes noch eine kurze Frage, die du vielleicht am besten beantworten kannst.

Wenn ich auf den (ich nenne ihn jetzt mal) native-Mac-Modus umschalte - also ohne Bootpicker, wo er einfach direkt in das unter macOS ausgewählte Startvolumen bootet und ich dann mal auf Win10 als Startvolume wechsle - wird dann das native Win10 gestartet oder das Bootcamp-Win10? Ich habe in den x-ig Beiträgen zum Thema irgendwas gelesen, dass das Bootcamp-Windows nicht so performant läuft, wie das native.

Dank dir schon mal.

Ist bei mir vermutlich nur die Gewöhnung. Bilder wären mir auch egal. Aber bei der Reihenfolge bin ich ein kleiner Monk

Dabei fällt mir ein - wie müsste man eigentlich die Settings setzen, sodass der Picker gar nicht mehr erscheint?

Griven hatte im Video erwähnt, dass man das machen könnte und dann nur in der macOS Systemsteuerung umschaltet, was gebootet werden soll.

Reicht es dafür den Eintrag "UsePicker" auf NO zu setzen? Bootet er dann automatisch immer in macOS?

Ich hatte leider nie einen echten Mac, daher stellen sich mir bei der Variante noch ein paar Fragen.

1) wie würde ich denn ohne Bootpicker an meinen CarbonCopyKlon kommen?

2) wenn ich dann mal umstellen würde auf "Startvolume = Windows". Wie kann man denn dann entscheiden, dass man beim nächsten Mal wieder in macOS booten möchten?

Sowas wie "Startvolumen festlegen" gibt es ja in Win10 meines Wissens nicht.

3) Ist der Start in Windows dann ein nativer Start oder via Bootcamp? Ich hatte hier mal irgendwo sowas gelesen - Bootcamp wäre performancetechnisch vermutlich nicht zielführend, da ich ja Win10 nur zum Zocken (also maximale Performance) brauche...

Mal was fürs Protokoll, weil ich das Problem gerade hatte.

Ich wollte auf macOS 10.15.3 Updaten... nach dem Neustart bekommt man normalerweise die Partition "Install macOS" angeboten.

Das war bei mir nicht so - nur die zusätzliche Recovery-Partition (die mit dem Update automatisch kommt) wurde angezeigt.

Ein ändern der ScanPolicy auf 0 hat nichts gebracht.

Erst als ich meinen CustomEntrie für meine macOS Partition disabled hatte, erschien auch die Install macOS Partition für das Update.

Ich werde das mal an NDK weitergeben - aus meiner Sicht ist das ein Bug der nicht sein darf..

Weil ich die Reihenfolge der Einträge im Picker selber steuern will. Das geht ja nur mit dem NDK Fork.

Ich werde denen jetzt auch mal einen Bug melden - jedenfalls ist es einer aus meiner Sicht.

Mal gucken was die sagen...

P.S Update sauber durchgelaufen. Dank dir!

Tante Edith sagt: Fehler vermutlich gefunden. Es liegt an dem CustomEntry den ich für mein macOS gemacht habe. Den habe ich jetzt mal disabled und siehe da - die bekannte Install macOS ist da und kann ausgewählt werden. Hab es jetzt mal gestartet. Bin gespannt ob es durchläuft

Ich hatte auch schon auf 0 gestellt -- das bedeutet doch "Zeig mir alles was du findest", wenn ich das richtig verstanden habe

Genau die meine ich.

Leider ja... hatte zwar den Eintrag nicht 100% korrekt (HfsPlus.efi) - aber ein ändern auf case-sensitive (HFSPlus.efi) hat keine Änderung gebracht.

Komisch ist auch, dass ich jetzt DREI Recovery-Partition habe - eine die nur "Recovery (dmg)" heißt. Ich gehe davon aus, dass das die vom Update ist (war glaub ich bei Clover auch so)

Aber die bekannte "Install macOS" fehlt weiterhin, sodass ich kein Update durchführen kann..... mysteriös