Beiträge von mabam

    Danke für deine Rückmeldung chaironimo, das macht Mut! :)


    g-force: Das wäre wohl der sicherste Weg. Aber wenn die ein oder andere App sich bei der Aktivierung z. B. an die UUID der Festplatte gebunden hat, habe ich eine Aktivierung weniger für die entsprechende Lizenz. Da bin ich sehr vorsichtig, weil ich das lieber vermeiden möchte.

    Darum möchte ich nun so vorgehen, dass ich das Update auf die geklonte Festplatte aufspiele und diese, wenn’s schiefgeht, neu klone und das Update nochmal probiere. Und wenn’s läuft, führe ich die exakt selben Schritte nochmal auf der ursprünglichen Platte durch.


    Wenn ich das nach deiner Anleitung richtig sehe, brauche ich aber auch bei Installation auf das aktuelle Systemvolume nicht vom Stick zu booten, sondern kann das Update direkt vom laufenden System aus starten. – Eigentlich auch logisch, denn mit Sicherheitsupdates funktioniert es ja genauso.


    Auch dir vielen Dank!

    Hallo ihr Lieben!


    U. A. aufgrund der Notwendigkeit, die Familienfreigabe/Bildschirmzeit zwischen macOS und iOS teilen zu können, möchte ich meinen High Sierra-Hackintosh auf Catalina updaten. (Mit Big Sur kann ich mich bis jetzt aus verschiedenen Gründen nicht so recht anfreunden und habe da auch das ein oder andere Kompatibilitätsissue, das seitens der Entwickler erstmal gelöst werden muss.) Außerdem bleibe ich damit wieder zwei Jahre länger kompatibel mit Sicherheitsupdates, Browsern etc.


    Nun soll es aber auch ein Update sein und keine Neuinstallation, da nicht jede Softwarelizenz endlos oft installiert werden kann. Und genau an dem Punkt wird mein Vorhaben möglicherweise etwas Hackintosh-unfreundlich. Oder wie seht ihr das? Das Klonen des Systems auf eine zweite Platte läuft gerade, damit die heutige Installation erstmal unberührt bleibt. Aber muss ich, bevor ich gleich „blind“ drauflos installiere ;), spezielle Dinge beachten, wenn ich von High Sierra auf Catalina updaten will?


    Ich freue mich auf eure Antworten!

    So, nachdem ich jetzt etwas Zeit hatte, habe ich mich endlich nochmal dem nervigen Problem mit dem NVRAM gewidmet.


    Nach nochmals einer langen Suche habe ich nun diese Lösung gefunden:

    Danke an al6042 und JimSalabim für ihre diesbezüglichen Beiträge in o. g. Thread!


    Wie sich durch die Behebung des NVRAM-Problems herausgestellt hat, war dieses tatsächlich die Ursache für das iCloud-Problem, wegen dem ich diesen Thread begonnen hatte. Denn mein iCloud-Login überdauert jetzt den Neustart:top:

    Kann es sein, dass das Problem mit iCloud als Ursache ein nicht funktionierendes NVRAM hat?


    Neben dem eigentlichen Thema dieses Threads habe ich nämlich manchmal das Problem, dass mein Hack aus dem Sleep gleich wieder aufwacht. Nachdem ich mich lange geweigert habe, mich davon stören zu lassen, habe ich jetzt doch mal gegoogelt. Ein nicht funktionierendes NVRAM kann zumindest die Ursache für das Sleep-Problem sein.


    Mit den folgenden Befehlen, die Google ausspuckte, habe ich getestet, ob mein NVRAM funktioniert:

    Code
    1. sudo nvram TestVar=HelloWorld
    2. # und nach dem Neustart:
    3. sudo nvram -p | grep 'TestVar'

    Da kam aber nix zurück, also funktioniert es nicht.


    Laut High Sierra, H370, i5 8400 - Instant-wake up bei Sleep hängt das vielleicht mit meinem H370-Chipsatz zusammen. Ich verstehe die dortige Anleitung aber nicht. Kann mir da vielleicht jemand den Weg weisen?


    Oder bin ich was iCloud angeht damit auf dem Holzweg?

    Hallo griven,


    aufgrund familiärer Verpflichtungen in den Sommerferien und Zeitmangel melde ich mich erst jetzt zurück.

    Was du schreibst klingt nach einem zielgerichteten Ansatz, dafür schonmal vielen Dank!


    Ich verwende Clover 5.2.0.1 und habe damals beim Erstellen meiner config.plist „iMac18,1“ als Modell gewählt (habe das jetzt auch in die Signatur geschrieben). Neben vielen anderen wurden die Werte in „SMBIOS“ –> „SmUUID“ sowie „Rt Variables“ –> „ROM“ bzw. „MLB“ daraufhin automatisch erzeugt und erscheinen jetzt beim Auslesen über Clover auch wieder in den entsprechenden Feldern.


    Habe ich damit die von dir genannten essentiell wichtigen Informationen mitgeteilt oder ist da mehr nötig, um dem Problem weiter auf den Grund zu gehen?


    Noch ein Gedanke, von dem ich nicht weiß, ob er eine Rolle spielt:

    Nach der Basisinstallation von 10.13.6 hatte ich unter SMBIOS das Modell kurzzeitig auf „MacBookPro15,2“ geändert, um ein Systemupdate aufzuspielen, das die UHD630 native unterstützt. Daraufhin habe ich sofort wieder mit meinem ursprünglichen CLOVER-Ordner (also mit iMac18,1) gebootet und damit seitdem auch weitere Sicherheitsupdates aufgespielt. Erst danach habe ich mich auf dem Rechner zum ersten Mal bei iCloud eingeloggt.

    An Geräten habe ich nur das iPhone und den aktuellen Hack drin, sonst nichts. Und am Rechner bin ich bis jetzt auch nur bei iCloud angemeldet, nicht unter iTunes, Facetime, o. ä. (kommt evtl. noch irgendwann).


    Meinst du mit „komplett abmelden“, dass ich mich unter appleid.apple.com anmelde und den Rechner dort unter „Geräte“ entferne?

    Ich bin mir nicht sicher, ob ich im richtigen Unterforum bin. Falls nicht, bitte ich um die richtige Zuordnung.


    Mein Hack funktioniert gut und hier und da kommt der ein oder andere Skript zum Feintuning hinzu. Auch iCloud, was ich zur Synchronisierung benutzen will, funktioniert mit meiner Apple-ID, die ich schon Jahre problemlos auf dem iPhone nutze. Allerdings bekomme ich nach jedem Neustart des Rechners eine Meldung, dass ich mich neu bei iCould einloggen muss. Weiß da wer Abhilfe?

    das dir da keine digitus-karte angezeigt wird, ist insofern logisch, als das karten-ver-käufer ala oemhändler fungieren , also das du x-händler mit ein-undderselben hardware sogar macadresse und oder fccid -findest, sogar dem ähnlichen, wenn nicht gar gleichen bild.

    Das ist mir klar. Da im Eingangspost aber explizit „Intel-CT-Desktop NIC EXPI9301CT oder EXPI9301CTBLK“ genannt wird, war ich mir zuerst nicht sicher, ob die identische Geräte-ID 10D3 allein ausreicht, oder evtl. irgendwas anderes noch eine Rolle spielt.


    das der chip nun anders als erwartet ist, hmja -gut oder schlecht- weiß ich jetzt nicht. hier

    eine karte evtl. -mit- intel chip, aber der ist unter den kühlkörper, könnte also auch ein realtek sein, deren logo ja leicht erkennbar ist. intel-karte amazone

    Für mich ist es letztendlich gut, dass der Chip anders als erwartet ist. Denn nach dem Flashen läuft die Karte mit den macOS-eigenen Treibern. Wenn man aber nicht flashen kann/will, ist es halt schon doof, wenn man etwas anderes geliefert bekommt, als in der Produktbeschreibung steht. Ich habe das mit dem Flashen auch zum ersten Mal gemacht und hatte ja Glück, dass eine NIC mit Intel 82574L-Chip geliefert wurde, zu der es diese Anleitung für die macOS-Verwendung gibt. (In der Anleitung in diesem Thread wird die genaue Chip-Bezeichnung zwar nicht genannt, aber in der ursprünglichen Anleitung auf insanelymac, die hier verlinkt ist, ist explizit davon die Rede.) Sonst wäre die NIC für mich unbrauchbar gewesen.


    ansonsten gibt es ja noch andere hersteller, die üblichen verdächtigen, wie 3com, atheros, broadcom, intel, mediatek, realtek , usw. je nach firmenübernahme sind dann auch deren treiber auf unterschiedlichen firmenseiten, so die dort weitergepflegt werden,

    Klar. Nur kann man die NIC auf der oben verlinkten Digitus-Produktseite nicht mit den Treibern installieren, die Digitus auf selbiger Seite zum Download anbietet. Damit wollte ich nur sagen, dass das nahe legt, dass Digitus auf derselben Produktseite zuerst eine NIC mit Realtek-Chip angeboten hat und Amazon diese damals schon von Digitus bezog. Nur dass Amazon nach dem Wechsel zu Intel bei dem Produkt verpennt hat die Produktangaben auf amazon.de zu korrigieren. Aber das ist ja wie schon gesagt nur gut für mich, denn sonst wäre ich nie auf die Idee gekommen eine für macOS eigentlich nicht verwendbare Karte zu flashen, damit sie danach mit nativen Treibern läuft.

    Hast du die Befehle vor BootUtil -saveimage -file=Backup.flb

    korrekt ausgeführt?

    Die stehen zwar in Code Blocks, sind aber eher zu verrichtende Handlungen und keine Befehle. Die habe ich auch ausgeführt (auch wenn es bei mir im BIOS etwas Anderes zu beachten galt, woran ich drei Stunden geknobelt habe – ich musste die CSM-Unterstützung einschalten, alles andere passte schon), wodurch ich nun vom DOS-USB-Stick booten kann.


    Ich denke, dass der Error erscheint, weil nicht nur die NIC von Intel ist, sondern auch mein Onboard-Ethernet. Und dann weiß BootUtil nicht, welche von beiden Schnittstellen ich ansprechen will.

    Wenn ich nach der Fehlermeldung google, finde ich nur ein japanisches Forum, aus dem ich auch nach einer Auto-Übersetzung ins Englische nicht schlau werde.


    Die Dokumentation zum BootUtil auf https://www.intel.de/content/w…s/000005790/software.html hat mich aber weitergebracht. Wenn ich den Befehl BootUtil -nic=01 eingebe, bekomme ich:

    Code
    1. Intel(R) Ethernet Flash Firmware Utility
    2. BootUtil version 1.6.57.0
    3. Copyright (C) 2003-2017 Intel Corporation
    4. ERROR: iSCSI is not flashed on port 1
    5. Port Network Address Location Series WOL Flash Firmware Version
    6. ==== =============== ======== ======= === ============================= =======
    7. 1 XXXXXXXXXXXX 0:31.6 Gigabit N/A FLASH Not Present
    8. 2 XXXXXXXXXXXX 1:00.0 Gigabit YES PXE 1.3.21

    Wenn ich die Netzwerk-Karte ausbaue und neu starte, fehlt beim gleichen Befehl die zweite Zeile. Damit ist meine Karte auf Port 2. Mit dem Befehl BootUtil -nic=02 -saveimage -file=Backup.flb konnte ich jetzt das ursprüngliche ROM sichern.

    Die nächsten Befehle habe ich in BootUtil -fe -nic=02 bzw. BootUtil -up=EFI -nic=02 -file=BootIMG.FLB geändert.


    Nach dem Flashen liest sich die oben genannte zweite Zeile nun:

    Code
    1. 2 XXXXXXXXXXXX 1:00.0 Gigabit YES UEFI 8.2.01


    Jetzt muss ich mir erstmal einen Linux-Live-USB-Stick erstellen, dann geht’s weiter.



    EDIT:
    So, mit Knoppix 8.6.1 als Linux-Live-System hat die Änderung der Geräte-ID geklappt. Bei den „ethtool“-Befehlen musste ich eth1 statt eth0 verwenden, wie ich in Knoppix per lshw -class network herausfand.

    Den „eeupdate.exe“-Befehl zum ändern der MAC-Adresse konnte ich dann wieder unverändert übernehmen.

    Als zeitsparender Tipp für Andere: Unter https://hwaddress.com/company/apple-inc/ gibt’s wirklich massenweise Apple-Hardwareadressen.

    Die von mir geflashte Karte habe ich für knapp 13 Euro unter https://www.amazon.de/dp/B008GXNY1U gekauft. Wie in meinem vorherigen Post schon erwähnt steht da RTL8168E als Chipsatz, mir wurde aber eine mit Intel 82574L-Chipsatz geliefert, die optisch exakt der Abbildung auf Amazon entspricht. Genau diese Abbildung findet sich auch auf der Website des Herstellers wieder: https://www.digitus.info/de/pr…ten-und-adapter/dn-10130/ , wo auch Intel 82574L als Chipsatz genannt wird (interessanterweise aber Treiber-Downloads bis OS X 10.7 für den Realtek-Chipsatz angeboten werden). Eine mit RTL8168E-Chipsatz gibt es da gar nicht. Das erweckt den Eindruck, dass die Info bei Amazon veraltet ist und immer eine mit o.g. Intel-Chipsatz geliefert wird. Für gerade mal 13 Euro ist das super!

    Wie auch immer: Die Karte wird jetzt nach dem Flashen von macOS anstandslos erkannt und ich freue mich.


    An dieser Stelle vielen Dank an aalbani (und natürlich auch den Verfasser der zugrundeliegenden englischen Anleitung auf insanelymac)!



    EDIT 2:

    Einziger Nachteil: Die Karte scheint kein AppleTalk zu transportieren (was mir, wenn man in meine Signatur schaut, wichtig ist). Zum Glück kann mein Onboard-Ethernet das.

    Nachdem ich eine PCIe LAN-Karte mit RTL8168E-Chip bestellt hatte (die laut diesem Thread OOB funktionieren sollte), wurde mir eine mit Intel 82574L-Chip geliefert.


    Der Hersteller der Karte ist nicht Intel, sondern Digitus. Die Geräte-ID ist aber sehr wohl 10D3, wie oben im ersten Post als Voraussetzung genannt. Reicht das aus um wie oben beschrieben flashen zu können, oder muss die Karte selbst auch von Intel sein? Sonst geht die nämlich wieder zurück.


    DPCIManager sagt:

    8086   10D3   8086   A01F   Intel Corporation   82574L Gigabit Network Connection


    Hier der Output von IOReg:


    EDIT:

    Also ich hab das jetzt einfach probiert. Nachdem ich den Befehl BootUtil -saveimage -file=Backup.flb eingegeben habe, erhalte ich jedoch die Fehlermeldung ERROR: SAVEIMAGE option requires -NIC parameter.


    Weiß da jemand Rat?

    Wie hast Du das Motherboard befestigt- alle alten Halter raus und neue gebohrt?

    Ja, genau. Diejenigen alten, die im Weg waren, habe ich rausgebohrt. Ich glaube in drei Schritten, mit Bohrergrößen von klein nach groß, weil das sonst zu schwer ging. Nur nicht zu tief, damit kein Loch in der Metallplatte des Gehäuses entsteht. Vielleicht geht es aber mit einem Dremel besser.


    Ich habe dann an den nötigen Stellen Löcher in die Metallplatte gebohrt und Metallschrauben mit Muttern darin verschraubt, damit ich herausstehende Gewinde hatte. Darauf habe ich dann wieder jeweils zwei Muttern gekontert, auf die ich dann die Hauptplatine aufgelegt habe und die dann eben wieder mit Muttern verschraubt.


    Und wo schließt Du das Flachbandkabel des Powwerschalters an? Ich würde gerne die originalen Schalter vorne belassen.

    Hast du dir Post 11 angeschaut? Die alte Platine musst du rausschmeißen, weil die darauf verlötete Elektronik nur mit der originalen Apple-Hauptplatine kompatibel war. Ich habe mir eine Lochplatine auf Maß gesägt und Taster auf die richtigen Positionen gelötet, damit die Gehäuseknöpfe da genau draufdrücken.


    Die Pin-Abstände und -Anzahl des Flachbandkabels sind identisch mit aktuellen Hackintosh-Hauptplatinen. Nur ist der alte Stecker etwas breiter. Da habe ich rechts und links vorsichtig was weggeschliffen, damit er zwar in den Anschluss passt, die Verschlüsse des Steckers aber noch intakt bleiben.


    Du musst dir die Anleitung deiner Hauptplatine genau anschauen, damit du auf deiner Power-Platine die richtigen Pins der Buchse mit den Tastern bzw. der LED verlöten kannst.



    EDIT:

    Google mal nach „superandy07's G3 Mod“, davon habe ich mich ursprünglich inspirieren lassen.

    Das 17G2208 gibt’s eigentlich nur über die Recovery Partition. Ich hab mir damals aber basierend auf einer Anleitung, die ich im Netz gefunden habe, eine Installer-App daraus gebastelt. Als ich die nun starten wollte kam folgende Meldung:

    „Diese Version des Programms ‚macOS High Sierra Installieren.app‘ ist beschädigt und kann nicht für die Installation von macOS verwendet werden“.


    Abhilfe fand ich hier:

    https://www.macuser.de/threads…1503/page-2#post-10387189

    Es ging jedoch nur, nachdem ich vorher den Netzwerk-Stecker entfernt hatte.

    Ja, die Datei ist vorhanden.


    Ich hatte es schon zweimal neu vom Backup aufgespielt. Allerdings ist das ursprüngliche Backup auf einer externen Platte, von der ich es auf eine interne Partition gespielt habe, bevor ich die Wiederherstellung durchgeführt habe. Lange Zeit wurde beim Booten vom Stick die externe Platte nämlich nicht erkannt und so war dieser Arbeitsablauf gestern noch automatisch drin bei mir. Dieses Problem verschwand aber wohl mal bei irgend einem Kextupdate und so habe ich das Backup jetzt direkt von der externen Platte zurückgespielt – mit der selben Kernel Panic als Ergebnis.


    Ich habe damals während dem Installationsvorgang vier Backups gemacht, begonnen bei der ersten Installation (10.13.1) und dann von jedem Update, das ich gefahren habe. Beim letzten (10.13.6 17G5019) und vorletzten (10.13.6 17G2208) Zeitpunkt aus dem TM-Backup bekomme ich dieselbe KP. Aber der zweite (10.13.6 17G65) läuft nach dem Wiederherstellen.


    Jetzt muss ich von da aus die anderen Updates wieder fahren und dann ein neues TM-Backup erstellen.


    Danke für deine Hilfe!

    Das Backup habe ich erstellt, als der Rechner vor allem Ausprobieren einwandfrei lief.


    Ja, ich kann mit der EFI in die Recovery HD booten. Sieht aber ungesund aus:



    Vor dem Wiederherstellen aus TM habe ich testweise auf das Securityupdate 2019-006 upgedated. Während diesem Update sah der Bildschirm genauso aus wie auf obigem Foto. Als es fertig war lief das System ohne weiteres und so plante ich, das Update auch nach dem Wiederherstellen durchzuführen. Dazu kam es dann aufgrund der Panic ja aber nicht mehr.