Warum man den Bose Flugzeugadapter verwenden sollte…

…auch wenn im Flugzeug eine Stereo-Klinke vorhanden ist.

Gemeint ist dieses Kerlchen hier:

Neben dem mechanischen Umsetzung beinhaltet der Adapter Spannungsteiler, die eine Dämpfung einfügen. Dadurch werden bei PAs (Durchsagen), deren Lautstärke man in aller Regel nicht unter einen bestimmten Wert einstellen kann, hoffentlich nicht mehr die Trommelfelle rausgeblasen.

Beim QC35 ist der Adapter noch dabei, warum Bose ihn beim Nachfolger QC35 II zu einem höheren Preis (der Google Assist-Taster rechtfertigt diesen IMHO nicht) weggelassen hat, erschließt sich mir nicht.

Seid vorsichtig!

Es ist verdammt kalt draußen. Am 27.02.2018 um 20:40 Uhr zeigt das Thermometer -13 °C. Es ist verdammt trockene Kälte. Die Heizungen und Klimaanlagen leisten zusätzlich noch ihren Beitrag. In meinem „Empire of dirt“/“Nerdcave“ herrschen 19 % relative Luftfeuchte, so man dem Hygrometer überhaupt noch trauen kann. In der Arbeit waren es heute morgen (gleicher Sensor und Disclaimer) 17 % rH. Dank ESD-Schlappen und leicht ableitenden Böden hat es dort nie gebritzelt. Es wäre mitunter teuer wenn doch. Nur die Schleimhäute und Hände leiden massiv unter der extrem trockenen Luft.

Daheim habe ich aufgehört, die Entladungen zu zählen. Auch wenn momentan leider keine Zeit zum Basteln bleibt (zum Glück habe ich im vorletzten Beitrag kein Datum versprochen), musste ich nackte Elektronik anfassen und habe mich dementsprechend oft und gezielt entladen. Obwohl mein Kleiderschrank nur sehr wenige Kleidungsstücke mit Neigung zur Ladungstrennung beinhaltet, hat es bei fast jeder Berührung geknackt.

Daher kann ich nur raten: Seid aktuell vorsichtig beim Basteln! Macht nichts kaputt und ärgert euch so richtig, wenn es doch passiert. Ich hab euch gewarnt 🙂

Die Anschaffung einer ESD-Matte kann kann günstiger sein, als das was man im Zweifel kaputt macht und schont gleichzeitig den Tisch.

Was mir an Trådfri gefällt (und was nicht)

Seit einiger Zeit hängen in meiner Wohnung Lampen von Ikea. Zunächst nur das E27 Starterset mit einstellbarer Farbtemperatur.

Ort der Anwendung: Büro. Dort brauche ich gleichzeitig helles Arbeitslicht, möchte an Programmierabenden aber dimmen können und wärmeres Licht haben. Das von vorne wird schon durch f.lux seiner Blauanteile entledigt.

Die Lampe ist mit 980 Lumen an Wintertagen angenehm hell, der CRI von 80 ist zwar nicht das Beste aber auch nicht das Schlechteste was ich gesehen habe. Für meine Anwendung ist es gut genug.

Die Einrichtung und Bedienung mit der E1524 (die mit den 5 Tasten) ist ganz gut, ein Drücken der Tasten verändert die Farbtemperatur und Helligkeit in Stufen, wenn man länger drückt wird langsam auf- bzw. abgedimmt. Das Verändern der Farbtemperatur mit longpress mag mir nicht so gelingen, bin mir aber auch nicht sicher, ob das wirklich funktioniert.

Wenn man die Lampe über die Fernbedienung ausschaltet und den Raum verlässt ist man nicht ganz verloren: Schaltet man den klassischen Lichtschalter aus und wieder an, kommt die Lampe mit der letzten An-Einstellung zurück.

Allerdings fehlt mir eine Option: dimmt man die Lampe komplett herunter, bekommt man sie nur über den Dimmer wieder hell. Schön wäre es, über die Sequenz (Aus) – An – Aus – An in eine vordefinierte Einstellung zu kommen.

Ich war so zufrieden, dass ich mehr wollte. Leider war das Gateway bis Ende Januar nicht lieferbar. Aber dann kam doch die Mail – praktisch, dass mein Arbeitsweg direkt am nächsten Schweden-Möbelhaus vorbeiführt.

Meine Bedenken gegenüber Datenschutz und Calling home haben sich bis jetzt nicht bestätigt. Das Teil nimmt nur aus zwei Gründen Kontakt zum „Mutterschiff“ auf: Firmware-updates und die aktuelle Zeit.

Letztere wird für die Lichtwecker-Funktion verwendet, wo ich auch schon bei der ersten richtigen Kritik bin: Die App zeigt sich bei der Konfiguration derselben etwas zickig. Möchte ich für die Wochentage einen anderen Zeitpunkt als für das Wochenende festlegen (also zwei Wecker parallel laufen lassen), wird gemeckert. Auch lässt sich die Dauer für den Anstieg der Helligkeit sowie Start- und End-Helligkeit und Farbtemperatur nicht einstellen. Es wird einfach auf die letzte An-Helligkeit gedimmt. Wenn man nach dem Aufstehen die Lampe aus- und wieder später wieder einschaltet springt sie auf eine Helligkeit von etwa 30 %. Da muss Ikea nochmal feilen.

Genauso reicht der sonst eigentlich ganz gute Dynamikumfang für den Lichtwecker nicht. Oft wache ich schon vom Einschalten der Lampe (bei geringster Helligkeit) vergleichsweise unsanft aus.

Eine weitere Funktion, die ich nicht verstehe: Zeitgesteuertes ein- und ausschalten. Man kann das Ein- bzw. Ausschalten nur als Zeitraum festlegen, nicht als Zeitpunkt. Das macht es unübersichtlich und verwirrend.

Leider ist selbst die Kernkompetenz der App nicht zu Ende gedacht. Während man die Helligkeit von 0 bis 100 % einstellen kann, gelingt das bei der Farbtemperatur nur in 3 Stufen. Die Lampen können über andere Apps mehr, warum wird das nicht genutzt? Die einfachste und intuitivste Bedienung wäre doch wie folgt:

Zwei Schieberegler und ein Fadenkreuz um beide Parameter gleichzeitig zu ändern. Wo Ikea doch sonst so für Pragmatismus und intuitive Konzepte bekannt ist…

Gleichwohl verstehe ich nicht, warum das Gateway zwar auf Port 80 lauscht aber nicht einfach eine Seite ausliefert, über die man die Lampen steuern kann. Das wäre wirklich plattformunabhängig. Für Windows gibt es z. B. keine Anwendung und wenn ein Bookmark auf dem Handy funktioniert mindestens genauso gut wie eine App, die zusätzlichen Aufwand bedeutet.

Bei der App stört ebenfalls die nicht vernünftige Nutzung des Platzes. Man muss sich durch die Menüs hangeln. Auf dem Handy blöd und auf dem Tablet richtig mistig. Ein einziger Helligkeits-Slider auf einen 10 Zoll Bildschirm aufgeblasen ist zumindest nicht wirklich optimal.

Was seit dem Gateway oder dem durch dessen Verwendung auf den Lampen installierten Update auffällt: die Dinger flackern hin und wieder. Hat zumindest die im Büro vorher nicht gemacht und ist auf der nervig-Skala eine glatte 4 (von 10). Der Mehrwert der Lampe ist größer als der Bug in ihrer Kernkompetenz. Trotzdem unschön. Ikea, fix it.

Heute schon 3244527696 angesurft?

Vermutlich ein alter Hut, aber heute entdeckt – In „Internet für Dummies“ steht wahrscheinlich, dass IP-Adressen die  Telefonnummern des Internets sind.

Als ich beim Eingeben einer lokalen IP in Firefox einen Punkt nicht erwischt habe sah ich, dass Firefox automatisch von Dezimal auf in die IP-üblichen Byteblöcke umrechnet. Also schnell einen lookup gemacht und http:3244527696 eingegeben:

Auch Chrome (naja, nicht ganz – der erwartet  noch // hinter dem Doppelpunkt) und sogar der sonst eher zurückgebliebene Internet Explorer können das.

Vielleicht eine ganz gute Gelegenheit, das Zahlengedächtnis etwas zu trainieren. Leider gibt es nicht mehr allzu viele Server, die keinen Hostname zum Ausliefern brauchen…

Es geht weiter

Zugegebenermaßen: es passiert hier so wenig, dass man in Hinblick auf den vorletzten Post schon fast von falschen Versprechen ausgehen könnte. Aber: Es passiert nicht nichts, es geht einfach nur verdammt langsam voran. (warum muss ich nur an das Zitat „es ist nicht undicht, es läuft über“ denken…?)

Um zu zeigen, dass es nicht ganz Schall und Rauch ist:

Aber das ist nicht alles. Bis wann die Software und der zugehörige Artikel fertig ist, kann ich noch nicht versprechen. Ein paar Wochen halte ich für realistisch 🙂

Das „Custom Programming Tool“ in Atmel Studio

Schon länger gibt es in Atmel Studio die Möglichkeit, ein eigenes Programming tool zu verwenden:

Hat mich bis jetzt nie wirklich interessiert, da ich entweder über einen in-circuit-Programmer (der direkt unterstützt wird) flashe oder FastBoot manuell startete.

Zu viele Klicks bzw. Tastaturakrobatik. Also doch mal mit dem bereits Vorhandenem spielen.

echo „foo“ macht was es soll:

Prima, also kann ich einfach die burn.bat im Projektverzeichnis einfügen und los geht’s!

Nope. Da passt wohl das Arbeitsverzeichnis nicht. Aber wie kommt man ins aktuelle Projektverzeichnis? Zunächst versuchte ich mich an den Platzhalter der „External Tools“. Allerdings wurde „$(ProjectDir)“ zu leer ersetzt.

Hmpf. Für die Buildautomatisierung gibt es noch die Build Events – klickt man dort auf „Edit #-build …“ und dann auf Show Macros, bekommt man eine längere Liste an Platzhaltern:

echo „$(MSBuildProjectDirectory)“ zeigt das aktuelle Projektverzeichnis 🙂

also schnell „$(MSBuildProjectDirectory)\burn.bat“ eingegeben und ab dafür!

Jaa-eein. Die Batch-Datei wird zwar ausgeführt, aber im falschen Arbeitsverzeichnis. Mist.

Eine kurze Suche bei Stack Overflow lässt in das richtige Verzeichnis wechseln:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat

It verks!!1!

Jetzt steht in der dämlichen Batchdatei halt noch der feste Pfad zum Binary und es wird immer die Debug-Config über den UART geschoben. Ein bisschen mehr Makro-Magic und ein %1 an der richtigen Stelle (die zu flashende Datei) mit folgendem Command erledigt den Job:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat „$(Configuration)\$(OutputFileName).hex“

Da in der burn.bat in meinem Fall eh nicht mehr als ein Aufruf von fboot.exe ist, kann die Batch-Datei auch komplett weggelassen werden:

cmd /k pushd $(MSBuildProjectDirectory) & fboot /B57600 /C1 /P“$(Configuration)\$(OutputFileName).hex“

Jetzt müsste man nur noch die Ausgabe des Build und des Custom programming tool gleichzeitig anzeigen können, dann wäre ich richtig happy 😉

PS: Bitte beim Copy & Paste der Befehle die Anführungszeichen manuell ersetzen, WordPress macht sie typografisch korrekt aber funktional kaputt.

Es bewegt sich was

Aber leider etwas langsam.

Ich hab aktuell ein paar Baustellen offen. Zum einen bin ich daran, ein Reverse Engineering an einem Autoradio durchzuführen, um Fehler – die der Hersteller tunlichst nicht fixen will – zu beseitigen. So gut wie alle relevanten Teile des Schaltplans sind rekonstruiert, dabei wurden sogar noch ein paar Designfehler entdeckt.

Leider blockt mich gerade ein wenig die Tatsache, dass die meisten Datenblätter unter NDA liegen und die I2C-Kommunikation zwischen Application Processor und Audioprozessor nicht ganz trivial ist.

Baustelle 2 ist beim Prozeda-Decoder. Nachdem die Anfrage reinkam, ob das auch mit einem Raspberry Pi funktioniert, dachte ich mir: Warum auch nicht? Mit echter Hardware auf dem Tisch, die mir freundlicherweise von einem Besucher bereitgestellt wurde, konnte ich mir ein paar Dinge nochmal genauer ansehen. Es gab auf jeden Fall einen Erkenntnisgewinn, jetzt muss ich es „nur noch“ dokumentieren.

Für den Minichirp gibt es hoffentlich auch bald ein Update, nachdem die ersten Versuche an der Hard- und Software vielversprechend sind. Nur so viel: der aktuelle Projektname lauter „ChirpRF“.

Als ob das nicht schon genug wäre, möchte ich jetzt endlich diese verdammte Wetterstation angehen, nachdem es im Sommer an den nRF-Modulen bzw. deren Durchdringung gescheitert ist, soll es jetzt ein CC1101 richten. Um mit diesem und den Sensoren schneller zu Rande zu kommen, gibt es zusätzlich Randprojekte: USB auf I2C und SPI. Das allerdings mit den Wandlerchips von Microchip, zu denen ich eine gewisse Hassliebe pflege. Beide funktionieren (irgendwie), es fehlt aber auch hier noch die Doku.

Es wird also nicht langweilig. Bis dahin für euch leider mal wieder Warteschleifenmusik…

Alle Passwörter geändert?

tl;dr: Bekommt man eine Mail vom T-Online-Sicherheitsteam, dass der Account für Spam missbraucht wird, darf nicht nur das Passwort für den Webmailer sondern muss auch das zweite für die Nutzung von POP3/IMAP/SMTP geändert werden.

Einer meiner Kunden war eine Spamschleuder.

Freundlicherweise hat die T-Online bzw. die Telekom das gemerkt und eine Mail geschrieben. Darin wird empfohlen, den Rechner nach Malware zu durchsuchen und alle Passwörter zu ändern. So weit so gut. Allerdings war es nicht das erste Mal, dass diese Warnmail gekommen ist.

Also den Rechner gecheckt. Avira, Malwarebytes und Avast fand nix. Auch Spybot Search & Destroy fand nichts. In Currports und Process Explorer war auch nichts zu sehen. Gut, muss nichts bedeuten – wenn ein Rootkit im Spiel ist, fliegt der Krempel unterm Radar.

Laut Kunde kamen vor ein paar Tagen auch einige nicht zuordenbare Zustellungsfehler-Mails. Wie üblich ist auch die Originalmail dabei – einmal eine Fedex-Paketzustellungsmail und das andere mal für einen amerikanischen Internetfax-Provider.

Die Links führen auf eine gehackte WordPress-Installation, dann auf eine kryptische Domain – weiter habe ich den Weg nicht verfolgt.

Interessanter waren da die Mailheader, die Details über den Versand zeigen. Absendezeitpunkt, Hostname und IP des Absenders und das verwendete Mailprogramm.

Nichts passte:

  • Zu dem Zeitpunkt war nach Windows Event Log der PC aus
  • Hostname stimmte nicht zum PC und die IP (Logs vom Router) wurde zum Versendezeitpunkt nicht dem Anschluss zugeordnet – und war auch in einem völlig anderem Range. Geotrace spuckte – wenn man dem nach einer guten Woche nach Versand noch trauen darf – die Westküste der USA aus
  • Als Mailclient war „iPhone Mail“ gesetzt

Gut, der letzte Punkt ist schwach, die anderen deuten sehr stark darauf hin, dass der PC nicht am Spamversand beteiligt war.

Was dann sonst? Schließlich hat mein Kunde lt. eigenen Angaben das Passwort seines Mailaccounts geändert. Das Passwort? Hier liegt der Hund begragen: Bei T-Online-Mailaccounts gibt es zwei Passwörter. Eines für den Webmailer, das man in den dortigen Einstellungen ändern kann (was auch gemacht wurde) und ein zweites für die Nutzung eines lokalen Mailclients. Um dieses Passwort zu ändern, muss in das Kundencenter gewechselt werden.

Dort kann man das Passwort nicht nur ändern, sondern auch einsehen. Einsehen? Einsehen. Es wird also an mindestens einer Stelle im Klartext gespeichert. Nach diversen Datenlecks sollte man eigentlich wissen, dass man das nicht macht…

Das Problem sollte mit dem zweiten geänderten Passwort wohl behoben sein. Wie die Mailadressen-Passwort-Kombination in die Hände von Spammern gelang, konnte ich leider nicht verfolgen, allerdings hat mein Kunde für viele Dienste das gleiche Passwort verwendet. Vermutlich war das das Einfallstor – Identitätsdiebstahl.

Da das sicher nicht der einzige Fall für einen T-Online-Mail-Benutzer war, habe ich das Sicherheitsteam (abuse@) angeschrieben. Zunächst wurde mein Hinweis anscheinend nicht richtig verstanden, da nach den Mailheadern einer der zurückgekommenen Mails gefragt wurde. Auf meine Antwort, dass „alle“ Passwörter geändert werden sollen (in Bezug auf alle Passwörter eines Dienstes), was von den meisten als „alle Passwörter“ der verschiedenen genutzten Dienste missverstanden wird.

Leider habe ich bis jetzt keine Antwort mehr bekommen.

Im Spamfilter ist zumindest nichts hängen geblieben.

Die meisten Daten haben überlebt

Noch ein kleines Update zum letzten Beitrag: Nach vielen On-Off-Zyklen der Festplatte war ddrescue bei 100 % aber doch nicht fertig.

ddrescueview zeigte folgendes:

416,24 GB wiederhergestellt, aber knapp 84 fehlen noch. Hm, das ist ungewöhnlich schlechte Ausbeute, vor allem weil so große Blöcke fehlen. Da muss ich etwas falsch gemacht haben.

Ich höre schon meine alte Ausbildungskollegin schreien „manpage, MANPAGE!!!“

ddrescue läuft mit den Parametern (Reihenfolge zu Dramaturgiezwecken geändert)

-f -r10 -v -n

-f: force overwrite of outfile, braucht man, wenn auf eine Partition geschrieben wird
-r10: Exit after the given number of retry passes
-v: Verbose mode
-n: Skipe the scraping phase

Vielleicht sollte ich das letzte weglassen 😉

Gesagt, getan – und ddrescue läuft weiter. Im Schleichmodus werden die restlichen Daten zusammengekratzt. Um diese Schleichfahrt nicht zu blockieren, habe ich den Knockout meines Scripts auf 2 Stunden gesetzt. Nach ein paar weiteren Tagen sieht es wie folgt aus:

Das würde ich als Erfolg bezeichnen. Mit dem Hintergrund, dass die erste Partition der Platte eine versteckte EFI-Partition mit 200 MB ist, sollten die Userdaten vollständig lesbar sein.

Das Volume ließ sich dann auch wieder mounten. Um auf Nummer sicher zu gehen, habe ich aber trotzdem noch ein Image der Partition gezogen.

dd if=/dev/sdxy of=/media/foo/bar/image.bin bs=64K

macht den Job. Wichtig ist, die Blocksize anzugeben, da sonst gefühlt Byteweise kopiert wird und so der Durchsatz unterirdisch ist – ohne Parameter dümpelte der Kopiervorgang von USB 2.0 nach USB 2.0 mit 4 MB/s herum, mit 64K bei 38 MB/s. Mehr geht über die Schnittstelle fast nicht.

ddrescue. aggressiv.

„Nein“ wäre die richtige Antwort gewesen. „Nein“ zur Frage, ob ich eine Festplatte wiederherstellen kann, die vor meinen Augen nochmal fallen gelassen wurde.

„Macht der das was?“

JA, verdammt nochmal – Festplatten (also „klassische“ mit Magnetscheiben) sind mechanisch empfindliche Komponenten.

Naja. Eine zweite Platte für die Wiederherstellung hat er immerhin schon besorgt, also versuche ich mein Glück. Also ein Live-Linux in das olle Thinkpad geworfen und ddrescue gestartet.

Quelle: 500 GB 2,5 Zoll Western Digital Blue, Ziel: 1 TB 2,5 Zoll Seagate.

Zunächst ging es auch ordentlich schnell und ich dachte, der begrenzende Faktor wäre das USB 2.0 am Rechner. Doch auch mit der extra georderten USB 3.0 Expresscard ging es nach ein paar Klimmzügen (zusätzliche Versorgung der Festplatten) nicht wirklich schneller.

Nach den ersten paar Gigabyte sackte die Leserate aber auf mehrere 100 kByte/s ab. Nicht so schlimm, wäre da nicht folgendes Geräusch:

(das nach 10 Sekunden)

Wäre da nur das Geräusch, könnte man vielleicht noch damit leben, aber ddrescue macht nur noch eines: Fehler für Runde zwei melden. Das bringt einen nicht weiter. Also Platte weg und wieder ran. Die ersten paar Stunden mache ich das noch manuell, dementsprechend haben sich knapp 100 GByte Lesefehler und ein wenig Frustration angesammelt. Grmpf. Dabei fiel auf, dass die ersten 30 Sekunden die Übertragungsrate mit 15-30 MByte/s noch relativ hoch war, danach sank sie schlagartig ab und schwankte zwischen 65 und 300 kByte/s.

In einer Woche (Abends, musste in der Nähe sein) kamen so etwa 90 GByte von Platte A auf Platte B. 150 GByte wurden als nicht lesbar markiert.

Um nicht dauernd den USB-Stecker ein- und ausstecken zu müssen, habe kam eines meiner Schubladen-Projekte zum Einsatz, der (verbuggte) USB-Switch. Mit einem Mit einem TS3USB221 (sehr klein und bescheiden zu löten) und einem IRLML2244 lässt sich das angeschlossene Device mit dem PC verbinden und trennen. Die Verbindungsfolgen werden erwartungsgemäß nicht eingehalten und durch einen Denkfehler und zu wenig Koffein schaltete die aktuelle Version entweder die Versorgung oder USB durch. Fädeldraht hat es zumindest vorübergehend gerichtet. Mit einem Schalter ausgestattet bleiben nun die Stecker heile.

Aber zurück zur Datenrettung. Zwei Gedanken: Die Platte alle 30 Sekunden pauschal zu trennen erhöht zwar die Datenrate, aber auch die elektromechanischen Zyklen, was der Lebensdauer nicht wirklich zuträglich ist. Gleichzeitig kommt die Platte nach einem Aussetzer nicht mehr hoch. Sie muss neu gestartet werden. Das kann man überwachen, indem man die Größe der Logfile von ddrescue prüft. Wächst diese stark an, ist etwas im faul. Ferner beendet sich ddrescue automatisch, wenn die Platte sich komplett abwirft.

So viel zum Wissen, aber wie kommt diese Information zum USB-Switch? Am einfachsten wäre es ja, den USB-Port selbst aus- und wieder einzuschalten. Geht in manchen Systemen, aber eine mittelkurze Recherche zeigte: die Erfolgschancen sind eher gering.

Also doch irgendwie anders. Hm. Der Laptop ist zu jung für den Parallelport, einen Microcontroller dafür zu programmieren ist mir ehrlich gesagt auch zu blöd. Hm, DTR und RTS lassen sich doch üblicherweise durch Software schalten und einen USB<>UART-Wandler, bei dem zumindest RTS herausgeführt ist, liegt auch herum.

Unter Linux ist doch alles eine Datei, also sollte es doch ein Leichtes sein, das Flag zu setzen. Leider nicht ganz. ioctl macht zwar genau das, aber es ist nicht persistent. Sobald das Programm sich beendet, wird der Port geschlossen und RTS/DTR ist wieder low. über stty schafft man es zwar auch irgendwie, aber mein Shell-Script begann eh anfangen, ziemlich übel zu stinken.

Nachdem desinfec’t mit Python kommt – warum nicht damit? Mit pyserial kann ich zumindest unter Windows schon einmal alles machen, unter Linux klappt es auch auf Anhieb.

Mittlerweile sieht das Setup so aus:

Die Platte liegt (ich weiß, nicht ganz ideal) auf einer Schütte, der Lüfter hält sie kühl. Am Notebook hängt der USB-Stick mit Scripts und Log (wichtig, da im Notebook kein persistenter Speicher ist), daneben der USB-Switch, der mit dem RTS des USB<>UART-Wandler verbunden ist.

Das Python-Script macht aktuell folgendes:

Verbinden der Platte und warten, bis /dev/sdx (also die Platte) existiert. ddrescue mit den entsprechenden Parametern als subprocess starten. Während es läuft, also .poll() des Prozesses keinen Exitcode ausweist. Weiter wird geprüft ob die Logdatei anschwillt. Dank Caching ist das leider nicht ganz so zielführend, aber immerhin. Das dritte Kriterium ist die Laufzeit. Ist die Datenrettung länger als 10 Minuten aktiv, naja – ich bin nicht stolz drauf. Tritt eine der drei Bedingungen ein, wird die Platte getrennt und gewartet (falls nicht schon passiert), bis ddrescue fertig mit dem Schreiben der Logdatei ist. Nach einer weiteren Wartezeit geht das Spiel von vorne los:

rescue.zip (weil WordPress mir Python-Scripts verbietet)

Für Schäden, die das Script verursachen kann, übernehme ich keine Haftung.

In nicht ganz 24 Stunden sind so nun weitere 130 GByte in Richtung Ersatzplatte gewandert. „Nur“ 35 weitere Gbyte wurden als defekt markiert.

Ob die Aktion erfolgreich gewesen sein wird, kann ich erst in knapp 280 GByte sagen und hoffe, dass auch so viel davon gelesen werden kann.

Abschließend kann ich nur mal wieder sagen: Kein Backup? Kein Mitleid!