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.
Linux ist und bleibt das ultimative System. Es braucht Zeit, sich daran zu gewöhnen wie dies auch bei Windows es der Fall war.
Bleibt die Frage offen, ob und wie sich bei Einsatz eines Live-Systems per USB unter Ubuntu „gddrescue“ auf einem USB-Stick installieren lässt?!?! Normalerweise lässt dies ein Liversystem nicht zu.
Bei einer Umrüstung HDD auf SSD gelang mir eine lauffähige dd-Kopie mittels Live-System nicht wirklich. Wie sieht die Lösung aus??
Möglicherweise gelingt dies unter Einsatz eines Persistenzspeichers unter Ubuntu, Kubuntu, Lubuntu, Mint usw. auf dem USB-Stick? Vielleicht können Sie mir diese Frage beantworten.
Vorerst herzlichst Dank für Ihre großartigen Hinweise und Lösungsvorschläge!
miracle – Hobbyist – 6 Laptops mit Mint, Xubuntu, Lubuntu, Kubuntu, Debian
Werter Herr miracle,
natürlich sollte man kein „offenes“, also in Betrieb befindliches Betriebssystem-Laufwerk mit all seinen geöffneten Dateien sichern oder übertragen – das führt zu Inkontinenzen oder wie das heißt 🙂 Für Ihren Fall empfehle ich folgende Vorgehensweise:
– Starten Sie Ihren Rechner, der das zu übertragende Laufwerk enthält, von einem Boot-Datenträger (am besten eine Live-DVD mit Linux Mint).
– Dann sichern Sie mit dd das zu übertragende Laufwerk (also Ihre HDD) in eine ISO-Datei – etwa so: dd if=/dev/sdb of=./bootlaufwerk.iso bs=1M (ermitteln Sie vorher, wie Ihr zu sicherndes Laufwerk heißt und wohin Sie die ISO-Datei speichern, etwa auf eine angeschlossene externe Festplatte; /dev/sdb ist hier nur beispielhaft für Ihr Quelllaufwerk).
– Nun gehen Sie erst mal Kaffeetrinken 😉
– Nachdem das Laufwerk in bootlaufwerk.iso gesichert ist, schließen Sie spätestens jetzt einen ausreichend großen USB-Stick an. Suchen Sie in dem jetzt noch live gebooteten Linux mit einem Dateimanager die iso-Datei und rechtsklicken Sie mit der Maus auf die Datei. Wählen Sie nun „Startfähigen USB-Stick erstellen“. Wählen Sie Ihren USB-Stick aus und klicken Sie auf „Schreiben“.
– Sobald dieser Schreibvorgang abgeschlossen ist, können Sie das Kästle herunterfahren und anschließend vom USB-Stick ihre gewohnte Umgebung booten und damit arbeiten.
– Die ISO-Datei können Sie natürlich auch per dd auf die neue SSD schreiben. Sie haben ja die ganze Platte gesichert und nicht nur eine Partition, somit enthält das ISO auch ein bootfähiges Laufwerk mit Bootsektor und allen Partitionen.
Für alles natürlich keine Garantie – wenn Sie sich irgendwelche lebenswichtigen Dateien zerschießen, nun ja, eigene Gefahr. Ich hab’s aber mit verschiedenen PCs, Notebooks usw. in den letzten Jahren gemacht. Ging (außer in dem beschriebenen Fall mit gddrescue) immer problemlos.
Weiterführende Links:
https://linuxmint-installation-guide.readthedocs.io/de/latest/burn.html
Den Umgang mit dd kennen Sie, ansonsten https://wiki.ubuntuusers.de/dd/
Und sollten sich Lesefehler auf ihrem alten Laufwerk einstellen (defekte Sektoren, die nie bemerkt wurden, können immer auftreten), hilft wie gesagt gddrescue
https://wiki.ubuntuusers.de/gddrescue/
Grüße von der Ostsee,
Michael Eggers
Sehr herzlichen Dank für die ausführlichen Hinweise. Mein Versuch zum clone folgte den häufig zitierten Hinweisen in Youtube. Beide Laufwerke ausgehängt; per dd if=/dev usw. clonen mittels externem USB- Linux. Leider lief das geklonte, mit FAT32 partitionierte SSD-Laufwerk nach Eibau nicht. Jetzt versuche ich es mit der von Ihnen beschriebenen Methode. *****