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

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.