War Tales

Kamikaze

Warrior of Sunlight
Teammitglied
Dieser Thread ist für all' die Probleme die wir doch noch gelöst haben ohne im Forum um Hilfe zu bitten ...

----

Ich habe ein FreeNAS System mit SUPERMICRO A1SRi-2558F SOC. In letzter Zeit stürzte das System alle paar Wochen mal ab. Da ich per ssh nicht mehr auf das System kam, keine Hinweise in den Logs zu finden waren und ich extra ein Windows booten muss um das IPMI remote KVM zu verwenden habe ich das Problem erst mal für eine Weile ignoriert. Die Ursache für die Probleme waren übrigens die reudigen SATA Power-Stecker, was ich durch gewohnheitsmäßiges alle aus- und wieder einstecken herausgefunden habe. Aber hier geht es um die IPMI Remote Control.

Ignorieren funktionierte bis letzten Freitag, da kam das System dann gar nicht mehr hoch. Es war an der Zeit endlich mal wieder das KVM zu fummeln doch auch unter Windows kam nichts. Ich bin durch alles durch, über die WebUI kam ich zwar in die Web-Oberfläche aber das Java-Applet meldete immer No Signal und die Anzeigefläche blieb immer schwarz. Im Web findet man viele Hinweise mit Java Security Einstellungen und Application cache löschen. Nichts davon hilft.

Dann habe ich die Supermicro ipmitools und die Android App entdeckt aber mit beiden konnte ich mich gar nicht einloggen.

Samstag zurück zu Google. Auf Seite 3 der Suchergebnisse fand ich den entscheidenden Hinweis, dass man bei einigen Supermicro Boards den Headless Modus einschalten muss damit man ohne Monitor und Keyboard ein Bild per Remote KVM bekommt. Außerdem gibt es eine neuere Firmware von Supermicro vor deren Installation aber gewarnt wird da man bei einem Fehler das Board brickt. Inzwischen habe ich aber erst mal entdeckt, dass ich mit dem Android Client und auch den ipmitools reinkomme, wenn ich vom Passwort nur die ersten 16 Zeichen verwende (WTF?!).

Doch auch mit denen funktioniert KVM nicht. Keine Überraschung hier. Der Tag ist inzwischen rum, denn ich war noch auf der hiesigen Artikel 13 Demo. Weiter am Sonntag morgen.

Meine Frau hat noch einen 24" Monitor mit VGA Eingang, den klaue ich mir erst mal während sie mit dem Hund beschäftigt ist. Reboot, kein Bild. Also noch eine Tastatur dran stecken - wieder nichts. Wie komme ich jetzt ins BIOS?!

OK jetzt bin ich verzweifelt genug das Firmware update zu probieren. Gut, dass ich ins beiliegende PDF gesehen habe, in dem drin steht, dass man die per Default gesetzten Haken die alten Einstellungen zu behalten wegmachen soll, sonst würde das System möglicherweise nicht mehr hochkommen. Vertrauenserweckend.
Ich mache die Haken weg, ich werde noch gewarnt, dass ich dann meine Einstellungen verliere. Das sind zum Glück nicht viele, IP-Adresse und das Fan-Profil ändern, weil der eine Fan sonst ständig aus- und angeht und das IPMI den Event log mit Fehlern spammt.
Gespannt warte ich auf das Upgrade, die 32 MiB Firmware geht mit immerhin 5 MBit/s über die Leitung. Nachdem die komplette Firmware übertragen ist, beginnt das eigentliche Upgrade, gespannt beobachte ich den gemächlichen Fortschritt und drücke die Daumen, dass das System noch bootet ….

Das Update ist fertig und siehe da, das neue IPMI kommt sogar mit der alten IP Adresse wieder hoch. Ich probiere Power-On aus und das FreeNAS System bootet und ist erreichbar. Nur der Lüfter geht ständig an und aus. Aber das Problem kenne ich ja schon, das Fan-Profil kann ich direkt am laufenden System per IPMI Web-Oberfläche ändern.

Als nächstes probiere ich wider KVM durch. Windows/Java, ipmitools, Android-Client und neu iKVM/HTML5 - es geht immer noch nichts. Kein Signal.

Ich mache noch mal das Handbuch zum Board auf (PDF) und suche nach der Headless Option. Nichts. Ich suche nach VGA, da findet sich viel und schließlich stoße ich auf die Überschrift VGA Enable Jumper JPG1 allows the user to enable the onboard VGA connector. …. Mist.

Nach der Ersteinrichtung war ich durch alle Jumper durchgegangen und habe alles deaktiviert was ich nicht brauche. Und wer braucht schon VGA, bei einem Headless System. Ich fahre den Rechner runter stecke den Jumper wieder um auf Enable und siehe da, im iKVM taucht beim Power-On der BIOS boot screen auf.

Happy End, dank neuem iKVM/HTML5 Client habe ich jetzt auch unter FreeBSD KVM Zugang, ganz ohne Java.

2019-03-24 iKVM.png
 
Erinnert mich an ein iLO welches ich aus einer Windows VM mit Java steuern musste. Das gelang jedoch erst nachdem ich in den Windows Umgebungsvariablen eingestellt habe, dass Java auf hardwarebeschleunigtes Rendering verzichten solle.
 
Na, das ist ja (mal wieder) eine Reise durch den Hardware-Djungel... schön, dass Du es lösen konntest :)
Sowas habe ich auch hin-und-wieder... Schade nur, dass es oft so viele Standards gibt... die ja sowieso unterschiedlich sind.
VG aus Münster, Norbert
 
Erinnert mich an ein iLO welches ich aus einer Windows VM mit Java steuern musste. Das gelang jedoch erst nachdem ich in den Windows Umgebungsvariablen eingestellt habe, dass Java auf hardwarebeschleunigtes Rendering verzichten solle.

Schön, dass das Gras auf der anderen Seite nicht grüner ist. Ich musste mir Jahre eine XP VM inkl. Java 7 halten für ein älteres DRAC.
 
Hab nur was weitläufig BSD (weil MacOS+Virtualbox+Packer+OpenBSD) mässiges das sich kürzlich zugetragen hat:
Das packer json hat eine weile lang (so 1,5 bis 2 Jahre) weit überwiegend klaglos funktioniert. Das Packerfile erstellt eine virtuelle Maschine und führt eine Script installation mit einer install??.iso durch. Beim Wechsel zu einem neuen Mac, Virtualbox6 und dem neusten Packer und ich meine auch das es grad beim schwenk von OpenBSD current 6.4 zur beta 6.5 war, rannte die Installation plötzlich in eine naja nicht wirklich Fehlermeldung. Im terminal Fenster stand ein unschuldiges "Waiting for ssh connection" aber in der Virtuellen Maschine war die Hölle los. Eine Zeile lief Amok. Irgendwas von wegen er könne das Netzwerk Device nicht konfigurieren...
und dann natürlich prompt an der falschen Stelle den Weg der Fehlersuche begonnen... das installieren von Hand ist NORMALERWEISE der erste Schritt und auch richtig wenn eine Automatisierung nicht funktioniert, hier hat es nur Zeit gekosten, weil: da funktionierte das ganze und ich war soweit wie vorher (dachte ich, weil ich es als einzige Fehlerquelle in Betracht zog). Ich war schon drauf und dran eine Frage zu schicken... warum etwas von Hand funktioniert aber aus dem Script nicht wobei es vorher immer funktionierte (also erstmal schön OpenBSD den Fehler untergeschoben).
Erst nach einer Weile kam ich drauf, mir die Virtuelle Hardware mal genauer an zu schauen. Und siehe da, die Netzwerk Karte fehlte ja schon dort! Aber nur wenn man virtuelle Maschinen per CLI erstellen lässt... ein riesiger Vorteil von physischer Hardware, da sieht man sowas wesentlich schneller.
Entweder kam es von irgendeiner meiner Konfigurationsversuchen oder das wurde bei Oracle geändert... kann und will ich nicht mehr nachvollziehen.
Ich hab bestimmt ne Stunde gebraucht, die richtige Dokumentation zu finden... Um eine klitzekleine Modifikation zu suchen die ich jetzt benötige und vorher eben nicht benötigte:

JSON:
    [
      "modifyvm",
      "{{.Name}}",
      "--nic1",
      "nat"
    ]
Weil ich irgendwie immer wieder was anderes wichtigeres zu tun hatte... hat sich die ganze Sache über mehrere Wochen erstreckt... und ist erst seit letzte Woche Samstag endgültig gelöst.
 
Vor einigen Tagen meldete sich meine Mutter, dass ihr Laptop nur noch "Operating systm not found" anzeigen würde. Das Drama mit SSDs der ersten Generationen schon kennend, fragte ich sie, ob sie ein Backup hätte. Sie wollte mal wieder eines machen, natürlich. Ich habe ich das Laptop dann bekommen und es mit viel Mühe und Not zerlegt. Es ist ein älteres Sony, völlig verbastelt mit fünf Arten von Schrauen, Plastikclips überall und ganz besonders idiotisch RAM, SSD und CD-ROM zwischen Mainboard und Tastatur...

Die SSD selbst war ein Intel Cherryville OEM-Modell, wahrscheinlich baugleich mit der Intel 520 480GB. Die Intel 520er Serie war die Serie, mit der sie ihre Marktführerschaft bei SSDs verloren haben, denn anstatt weiterhin eigenen Controller mit eigener mehr oder weniger funktionierender Firmware zu bauen, setzten sie von dort an auf Sandforce-Controller mit einer laut Marketing optimierter, in der Realität aber wohl kaum veränderter Firmware. Damit hatten die Intel 520er die gleichen Probleme wie alle anderen Sandforce-SSDs auch, plötzlich aussteigende Controller, sich selbst zerschießende Firmware und so weiter. Allerdings nicht in dem Ausmaß, wie zum Beispiel OCZ oder PNY, die ebenfalls auf den Controller setzten. Hinzu kam die lustige Geschichte mit dem AES-256, was wohl maximal AES-128 war. Egal. Zumindest ist es ein mittleres Wunder, dass die SSD solange gehalten hat, die Intel 520er in der Firma sind bis auf wenige Überlebende lange tot.

Nun sind Sandforce-Controller recht speziell und die meisten Datenrettungsfirmen lehnen die SSDs ab. Sogar die von Intel empfohlenen Firmen meinten sofort "Njet". Nur ein Labor in Griechenland hätte es sich anschauen wollen, aber die wollten alleine für den Versuch ohne jede Erfolgsgarantie schon 1900€ haben. So wichtig sind die Daten dann doch nicht. Also blieb nur Hilfe zur Selbsthilfe.

Leider wurde die SSD, eigentlich untypisch für Sandforce, überhaupt nicht mehr erkannt und auch die klassischen Tricks wie 20 Minuten nur Strom anschließend und dann S-ATA einstecken halfen nichts. Auch der große "Power Cycle Trick", also 30 Minuten nur Strom, 30 Sekunden abklemmen, wieder 30 Minuten Strom, wieder 30 Sekunden abklemmen, dann erst S-ATA gefolgt von Strom zeigte keine Wirkung. Es wunderte mich, denn der Trick kommt der Legende nach von einem Corsair-Ingenieur und hat mir tatsächlich bisher jede Sandforce-SSD zumindest soweit wiederbelebt, dass sie auf ATA-Kommandos reagierte. Ich habe sie dann noch eingefroren. Ich halte es zwar für ein Gerücht, aber angeblich soll das NAND lesbarer machen und schaden konnte es nicht. Allerdings half es wenig überraschend auch nicht.

Damit war ich mir ziemlich sicher, dass die Hardware selbst defekt war. Also erst die Sicherungen durchgemessen, das Board schien aber, soweit man es denn sagen kann, Strom zu bekommen. Also die Heißluftpistole, was wieder nicht half. Wobei es der oft auch an Wumms fehlt. Dann habe ich, zugegeben etwas mit dem Mut der Verzweifelten, die SSD bei 230°C für 8 Minuten gebacken, bis das Lot geschmolzen war und sie anschließend 60 Minuten auskühlen lassen. Die Platine war danach ziemlich verfärbt, aber zumindest die Anschlüsse nicht verzogen. Und tatsächlich wurde die SSD nach mehrmals Strom ein- und wieder ausstecken erkannt! Yeah!

dd_rescue legte dann auch erfolgreich los, allerdings mit sehr langsamen 10MB/s und der SMART-Wert für korrigierbare ECC-Fehler schoss durch die Decke. 230°C waren vielleicht etwas heiß, aber Schmelzpunkt und so. Das Auslesen dauerte etliche Stunden und dabei zeigte sich schnell, dass jeder achte 4096 byte Block nicht gelesen werden kann. Dem Platinenlayout nach könnte der Controller über acht Kanäle mit dem Flash verbunden sein, weshalb die Vermutung nahe lag, dass einer der Kanäle tot war. Hier war sehr positiv, dass Sandforce anscheinend nur normale 4096 Byte Blöcke verteilt und nicht die Blöcke an sich noch auf die einzelnen Kanäle splittet.

Das Ergebnis war dann ein Image, was für ntfs-3g zu kaputt war, in dem photorec aber viele Daten fand. Damit hätte man schon leben können, aber so auf gut Glück rausgekratzte Daten sind ja immer so eine Sache. Also zurück in den Ofen, noch einmal 8 Minuten bei 230°C. Dazu habe ich ein kleines Programm geschrieben, was jeden achten Block liest. Und tatsächlich, mit unter 1MB/s und sehr, sehr viel Geduld bekam es einen Großteil der Blöcke. Die Blöcke anschließend in das Image einzubauen war einfach, ntfs-3g konnte das Image immerhin read-only weitgehend auslesen.

Zum Muttertag gibt es eine neue Corsair MX500 500GB und eine 2,5" Backup HDD.
 
Gelöst ohne zu fragen? Das kommt gar nicht soo selten vor :)

Ich würde gern mal schauen, ob ich "electron apps" auf meinem FreeBSD Desktop zum laufen kriege -- also z.B. das neue Skype, Visual Studio Code, usw. Mal sehen ob das noch was wird. Jedenfalls braucht man da als erstes mal: electron. Gesucht und diesen Port gefunden: https://github.com/tagattie/FreeBSD-Electron

Tja, der wollte bei mir in Poudriere nicht bauen. Es stellte sich heraus, dass es daran liegt, dass er mit "npm install" jede Menge node.js Pakete in der fetch-Phase nach $TMPDIR zieht (und die sicherheitshalber vorher löscht). Poudriere macht per default "fetch" als root, aber ab "extract" als non-root, und da nirgends geschaut wird, ob die Pakete schon da sind, führt extract in Poudriere alles nochmal aus, nur diesmal darf ich nicht löschen, was vorher root geschrieben hat... logisch.

Schaut man genauer hin ist es für einen Port sowieso grundfalsch, irgendwas irgendwo außerhalb von $WRKDIR (und, während fetch, $DISTDIR) zu schreiben. Also wie löst man das? Man baut sich selbst ein Distfile aus dem, was npm so gezogen hat. Ich hatte natürlich bei dem Port schon ein issue aufgemacht, und der Autor hat immerhin das Kommando "npm ci" hervorgekramt, das angeblich einen absolut reproduzierbaren "node_modules" Baum aufbaut.

Nur, wie baut man aus diesem Baum jetzt ein absolut reproduzierbares Distfile (tarball)? Tar archiviert ja auch so Dinge wie uid, gid, timestamps, außerdem weiß man normalerweise nicht, in welcher Reihenfolge die Files im Archiv landen ... und ein Distfile wird schließlich beim entpacken mit SHA256 gecheckt, das muss aufs Byte korrekt sein ;)

Lösung: mtree! Cooles tool :)

Code:
mtree -cbnSp npm_modules | mtree -C | sed \
    -e 's:time=[0-9.]*:time=1557238990.000000000:' \
    -e 's:\([gu]id\)=[0-9]*:\1=0:g' \
    -e 's:^\.:./npm_modules:' > npm_modules.mtree; \
tar cJf ${DISTDIR}/electron-npm-modules-${ELECTRON_VER}.tar.xz @npm_modules.mtree

Das erstellt zunächst mal aus dem Pfad "npm_modules" eine mtree Beschreibung, bereits sortiert (Option -S), konvertiert die dann mit "mtree -C" in ein simpleres Format, und dann wird mit sed angepasst: Alle Files bekommen in der Beschreibung den gleichen fixen Timestamp, alle Files bekommen uid/gid 0 (root:wheel), und vor jeden Pfad wird "./npm_modules" gehängt, weil mtree als Basis immer "." ausgibt. Die entstandene Beschreibung kann man "tar" mit @ als Eingabe geben, dann werden die Files entsprechend der mtree-Beschreibung ins Archiv genommen. Ergebnis: Absolut reproduzierbares Archiv, vorausgesetzt man hat einen Baum mit den gleichen Files :)
 
Vor einigen Tagen meldete sich meine Mutter, dass ihr Laptop nur noch "Operating systm not found" anzeigen würde. Das Drama mit SSDs der ersten Generationen schon kennend, fragte ich sie, ob sie ein Backup hätte. Sie wollte mal wieder eines machen, natürlich. Ich habe ich das Laptop dann bekommen und es mit viel Mühe und Not zerlegt. Es ist ein älteres Sony, völlig verbastelt mit fünf Arten von Schrauen, Plastikclips überall und ganz besonders idiotisch RAM, SSD und CD-ROM zwischen Mainboard und Tastatur...

Die SSD selbst war ein Intel Cherryville OEM-Modell, wahrscheinlich baugleich mit der Intel 520 480GB. Die Intel 520er Serie war die Serie, mit der sie ihre Marktführerschaft bei SSDs verloren haben, denn anstatt weiterhin eigenen Controller mit eigener mehr oder weniger funktionierender Firmware zu bauen, setzten sie von dort an auf Sandforce-Controller mit einer laut Marketing optimierter, in der Realität aber wohl kaum veränderter Firmware. Damit hatten die Intel 520er die gleichen Probleme wie alle anderen Sandforce-SSDs auch, plötzlich aussteigende Controller, sich selbst zerschießende Firmware und so weiter. Allerdings nicht in dem Ausmaß, wie zum Beispiel OCZ oder PNY, die ebenfalls auf den Controller setzten. Hinzu kam die lustige Geschichte mit dem AES-256, was wohl maximal AES-128 war. Egal. Zumindest ist es ein mittleres Wunder, dass die SSD solange gehalten hat, die Intel 520er in der Firma sind bis auf wenige Überlebende lange tot.

Nun sind Sandforce-Controller recht speziell und die meisten Datenrettungsfirmen lehnen die SSDs ab. Sogar die von Intel empfohlenen Firmen meinten sofort "Njet". Nur ein Labor in Griechenland hätte es sich anschauen wollen, aber die wollten alleine für den Versuch ohne jede Erfolgsgarantie schon 1900€ haben. So wichtig sind die Daten dann doch nicht. Also blieb nur Hilfe zur Selbsthilfe.

Leider wurde die SSD, eigentlich untypisch für Sandforce, überhaupt nicht mehr erkannt und auch die klassischen Tricks wie 20 Minuten nur Strom anschließend und dann S-ATA einstecken halfen nichts. Auch der große "Power Cycle Trick", also 30 Minuten nur Strom, 30 Sekunden abklemmen, wieder 30 Minuten Strom, wieder 30 Sekunden abklemmen, dann erst S-ATA gefolgt von Strom zeigte keine Wirkung. Es wunderte mich, denn der Trick kommt der Legende nach von einem Corsair-Ingenieur und hat mir tatsächlich bisher jede Sandforce-SSD zumindest soweit wiederbelebt, dass sie auf ATA-Kommandos reagierte. Ich habe sie dann noch eingefroren. Ich halte es zwar für ein Gerücht, aber angeblich soll das NAND lesbarer machen und schaden konnte es nicht. Allerdings half es wenig überraschend auch nicht.

Damit war ich mir ziemlich sicher, dass die Hardware selbst defekt war. Also erst die Sicherungen durchgemessen, das Board schien aber, soweit man es denn sagen kann, Strom zu bekommen. Also die Heißluftpistole, was wieder nicht half. Wobei es der oft auch an Wumms fehlt. Dann habe ich, zugegeben etwas mit dem Mut der Verzweifelten, die SSD bei 230°C für 8 Minuten gebacken, bis das Lot geschmolzen war und sie anschließend 60 Minuten auskühlen lassen. Die Platine war danach ziemlich verfärbt, aber zumindest die Anschlüsse nicht verzogen. Und tatsächlich wurde die SSD nach mehrmals Strom ein- und wieder ausstecken erkannt! Yeah!

dd_rescue legte dann auch erfolgreich los, allerdings mit sehr langsamen 10MB/s und der SMART-Wert für korrigierbare ECC-Fehler schoss durch die Decke. 230°C waren vielleicht etwas heiß, aber Schmelzpunkt und so. Das Auslesen dauerte etliche Stunden und dabei zeigte sich schnell, dass jeder achte 4096 byte Block nicht gelesen werden kann. Dem Platinenlayout nach könnte der Controller über acht Kanäle mit dem Flash verbunden sein, weshalb die Vermutung nahe lag, dass einer der Kanäle tot war. Hier war sehr positiv, dass Sandforce anscheinend nur normale 4096 Byte Blöcke verteilt und nicht die Blöcke an sich noch auf die einzelnen Kanäle splittet.

Das Ergebnis war dann ein Image, was für ntfs-3g zu kaputt war, in dem photorec aber viele Daten fand. Damit hätte man schon leben können, aber so auf gut Glück rausgekratzte Daten sind ja immer so eine Sache. Also zurück in den Ofen, noch einmal 8 Minuten bei 230°C. Dazu habe ich ein kleines Programm geschrieben, was jeden achten Block liest. Und tatsächlich, mit unter 1MB/s und sehr, sehr viel Geduld bekam es einen Großteil der Blöcke. Die Blöcke anschließend in das Image einzubauen war einfach, ntfs-3g konnte das Image immerhin read-only weitgehend auslesen.

Zum Muttertag gibt es eine neue Corsair MX500 500GB und eine 2,5" Backup HDD.

Ich bin ja total begeistert von der Geschichte und man halte mich jetzt bitte nicht für ironisch, ich meine meine Fragen tatsächlich ernst!
Die Sache mit dem Backofen scheint mir ja hier ein wichtiger Punkt (den ich mich niemals getraut hätte). Ich meine, die Dinger regeln doch die Temperatur nur so ungefähr. Abweichungen von 10 oder 20K sind doch eher normal. Meine beiden Backöfen regeln jedenfalls deutlich unterschiedlich und deshalb ist auch das Backergebnis unterschiedlich, bzw musste ich lernen, in welchem Backofen welche Einstellung zum Erfolg führt.
Nun sehen wir die tatsächliche Temperatur mal weniger als Problem, es geht hier ja entscheidend auch um die Energiemenge.
Wie sieht das genau aus?
Du zerlegst die SSD erst, so dass nur die Platine mit Anschlüssen übrig bleibt.
Dann heizt du den Backofen vor, mit Umluft?
Dann die Platine rein, direkt aufs Blech? Oder eine andere Konstruktion? Etwa hängend? Oder Bauteile nach oben?, damit sie von der Schwerkraft irgendwie in Richtung Anschluss gedrückt werden?
Dann acht Minuten warten, oder auch hinsehen, ob der Schmelzvorgang stattfindet?
Danach ist die Platine heiß? Greifst du die mit einer Zange? Oder nimmst du das komplette Backblech raus oder öffnest du nur den Ofen und wartest?

Nochmal: ich meine das wirklich ernst und bin an zusätzlicher Information interessiert.
 
Erstmal muss man sich klarmachen, dass ich an dem Punkt war, wo nichts mehr zu verlieren war. Die SSD gab keinen Mucks von sich, eine professionelle Datenrettungs kam nicht in Frage. Es ging also nur noch darum, sowieso schon verlorene Daten etwas weniger verloren zu machen. Solange es noch irgendeine andere Möglichkeit gibt, sollte man eine SSD auf gar keinen Fall in den Backofen legen oder ähnliche Dinge damit machen.

Ich habe mich früher viel mit High-End-Grafik beschäftigt. In den 2000ern waren die richtig bösen High-End-Karten im epischen Wettkampf um die Performancekrone bis an die absolut äußersten Grenzen des technisch Machbaren überzüchtet. Für mich war der Höhepunkt eine Asus Geforce 6800 Ultra mit Werksübertaktung. Die GPU hatte so gut wie kein Powermanagement, Asus hatte die Kernspannung bis an den Anschlag gezogen, um den Takt so weit wie irgendwie möglich hochzubekommen. Das Ergebnis waren auch mit brachialem Kühlkörper ca. 120°C unter Volllast, jenseits der Grenze, was man einem Siliziumchip und der Verlötung zwischen Chippackage und PCB dauerhaft zumuten kann. Im Betrieb schwankte die Karte so zwischen 70°C und den 120°C, diese etwa 50°C sind eine massive mechanische Belastung. Entsprechend verreckten solche Karten meistens nach 2 bis 3 Jahren, die GPU oder selten auch der VRAM löteten sich buchstäblich selbst aus. Ein beliebter Trick war, die Karte zu demontieren und das PCB in den Backofen zu legen, damit sich die Lötstellen wieder schließen. So kam ich überhaupt erst auf die Idee.

Und das Netz findet dazu auch was, zum Beispiel: https://dfarq.homeip.net/baking-ssds-the-ssd-oven-trick/

Das meiste bleifreie Lot hat einen Schmelzpunkt zwischen ca. 215°C und 225°C. 230°C sollten es damit schon sein, um einigermaßen sicher drüber zu kommen. Wie @pit234a sagt sind Backofen nicht so wirklich genau. Andererseits sind so Temperaturen gar nicht gut für die Komponenten und schon gar nicht für die in den NANDs gespeicherten Daten. Da viele Artikel 8 Minuten empfohlen, habe ich sie einfach übernommen. Eventuell hätten aber auch 6 oder sogar nur 4 Minuten gereicht. Wesentlich länger als 8 Minuten würde ich aber auf keinen Fall gehen wollen, wenn ich mir so anschaue, wie sich das PCB verfärbt hat und wie viel Mühe der Controller hatte die Daten noch zu lesen.

Und ein echter Reflow-Ofen ist definitiv besser, aber sowas hat man meistens nicht im Keller und ich wüsste auch nicht, wo ich einen herbekommen sollte. Hier sind nicht mal Unternehmen in der Nähe, wo man mal fragen und 20€ für die Kaffeekasse spenden könnte.

Ich habe dann eine Auflaufform mit flachem Boden genommen, da eine Alufolie rein gelegt und die Platine der SSD (also nicht das ganze Gehäuse, wirklich nur die Platine selbst) raufgelegt. Dabei drauf geachtet, dass sie wirklich komplett aufliegt und nirgends frei schwebt. Um zu verhindern, dass SMDs der Schwerkraft folgend abfallen können. Die Auflaufform habe ich mit Deckel drauf auf ein Backblech in der Mitte des kalten Ofens gestellt, in der Hoffnung, dass giftige Ausdünstungen größtenteils in der Form bleiben. Dann 230°C Ober- und Unterhitze und gewartete, bis die Heizleuchte ausging. Von da an 8 Minuten, während dessen immer wieder mit einer Taschenlampe geschaut, ob das Lot schmilzt. Das sieht man, es beginnt sehr hell zu glänzen. Nach den 8 Minuten den Ofen abgestellt und die Tür aufgemacht, es 60 Minuten auf Raumtemperatur abkühlen lassen. Auf gar keinen Fall irgendwas bewegen, solange das Lot flüssig ist. Man riskiert nur, dass sich SMDs verschieben. Zum Schluss habe die Auflaufform im Freien geöffnet und sehr gründlich ausgewaschen, außerdem den Ofen ausgewischt.

Die Idee ist schon grenzgenial.. aber einfach? Mir fehlt da vor dem 2. Kaffee der Ansatz (ausser was in C selber zu bauen).
Man kann da bestimmt was Lustiges in Shell-Script und dd frickeln, aber ich habe es in Go gemacht. In C wäre es: Einen Buffer von 8 Blöcken zu je 4096 Byte anlegen. fread() auf 7 Blöcke aus Image A, fread() auf einen Block in Image B. Die 8 Blöcke per fwrite() ins Zielimage schreiben. Anschließend fseek() um einen Block nach vorne in Image A, um den aus Image B gelesenen Block zu überspringen. Dann wieder von vorne.
 
Die Idee ist schon grenzgenial.. aber einfach? Mir fehlt da vor dem 2. Kaffee der Ansatz (ausser was in C selber zu bauen).
Naja dazu muss man wohl etwas programmieren, aber Daten an festen Stellen in einem File überschreiben ist auch keine Raketenwissenschaft ;) Da finde ich die "Rettung durch backen" doch viel bemerkenswerter ;)

Es wäre allerdings möglich, dass "recoverdisk" die Vorgehensweise quasi "generisch automatisiert" hätte -- das Tool führt sich selbst eine Liste, was es noch nicht lesen konnte, und versucht das später wieder. Habe damit vor kurzem so gut wie vollständig Daten von einer beschädigten USB Platte meiner Frau gerettet :)
 
"recoverdisk" kannt ich wirklich nicht. Das wird für das nächste Mal notiert. :)
 
Coole Geschichte, sowas kenne ich! :)

Du tust was du tust, andere Leute sehen dich als vermummten H4xx0r-Ninja vorm Monitor, schwarzer Hintergrund, grüne Matrix-Schrift bewegt sich. :p

Leider erzieht das die Betroffenen dazu in Zukunft erneut, das Backup zu vernachlässigen....weil 'man kanns ja doch immer wieder retten'. Bei Familie ist das ja noch pikanter zu überzeugen mit Zwangsbackup. ;)

Und ein echter Reflow-Ofen ist definitiv besser, aber sowas hat man meistens nicht im Keller und ich wüsste auch nicht, wo ich einen herbekommen sollte.

Was ist das für ein Ofen?
Wir hatten letztes Jahr ein Dentallabor geräumt. Da waren kleine Öfen dabei, womit sie vermutlich die Goldkrümel auf/in die Implantate schmolzen.
Falls davon noch einer da ist, hätte ich dir für kleines Geld was angeboten, aber ich habe grade nach dem Schmelzpunkt von Gold geguckt, womit das hinfällig ist. :p
 
Ich konnte mit dem Backofen Trick auch mal Daten von einer mechanischen HD retten. Nach einem fallschaden ging erstmal nichts mehr, nach kurzem "aufbacken" wurde sie wieder erkannt und zumindest ein paar Daten ließen sich noch runter kratzen.
 
Was ist das für ein Ofen?
Die sind spezielle Öfen zum Neu- und Wiederverlöten von SMDs. Die Idee ist, dass die Platine mit klebriger Lötpaste bestrichen wird, man die SMDs auf die Paste klebt und anschließend allles zusammen im Ofen so weit erhitzt, dass die Lötpaste schmilzt und die SMDs sich dadurch einlöten. Der Unterschied zum Backofen ist, dass solche Öfen besser kontrollierbare Wärmeabgabe per Heißluft oder Infrarot haben und damit nicht die Platine totgrillen. Aber da können echte Elektroniker sicher viel mehr zu sagen.
 
Notfalls kann man auch ein guenstiges Backofenthermometer nutzen. Damit kann man die Temperatur des Backofens recht genau im Auge behalten und noetigenfalls nachregulieren.
 
In der Tat habe ich selten einen Ofen gesehen, der nicht ausschließlich grob regulierbar war.

Da 'kein Backup' ja öfters vorkommt, sollte man die Marktnische mit den SSDs vllt. abdecken. :p
 
Lösung: mtree! Cooles tool :)

Code:
mtree -cbnSp npm_modules | mtree -C | sed \
    -e 's:time=[0-9.]*:time=1557238990.000000000:' \
    -e 's:\([gu]id\)=[0-9]*:\1=0:g' \
    -e 's:^\.:./npm_modules:' > npm_modules.mtree; \
tar cJf ${DISTDIR}/electron-npm-modules-${ELECTRON_VER}.tar.xz @npm_modules.mtree
Tja und dann probiert es jemand anders aus und man stelllt fest, dass sich auch noch flags unterscheiden können, verflixt ;) Also, nochmal "lesson learned" -- wirklich auch auf verschiedenen Maschinen reproduzierbar ist folgendes:

Code:
mtree -cbnSp npm_modules | mtree -C | sed \
    -e 's:time=[0-9.]*:time=1557238990.000000000:' \
    -e 's:\([gu]id\)=[0-9]*:\1=0:g' \
    -e 's:flags=.*:flags=none:' \
    -e 's:^\.:./npm_modules:' > npm_modules.mtree; \
tar cJf ${DISTDIR}/electron-npm-modules-${ELECTRON_VER}.tar.xz @npm_modules.mtree
 
Zurück
Oben