Defektes NTFS-Laufwerk retten und kopieren – so geht’s mit gddrescue

Mein Artikel „Linux rennt beim Booten in initramfs – was tun?“ hat, wie man den Kommentaren entnehmen kann, vielen Menschen geholfen, ihr Linux-System wieder zum Starten bewegen zu können. Ich wurde gelegentlich auch nach den Ursachen gefragt, wie es dazu kommen kann. Meistens liegen die Gründe in fehlerhaften Laufwerken oder Problemen im Dateisystem. Letztere kann man aber in der Regel mit fsck beheben (wenn z. B. während eines Schreibzugriffs auf die Platte ein Absturz erfolgte und dadurch das Dateisystem inkontinent wurde 😀 ). Auch bei mir kam es in der letzten Zeit auf einem Dual-Boot-Notebook mit LinuxMint 19 und Windows 10 vermehrt zum initramfs – und auch unter Windows kam es immer häufiger zu den berüchtigten Bluescreens mit anschließendem Neustart. Hier lag es nun daran, dass die Festplatte nach acht Jahren intensivem Einsatzes erste Schwächen aufzeigte. Arbeiten damit ging noch irgendwie, aber nachdem nun auch unter Linux nach Schreibzugriffen auf das Laufwerk (insbesondere bei Updates) das Dateisystem auf read-only gesetzt wurde und außer Alarmmeldungen, dass ich den Systemadministrator benachrichtigen soll, nun gar nichts mehr ging, war es doch mal an der Zeit, nach Abhilfe zu schauen.

Also habe ich mir eine neue 2,5″-HDD für das Notebook bestellt. Der Plan war, mit Tools wie CloneZilla oder mit dem Linux-eigenen dd das komplette Laufwerk sektorenweise 1 : 1 auf die neue Platte zu kopieren. Ich habe einen PC hergenommen, die beiden Platten an die SATA-Anschlüsse gehängt und die Maschine mit einem bootfähigen USB-Stick mit Ubuntu 20.4 gestartet. Quell- und Ziellaufwerk (bzw. die kaputte und die neue HDD) waren schnell ausgemacht, CloneZilla hat mich gut geführt und der Kopiervorgang konnte starten. Beim Lesen auf der Windows-10-NTFS-Partition wurden dann aber vermehrt Lesefehler auf dem Quell-Laufwerk festgestellt, einzelne Sektoren waren schlichtweg nicht mehr lesbar, was – je nach Einstellungen unter CloneZilla – entweder zum Komplettabbruch des Kopiervorgangs oder zu endlos wiederholten Leseversuchen auf den schadhaften Blöcken führte. Nachdem Stunden verstrichen waren und der Fortschritt immer langsamer wurde, habe ich einfach hart abgebrochen und ich dachte mir: „Das Ding ist wohl ZU intelligent – probierstes mal mit dem schlichten, einfachen dd.“ Ich wollte ja einfach nur eine 1-zu-1-Kopie der Platte erstellen – mit allen enthaltenen Fehlern, die man später auf der neuen Platte dann immer noch in aller Ruhe reparieren kann. Mit dd habe ich noch jeden Datenträger im Originalzustand (insbesondere SD-Karten, siehe hier) kopiert bekommen. Aber selbst in diesem Fall führte dd beim Erreichen der NTFS-Partition zu Lesefehlern und Abbrüchen. Scheint also ein echtes Hardware-Problem zu sein.

Nach eingehenden Recherchen bin ich dann auf das Linux-Tool GNU ddrescue gestoßen (kann in den Paketquellen der aktuellen Debian-Distros mit

sudo apt-get install gddrescue

installiert werden). Bei gddrescue handelt es sich um eine Art erweitertes dd mit zusätzlichen Funktionen zur Rettung und Wiederherstellung von defekten Bereichen auf Festplatten. Man geht dabei in zwei Etappen vor. Angenommen, die alte Festplatte, die ich retten und kopieren möchte, sei /dev/sda, und die neue Platte sei /dev/sdb (welche nun welche ist, kann man schnell z. B. mit lsblk oder gparted ermitteln, CloneZilla hat zuvor auch bereits darüber Auskunft gegeben). Dann erfolgt ein erster Kopiervorgang mit folgendem Terminalbefehl:

sudo ddrescue -n --force /dev/sda /dev/sdb ddrescue.log

Nun wird das Quelllaufwerk – ohne Abbrüche durch schadhafte Sektoren – blockweise auf die neue Platte übertragen, inklusive aller Partitionstabellen, Boot-Sektoren, MBR usw. Der Parameter „-n“ sorgt dafür, das nicht lesbare Bereiche auf der Festplatte zunächst übersprungen werden, damit der Kopiervorgang alle Teile, die „noch gut“ sind, auf die neue Platte übernommen werden können. Der Clou bei diesem Vorgang ist nun die Datei „ddrescue.log“. Hier werden alle Adressen der nicht mehr lesbaren Sektoren gespeichert, was im zweiten Schritt nutzbar gemacht werden kann. Uff – primäres Ziel ist aber erst mal erreicht: 99,99 Prozent des Quell-Laufwerks waren noch lesbar. Der erste Kopier- und Analysevorgang hat bei einer 500-GB-Platte etwa drei Stunden gedauert.

Im zweiten Schritt nimmt sich gddrescue nun die geschriebene Log-Datei vor und kratzt in einem sogenannten Scraping-Verfahren intensiv genau an den Stellen auf der Platte herum (natürlich nur lesenderweise), die zuvor in der ddrescue.log als fehlerhaft markiert wurden. Hier wird nun versucht, aus den schadhaften Sektoren vielleicht doch noch das eine oder andere wiederherstellen zu können. Der dazugehörende Terminalbefehl ist fast identisch mit dem obigen, nur ohne den Parameter „-n“:

sudo ddrescue --force /dev/sda /dev/sdb ddrescue.log
gddrescue
Im oberen Schritt erkennt man den ersten Kopierlauf. Im unteren Teil sieht man, wie gddrescue versucht, das Letzte aus den schadhaften Sektoren herauszuholen.

Der zweite Durchgang hat dann in meinem Fall nochmal etwa eineinhalb Stunden gedauert. Um es abzuschließen: Nachdem der zweite Durchgang beendet war und ich die Kiste sauber runtergefahren habe (man weiß ja nie, was vielleicht doch noch im Cache nicht auf die Platte geschrieben wurde), habe ich die neue Platte im Ursprungs-Notebook eingebaut und zunächst Windows gebootet. Hier hat er erstmal einen großmächtigen chkdsk durchgeführt, der nochmal eine Stunde gedauert hatte, und dann lief alles reibungslos. Neustart mit Grub und Start von LinuxMint – hier lief dann alles auf Anhieb wieder problemlos, auch Updates ließen sich problemlos schreiben. Gerettet…

Zu beachten ist auf jeden Fall, dass keins der beteiligten Laufwerke während der Arbeit mit ddrescue gemountet sein darf. Daher ist die Lösung mit einem bootfähigen Live-Linux per USB-Stick (geht natürlich auch mit einer Boot-DVD) die sauberste.

Es versteht sich von selbst, dass man die defekte Platte noch komplett löscht und überschreibt, bevor man sie der Elektroschrott-Entsorgung zuführt.

Nur den Stunden-Aufwand darf man nicht in Lohn umrechnen 🙂 Nicht auszudenken, was ein bezahlter Fachmann für diese Nummer genommen hätte. Aber das sehr spezielle Notebook komplett neu aufzusetzen wäre dann doch weitaus zeitintensiver gewesen.

Windows-Uhr geht auf einer Linux-Dual-Boot-Maschine zwei Stunden nach – hier die Abhilfe

Heute mal wieder etwas, das mir alle Jubeljahre immer wieder passiert, wenn ich einen Dual-Boot-PC aufsetze, auf dem Windows und eine Linux-Distribution laufen sollen. Nachdem man die beiden Betriebssysteme eingerichtet hat, stellt man fest, dass unter Windows 7/8/10 die Uhrzeit eine Stunde bzw. während der Sommerzeit zwei Stunden nachgeht. In früheren Zeiten musste man, um dies zu beheben, mühsam in den ntp-Einstellungen unter Linux herumfuhrwerken oder aber unter Windows die Uhrzeit ständig manuell synchronisieren. Heute geht das viel einfacher – hier erfahren Sie, wie!

Das eigentliche Problem ist, dass sowohl Linux als auch Windows ihre aktuelle Uhrzeit innerhalb des Betriebssystems speichern, jedoch nicht die Hardware-RTC-Uhr des Rechners aktualisieren. Um dies zu beheben, müssen beide Betriebssysteme dazu gebracht werden, die Uhrzeit in der PC-Uhr zu speichern. Unter aktuellen Linux-Distros, die mit systemd laufen – Ubuntu, Fedora, LinuxMint usw. – gibt man zunächst folgenden Befehl in ein Terminal ein:

timedatectl set-local-rtc 1 --adjust-system-clock

Hierdurch wird das System veranlasst, die Uhrzeit künftig in der RTC-Uhr des BIOS zu aktualisieren. Mit

timedatectl

können Sie dann nachprüfen, ob die Einstellung richtig angenommen wurde. Hier sollte nun u. a. „RTC in local TZ: yes“ zu lesen sein. Die anschließende Warnung, dass es nicht gut sei, die RTC statt der Software-Uhr zu aktualisieren, können wir geflissentlich übersehen.

Unter Umständen könnte es nach einem Reboot aber sein, dass Windows immer noch die falsche Zeit anzeigt. Dies kann man in der Registry fixen. Hierzu also regedit aufrufen und den Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation suchen. An dieser Stelle trägt man nun ein neues DWORD mit der Bezeichnung RealTimeIsUniversal ein und setzt darin den Wert 1. Dies sorgt dafür, dass die Hardware-Uhrzeit, die ja in UTC (internationale Weltzeit, früher GMT) gespeichert ist, gemäß Ihrer Zeitzone (etwa ME[S]Z, Berlin) und der aktuell gültigen Sommer- oder Normalzeit unter Windows richtig angezeigt wird.

Nach einem erneuten Reboot und Windows-Start erscheint nun dauerhaft die korrekte, lokal gültige Uhrzeit.

Dass Sie mit der Windows-Registry vorsichtig umgehen sollten, versteht sich von selbst – ich gehe davon aus, dass Sie wissen, was Sie tun. Eine Haftung für zerschossene Windows-Maschinen kann ich natürlich nicht übernehmen.

Leistungs-Index unter Windows 7: Zugriff auf primäres Laufwerk nicht möglich. Falscher Parameter.

Ich habe auf einem Arbeitsrechner, mit dem ich mein Geld verdiene, immer noch Windows 7 im Einsatz. Nun habe ich kürzlich dem PC eine neue SSD spendiert und das Gesamtsystem unter Linux mit „dd“ von der alten HDD rüberkopiert. Hat alles bestens funktioniert und der SSD-Performancegewinn macht Spaß.

Nun habe ich heute aber mal nach langer Zeit das Leistungs-Index-Tool unter Windows 7 gestartet. Das hat auch alles brav gecheckt – bis zu dem Punkt, wo es darum geht, den Datendurchsatz der Festplatte zu messen. Da brach das Tool mit der Fehlermeldung „Zugriff auf primäres Laufwerk nicht möglich. Falscher Parameter.“ ab. Mein erster Gedanke war natürlich: „Da hab ich wohl irgendwas noch mit der neuen SDD nicht richtig eingestellt.“ Auf der Kommandozeile „winsat disk“ eingegeben – das ergab die selbe Fehlermeldung. Na ja, das Leistungs-Index-Tool ist ja nicht so wichtig, ansonsten läuft ja alles – aber das wollte ich dann doch genauer wissen.

Es hat einige Zeit gedauert, bis ich den Übeltäter entdeckt habe: die Antiviren-Software AVAST! Diese gräbt sich sehr tief in die Windows-Registry ein und hebelt dort einiges aus – mit der Folge, dass die Festplatte nicht mehr richtig parametrisiert wird. AVAST verhindert direkte HDD-/SDD-Zugriffe und leitet diese für den Echtzeitschutz über eigene Dienste um. So ohne Weiteres lässt sich AVAST jedoch auch nicht restlos deinstallieren, und genau aus diesem Grund bietet das Unternehmen auch ein separates Deinstallationstool namens AvastClear.exe an (Download). Die exe-Datei einfach auf den Desktop ablegen und das System im abgesicherten Modus (während des Bootvorganges F8 drücken) starten. Nun die AvastClear.exe per Doppelklick starten. Wärend des Ablaufs der Deinstallationsroutine sieht man sehr deutlich, welche Dateien, Kernel und Registry-Einträge eliminiert werden.

Anschließend Windows 7 wieder „normal“ starten. Erster Test mit „winsat disk“ auf der Kommandozeile: Juhuuu, dort tut er nun was. Dann nochmal das Leistungs-Index-Tool gestartet und durchlaufen lassen: Yippieh, die SSD hat eine Top-Performance!

Doch jetzt steht das Ding völlig ohne Virenschutz da! Nun hätte ich AVAST neu installieren können, aber nach diesem Reinfall habe ich mich für einen anderen Weg entschieden, nämlich für den Windows Defender! Das MS-eigene Antivirenprogramm hat in der Systemsteuerung einen eigenen Eintrag und ist schnell aktiviert und aktualisiert. Während in früheren Zeiten der Defender eigentlich nur für einen grundlegenden Schutz gut war, so hat er in den letzten Wochen und Monaten in vielen Tests durch die üblichen Verdächtigen (Heise & Co.) in seiner aktuellen Version durch seine sehr hohe Infektions-Erkennungsrate überrascht. Im Übrigen geht der Defender auch und gerade im Echtzeitschutz sehr schonend und sparsam mit den Ressourcen um. Ich gebe dem Windows Defender also mal eine Chance und werde beobachten.

Windows10-Upgrade zerstört Grub-Konfiguration

Auf meinem Arbeitsnotebook mit LinuxMint 17.1 habe ich nebenher noch ein Windows 8.1 mit Grub und entsprechend mühsam eingerichteter UEFI-Konfiguration am Laufen. Nun kam der Tag des (automatisierten) Windows-10-Upgrades. Mutig, wie ich ja bin, habe ich das einfach mal laufen lassen. Hat auch alles auf den ersten Blick geklappt, aber dann kam der große Schreck: Beim Versuch, das Grub-Bootmenü von Linux zu starten, rannte der Rechner prompt in den – genau – Grub-Rescue-Prompt. Somit war LinuxMint erst mal nicht mehr erreichbar.

Wie ich später herausfand, hat das Windows-10-Upgrade die Reihenfolge und Attribute der Partitionen verändert (getreu dem Gebot „Du sollst keine anderen OS neben Windows 10 haben“) – die Linux-Bootpartition war nicht mehr dort, wo Grub sie vermutete. Ich hätte jetzt versuchen können, ein Linux von einer Boot-CD-ROM oder einem USB-Stick zu starten, um dann Reparaturversuche durchzuführen. Ich habe es dann aber doch mit Bordmitteln auf dem Grub-Rescue-Prompt hinbekommen.

Zunächst habe ich mit „ls“ nachgesehen, welche Partitionen überhaupt vorhanden sind. Ergebnis bei mir war (hd0,gpt10), (hd0,gpt9), (hd0,gpt8) … (hd0). Welche davon ist jetzt die Linux-Partition, die ich starten möchte? Das findet man heraus, indem man nacheinander „ls (hd0,gpt1)/“, „ls (hd0,gpt1)/boot“, „ls (hd0,gpt2)/“, „ls (hd0,gpt2)/boot“ usw. eingibt. Meist wird man eine Fehlermeldung erhalten, dass das Filesystem nicht erkannt werden konnte. Irgendwann wird man aber das Laufwerk entdecken, welches das Linux-Hauptverzeichnis enthält – das war in meinem Fall (hd0,gpt9). Viel Spaß übrigens mit der deutschen Tastatur und den Zeichen „()/=“ 🙂

Als nächstes habe ich mit „set“ kontrolliert, wo Grub seine Konfigurationsdateien sucht. Das Ergebnis war in meinem Fall:

prefix=(hd0,gpt8)/boot/grub
root=(hd0,gpt8)

Aha! Ich habe doch zuvor festgestellt, dass mein Linux-Laufwerk (hd0,gpt9) ist. An der Stelle hat Windows 10 also herumfuhrwerkt! Ehemals Partition gpt8 ist jetzt gpt9. Jetzt gilt es also, die Einstellungen für prefix und root so einzustellen, dass Grub seinen Kram wieder findet. Und das geht so:

set prefix=(hd0,gpt9)/boot/grub
set root=(hd0,gpt9)

Wenn man jetzt in die normale Menüansicht von Grub möchte, gibt man Folgendes ein:

insmod normal
normal

Wenn Sie alles richtig gemacht haben, sehen Sie jetzt wieder Ihr altbekanntes Grub-Bootmenü. Juhuuuuu! Aber nicht zu früh freuen! Beim nächsten Booten rennen Sie garantiert wieder in den Grub-Rescue-Prompt. Wenn Sie jetzt auf dem Grub-Bootmenü stehen, stellen Sie den Leuchtbalken auf den Eintrag, der Ihr Linux starten soll, und drücken ‚e‘ (wie „edit“). Hier ändern Sie jetzt überall, wo noch der falsche gpt-x-Wert steht, auf den neuen – bei mir also überall, wo noch ein gpt8 steht, ein gpt9 setzen. Nun F10 drücken – und Linux startet!

Nun sind wir auch schon fast am Ziel. In einer Konsole geben wir nun noch ein „sudo grub-install“ ein, und Grub wird aktualisiert – auch das neue Windows wird erkannt. Jetzt kontrollieren wir nochmal zur Sicherheit die /etc/fstab mit einem Editor (nano, vim, was Sie mögen). Die gemounteten Partitionen mit einem UUID-Identifier stellen natürlich kein Problem dar, sollten Sie dort aber Laufwerke mit einem /dev/…-Eintrag finden, sollten Sie die entsprechende Zeile auf die neuen Gegebenheiten anpassen.

 

Bing-Desktop mit hoher CPU-Last

Die Windows-App „Bing-Desktop“ finde ich eigentlich ganz nett – insbesondere die Funktion mit dem täglich neuen Bing-Startseitenbild als Bildschirmhintergrund. Seit einer Woche stelle ich jedoch fest, dass der Notebook-Lüfter im Dauerlauf rennt und mir der Taskmanager anzeigt, dass Bing-Desktop über 50 Prozent Prozessorlast für sich vereinnahmt. Außerdem wird seit Tagen das tägliche Hintergrundbild nicht mehr aktualisiert.

Hier hilft nur, in der Systemsteuerung unter „Programme“ das Ding rauszuschmeißen und neu zu installieren. Download gibt’s hier.

Wieder einmal PuTTY: Darstellung von Linien, Umlauten und Sonderzeichen

Ich greife öfter mittels des Terminalprogramms PuTTY unter Windows auf Linux-Rechner zu – insbesondere auf meine Raspberry Pis. Nun kommt es immer wieder mal vor, dass bestimmte zeichenorientierte Anwendungen auf einer Linux-Konsole in PuTTY falsch dargestellt werden. Ich muss z. B. häufig mit dem alsamixer Audio-Einstellungen der USB-Soundcard eines Raspberrys ändern. Aus den gewohnten Rahmenlinien wird in PuTTY ein Buchstaben-Mix umgesetzt, die als lppk-Zeichenfolge bekannt ist. Hinzu kommt, dass die F-Tasten in PuTTY nicht richtig funktionieren und dafür sorgen, dass alsamixer beendet wird, wenn ich mit F3 bzw. F4 zwischen den Wiedergabe- und Aufnahmeeinstellungen umschalten will. Hier helfen einige PuTTY-Einstellungen.

raspberry_putty-lqqk

Diese verwurstete Darstellung nervt mich schon seit Jahren.

 

Unter Connection/Data ist es wichtig, dass man im Feld „Terminal-type String“ das vorgegebene „xterm“ durch das Wort „linux“ ersetzt. Achtung – kontextsensitiv! „linux“ muss komplett kleingeschrieben werden. Somit haben wir die richtige Rahmendarstellung schon mal im Griff. Nun ist es noch wichtig, unter Terminal/Keyboard unter „Function keys and keypad“ den Radiobutton „Linux“ zu setzen – dann funktioniert es auch mit den F-Tasten.

putty-alsamixer

So soll es sein!

 

Windows 8.1 Update 1 – Fehler bei der Installation und Lösung

Naaaaaa? Haben Sie auch Probleme bei dem Pflicht-Update von Windows 8.1 (KB2919355), zu welchem Microsoft uns zwingt, damit der geneigte Anwender auch im nächsten Monat zum Patch-Day noch Updates erhält? Bricht nach dem langwierigen Download und dem noch langwierigeren Installationsversuch der Updater mit der Fehlermeldung „Das Update wurde nicht installiert“ und der Nummer 0x80070002 oder 0x80073712 ab? Haben Sie auch schon tausend Sachen versucht, wie z. B. das System zu „refreshen“, Windows-Update reparieren – und nichts hat geholfen?

Dank WinFuture.de bin ich auf einen Fix gestoßen, der bei mir  geholfen hat:

1. Öffnen Sie eine Administrator-Eingabeaufforderung.

2. Geben Sie nacheinander folgende Befehlszeilen ein.

  • dism /online /remove-package /packagename:Package_for_KB2919355~31bf3856ad364e35~amd64~~6.3.1.14
  • dism /online /cleanup-image /startcomponentcleanup

Nachdem diese Schritte durchgelaufen sind, starten Sie noch einmal das Windows Update in der Systemsteuerung, suchen nach neuen Updates und downloaden/installieren Sie das KB2919355 noch einmal. Das sollte dann endlich hinhauen.

Ein offizieller Fix seitens Microsoft steht derzeit (13.04.2014) noch aus.

Älteres jQuery, fadeIn/fadeOut und der Internet Explorer

Kinners, nee! Was habe ich mich heute mal wieder über den Internet Explorer geärgert! Aber was soll man machen – es gibt ja immer noch unbedarfte Mitmenschen, die nur diesen so genannten Browser kennen, und auf die muss man auch eingehen. Und das kostet – vor allem Zeit.

Was ist passiert? Ich arbeite mitunter gern mal mit den Animationsfunktionen der JavaScript-Bibliothek jQuery. So habe ich schon vor fast einem Jahr für eine Freundin eine Seite gebastelt, in der unsere gemeinsamen Urlaubsfotos in Form einer Diashow mit Überblendeffekten ablaufen sollten. jQuery-Funktionen der Wahl waren ‚fadeIn‘ und ‚fadeOut‘. Hat auch alles wunderbar funktioniert – einmal mit Opera, Firefox und Co. getestet, der Freundin den „geheimen“ Link geschickt zum Anschauen – abgehakt und vergessen. War ja nur für uns so …

Nun habe ich dieser Tage eine Seite für ein etwas größeres Publikum entwickelt, in der ich eine ähnliche Diashow meinen Vereinsfreunden präsentieren wollte. Und da ich das Rad nicht neu erfinden wollte, habe ich eben besagte Webseite von damals als Vorlage genommen. Hat auch alles soweit funktioniert – bis ich dann mal auf die glorreiche Idee kam, auch mal mit dem Internet Explorer draufzusehen. Und erst da sah ich: im IE blendet nichts über – die Bilder werden einfach nacheinander übereinander gelegt. Ganz normale IE-Bugs eben :-/

Ich habe dann eine Reihe von CSS-Workarounds ausprobiert mit „filter:inherit“, „opacity: inherit“, mit verschachtelten divs als nachzuladendem Hintergrundbild usw. Krampf eben. Dabei ist die Lösung soooooo einfach:

Ich benutzte vor einem Jahr die jQuery-Version 1.2.6, die solche typischen Fehler im Internet Explorer noch nicht berücksichtigte. Ich habe dann eine etwas neuere Version eingespielt (1.7.2) – im HTML-Code im <head>-Bereich entsprechend angepasst, und siehe da: jetzt spielt auch der zickige IE die Diashows flüssig ab – siehe http://meikelcam.bplaced.net/dk7lj .

PuTTY und der Ziffernblock

Wenn ich mal mit Windows 7 arbeite (kommt selten genug vor 😉 ) und per SSH auf meinen Raspberry Pi zugreifen möchte, nutze ich PuTTY. Seit langem ärgert es mich ein wenig, dass ich auf dem Ziffernblock der Tastatur keine Ziffern im Terminalfenster erhalte, sondern die alternativen Steuerzeichen (so als ob NumLock off wäre).

Abhilfe ist ganz einfach: in den PuTTY-Einstellungen unter „Terminal > Features“ die Option „Disable Application Keypad mode“ aktivieren. Am besten gleich diese Änderung unter „Session“ bei den Saved Sessions dauerhaft speichern.

Dann klappts auch mit den Zahlen.