Beiträge von mabam

    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.

    So, falls irgendwer mal ein ähnliches Problem hat, möchte ich meine letztendliche Konfiguration hier dokumentieren:


    Ich wollte mit sleepwatcher keinen externen Skript ausführen, obwohl das eigentlich so gedacht ist. Denn sonst muss ich neben dem Launch Agent unter /Library/LaunchAgents/org.mabam.wacom.sleepwatcher.plist noch irgendwo anders einen Skript unterbringen, der aber eigentlich zum Launch Agent gehört und ein recht einsames Dasein pflegen würde. Ich hab’ lieber übersichtlich alles in einem, damit ich auch Jahre später noch auf einen Blick sehen kann, was wozu gehört.


    Wenn ich im Launch Agent Variablen ins Argument hinter /usr/local/sbin/sleepwatcher schreibe, expandiert letzterer diese einmal und merkt sich den daraus resultierenden Wert für jegliche folgende Ausführung. Sollte ich in der Zwischenzeit das Intuos also in einen anderen USB-Port gesteckt haben, versagt sleepwatcher.


    Gelöst habe ich das, indem der Launch Agent beim Laden den benötigten Skript nach /tmp schreibt, wo sleepwatcher ihn dann ausführt. So werden die Variablen bei jedem Ausführen neu expandiert und ich kann das Intuos nach Lust und Laune umstöpseln. Beim Runterfahren wird der Skript vom System gelöscht und beim nächsten Hochfahren vom Launch Agent wieder erstellt (ein ewiger Kampf also … :)). Auf diese Weise ist alles Nötige einzig im Launch Agent enthalten.


    Das Problem, dass Dateien in /tmp nicht ausführbar gemacht werden können, wird umgangen, indem das Argument hinter /usr/local/sbin/sleepwatcher mit /bin/bash beginnt.


    Hier der Launch Agent:


    Ich habe inzwischen übrigens festgestellt, dass mein Dell 1704FPT-Monitor über ein per uhubctl schaltbares USB 2-Hub verfügt. Wenn ich das mit obiger Lösung verwende, wacht der Rechner jedoch sofort wieder auf, nachdem er im Sleep-Modus angelangt ist. Seltsam. Wenn ich das AmazonBasics-Hub (USB 3) verwende, funktioniert alles einwandfrei.

    So, nachdem ich das erste Hub beim Versuch, es mit einem PCI-Slotblech zu versehen verheizt habe (weil ich erst nach dem Durchbohren der Platine sah, dass es sich um eine Multilayer-Leiterplatte handelte und damit im Inneren wohl noch was Anderes als nur Masse erwischt habe :huh:), kam gestern das neue Hub und ist nun eingebaut:



    • Auf dem ersten Bild sieht man ganz unten einen Adapter USB 3-Pinheader –> 2 × USB A-Buchse, in den das Hub eingesteckt ist.
    • Auf dem zweiten Bild ist die Platine des USB-Hubs mit einen Slotblech verschraubt.
    • Auf dem dritten Bild sieht man das Ganze dann von außen.
      Das Slotblech hatte ich noch rumliegen. Es hat nur zwei Öffnungen, aber ich habe sonst genügend USB-Anschlüsse und zwei schaltbare reichen mir. (Zusätzliche Löcher im Slotblech wären mit meinem Werkzeug wohl relativ hässlich geworden, also hab ich’s lieber gelassen.)

    Vor dem Sleep Power ausschalten geht über:

    Code
    1. uhubctl=$(uhubctl); uhubctl -a off -el $(echo "$uhubctl" | grep 'USB 2' | cut -d ' ' -f 5) -p $(echo "$uhubctl" | grep Wacom | cut -d ' ' -f 4)

    So funktioniert es auch noch, sollte ich das Tablet mal am anderen Anschluss einstecken.


    Power per Befehl wieder einschalten ist nicht nötig, da macOS das nach dem Sleep automatisch macht.

    Screen Wakener ist im Prinzip auch nur ein Workaround. Ich habe nur einen Sicherheitsmechanismus eingebaut, der vielleicht etwas weiter geht als ein Workaround. Das führt schlimmstenfalls aber schlicht dazu, dass die automatische Konfiguration von Screen Wakener nicht funktioniert, um den Monitor nicht mit Einstellungen zu versehen, die nicht zu ihm passen.


    Wenn ich mir das Ganze aber recht anschaue, übernimmt der im Bundle inbegriffene displayplacer eigentlich den Sicherheitscheck (ich hatte zuerst vor, ein anderes Tool mitzuliefern, bevor ich displayplacer fand). Ich werde den Mechanismus also wohl in einer neuen Version rausschmeißen.


    Aber das gehört eigentlich in den anderen Thread.

    Ich habe mir jetzt doch das AmazonBasics USB Hub gekauft. Es wird von uhubctl einwandfrei erkannt (als zwei Hubs, eins mit USB 2 und eins mit USB 3, wie in der Beschreibung zu uhubctl erwähnt):

    Das Wacom Tablet an Port 1 wird erkannt und ich kann es per uhubctl -a off -p 1 aus- bzw. per uhubctl -a on -p 1 wieder einschalten.


    In der IO Registry sieht das Hub so aus:


    Das Netzteil des Hubs habe ich nicht angeschlossen, die Stromversorgung reicht wie erhofft auch so für das Wacom Tablet.


    Jetzt muss ich das Ganze noch über SleepWatcher konfigurieren, sodass das Tablet automatisch vor dem Sleep aus- und nach dem Wake eingeschaltet wird.


    Außerdem möchte ich das Gehäuse des Amazon-Hubs entfernen und die Anschlüsse mit dem restlichen Innenleben an einem PCI-Slotblech befestigen, damit ich es im Rechner anschließen und die vier Ports praktisch wie interne USB-Anschlüsse nutzen kann.



    EDIT:

    Nach dem Wake per uhubctl -a on -p 1 wieder einschalten ist nicht nötig, da macOS beim Aufwachen wohl automatisch alle Ports mit Strom versieht. Port 1 des 3.0-Hubs ist dann aber „disabled“. Vielleicht, weil das Wacom sich nur über USB 2.0 verbindet (?)

    Ich kann es vor dem Sleep aber mit uhubctl -a off -el 20-6 -p 1 ausschalten, dann wird nur Power für USB 2.0 und nicht für USB 3.0 ausgeschaltet.

    Solange du Auto-Login aktiviert hast, kannst du zum Testen mit SleepWatcher meinen Skript in /Applications/Screen\ Wakener.app/Contents/Resources/org.mabam.ScreenWakener.sh verwenden.


    Wenn es so läuft, wie es soll, ist es aber „sauberer“, ein paar Sachen aus dem Skript rauszuschmeißen. Allerdings verweist der Skript auch auf

    /Applications/Screen\ Wakener.app/Contents/Resources/ScreenWakenerLogSwitch,

    /Applications/Screen\ Wakener.app/Contents/Resources/ScreenWakenerPrefs und

    /Applications/Screen\ Wakener.app/Contents/Resources/displayplacer.


    Die Befehle zum Loggen kannst du dann rausschmeißen, wodurch die erste Zeile überflüssig wird. Wenn du die Preferences fest in den Skript einbaust, ist die zweite Zeile auch überflüssig. Ohne displayplacer in der dritten Zeile geht aber gar nichts. Den könntest du aber auch nach /usr/local/bin kopieren und root:wheel als Owner setzen, damit auch die dritte Zeile unnötig wird und du ScreenWakener.app komplett löschen kannst.


    Wenn dein Test mit SleepWatcher erfolgreich ist und du brauchst Hilfe, um den Skript für dauerhaften Betrieb „sauber“ einzustellen, dann gib bescheid.



    Danke für die Ausgabe des Skripts. Wenn ich diese Änderung einbaue, sollte auch die automatische Konfiguration von Screen Wakener auf deinem Rechner laufen. Ich habe aber von jemand anderem die Rückkopplung, dass dieser Teil-Skript auf seinem Rechner nicht läuft. Das muss ich mir also nochmal anschauen.


    Um Screen Wakener auch zum Aktivieren nach Sleep verwenden zu können, könnte ich SleepWatcher darin einbauen und in einem der Dialoge eine entsprechende Option anbieten. Weiß noch nicht, ob ich das mache. Erstmal möchte ich schauen, dass er auf allen Macs/Hacks lauffähig ist.

    Naja, wenn ein Dirty Hack funktioniert, darf es von mir aus auch ein Dirty Hack sein. Nur fliegt die Tastatur dann auch raus und kann ich den Rechner damit nicht mehr aufwecken, was ich eher doof fände.


    Ich glaube, es liegt wirklich am Wacom. Andere berichten vom selben Problem, auch unter Windows.


    EDIT:

    Es liegt definitiv am Wacom. Wenn es nach dem Wake aus bleibt (also das Lämpchen am Wacom nicht leuchtet), funktioniert es zwar nicht, aber es hat Strom und wird im System erkannt:

    Code
    1. $ uhubctl
    2. Current status for hub 20-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports]
    3. Port 1: 0103 power enable connect [056a:0374 Wacom Co.,Ltd. Intuos S 8BH00R2024087]
    4. Port 2: 0100 power
    5. Port 3: 0100 power
    6. Port 4: 0100 power



    Ein Gedanke:

    Wenn ich eine zusätzliche USB-Karte einbaue, die nur mit einem separaten Treiber funktioniert, dann müsste ich diesen doch per Skript unloaden und loaden können und damit das Problem beheben, oder?

    Nur welche Karte funktioniert nur mit separatem Treiber? Hat da wer einen Tipp?



    EDIT:

    Mal von hinten nach vorne aufgerollt:

    • Laut Systeminformationen benötigt das Tablet 500 mA.
    • Ohne eingesteckten Netzadapter ist das genau das Maximum, das das „AmazonBasics USB Hub 3.0 mit 4 Ports“ liefern kann.
    • Laut https://github.com/mvp/uhubctl ist das „AmazonBasics USB Hub 3.0 mit 4 Ports“ eines der wenigen USB-Hubs, bei dem sich USB Power sogar je Port softwaremäßig ein- und ausschalten lässt.
    • uhubctl kann mithilfe von Homebrew oder MacPorts auf macOS installiert werden und dient als Command Line Tool, um den Strom der USB-Ports ein- und auszuschalten.

    Ich glaube, ich habe einen bezahlbaren Workaround für mein Problem gefunden.


    EDIT 2:

    Laut https://github.com/mvp/uhubctl#usb-30-duality-note muss man mit uhubctl und USB 3.0 aufpassen. Das Tablet braucht sowieso nur USB 2.0, also nehme ich vielleicht doch besser das Belkin F5U701-BLK mit USB 2.0.