Hallo SpoG,
jetzt kommt eine wichtige Korrektur bzw. Präzisierung: Die neuen dmesg-Meldungen sind kein harmloses Begleitgeräusch. Sie zeigen, dass Linux Schreibzugriffe auf die angeschlagene SSD versucht hat — und genau das darf bei einer Datenrettung eigentlich nicht passieren. Die entscheidenden Wörter sind WRITE, lost sync page write, writing superblock und updating journal superblock .
Das bedeutet: Die SSD wurde nicht nur gelesen, sondern Linux hat beim Mountversuch versucht, Dateisystem-Metadaten zu aktualisieren. Besonders EXT4 macht das sehr gern über sein Journal. Bei einer gesunden Platte ist das normal; bei einer Rettungsplatte ist es gefährlich.
Die gute Nachricht: Der Laptop deiner Tochter ist inzwischen praktisch entlastet. Mit neuer SSD läuft Windows 11 fehlerfrei, und Tests zeigen keine Fehler. Damit ist sehr wahrscheinlich nicht das Motherboard der Übeltäter, sondern ausschließlich die alte 1-TB-SSD .
Jetzt würde ich so antworten:
Hallo SpoG,
das ist ein sehr wichtiger Zwischenstand — und diesmal liefert die Ausgabe eine klare neue Erkenntnis.
Die wichtigste Information steckt in diesen Teilen:
op 0x1:(WRITE)
critical medium error
lost sync page write
I/O error while writing superblock
JBD2: I/O error when updating journal superblock
Das bedeutet nicht einfach nur „Lesefehler“.
Das bedeutet:
Linux hat versucht, auf die defekte SSD zu schreiben.
Und genau das ist bei einer Datenrettung unbedingt zu vermeiden.
Besonders kritisch ist diese Stelle:
EXT4-fs (nvme0n1p5): I/O error while writing superblock
JBD2: I/O error when updating journal superblock
Das heißt:
Die EXT4-Partition wurde offenbar nicht nur gelesen, sondern das System wollte beim Mounten das Journal bzw. den Superblock aktualisieren.
Bei EXT4 ist das normal, wenn ein Dateisystem nicht sauber ausgehängt wurde.
Für Datenrettung ist es aber ungünstig, weil jeder Schreibversuch auf der Schad-SSD weitere Metadaten verändern kann.
Darum ab jetzt bitte als oberste Regel:
Nicht mehr im Dateimanager anklicken.
Nicht mehr mounten.
Nicht mehr Testprogramme starten, die „reparieren“ könnten.
Nicht mehr versuchen, Partitionen direkt zu öffnen.
Nur noch lesen.
Warum nimmt das Terminal nach dmesg -w keinen Befehl mehr an?
Das ist normal.
Der Befehl:
sudo dmesg -w
läuft dauerhaft weiter und wartet auf neue Kernelmeldungen.
Das Terminal ist dadurch nicht „kaputt“.
Es ist nur mit dmesg beschäftigt.
Beenden mit:
Strg + C
Danach erscheint wieder die normale Eingabeaufforderung.
Was bedeuten die roten Zeilen fachlich?
Die SSD meldet echte Medium-Errors.
Beispiel:
critical medium error, dev nvme0n1
Das ist keine Windows-Macke und kein bloßer NTFS-Fehler mehr.
Das kommt direkt aus der Linux-Kernel-/NVMe-Schicht.
Besonders wichtig ist:
sct 0x1 / sc 0x82
Das ist eine NVMe-Fehlerkennung. Vereinfacht gesagt:
Der NVMe-Controller meldet, dass bestimmte Medienzugriffe nicht korrekt bedient werden können.
In Kombination mit:
Critical Warning 0x08
aus den früheren SMART-Werten passt das sehr gut zu einem internen SSD-Problem.
Also:
Controller, Flash Translation Layer oder NAND-/Mappingbereich der SSD.
Nicht primär Mainboard.
Nicht RAM.
Nicht Windows.
Nicht Linux.
Warum ist das Motherboard jetzt fast entlastet?
Du hast inzwischen einen sehr wichtigen Gegenbeweis erbracht:
Eine neue SSD läuft im Laptop deiner Tochter mit Windows 11 fehlerfrei.
Auch Testprogramme zeigen keine Fehler.
Damit ist die These:
„Das Mainboard beschädigt SSDs“
deutlich unwahrscheinlicher geworden.
Wenn das Mainboard oder die Spannungsversorgung grundsätzlich gefährlich wären, würde man mit der neuen SSD vermutlich wieder Instabilitäten, I/O-Fehler, SMART-Probleme oder Installationsabbrüche sehen.
Das passiert aber offenbar nicht.
Daher ist die vernünftige Schlussfolgerung:
Der Laptop ist wahrscheinlich wieder verwendbar.
Die alte 1-TB-SSD ist das Problem.
Jetzt kommt der entscheidende Sicherheits-Schritt
Bevor du weiter mit ddrescue arbeitest, würde ich die alte SSD im Live-Linux sofort schreibgeschützt setzen.
Zuerst alles aushängen, falls irgendetwas automatisch gemountet wurde:
sudo umount /dev/nvme0n1p1 2>/dev/null
sudo umount /dev/nvme0n1p2 2>/dev/null
sudo umount /dev/nvme0n1p3 2>/dev/null
sudo umount /dev/nvme0n1p4 2>/dev/null
sudo umount /dev/nvme0n1p5 2>/dev/null
Dann die komplette NVMe und ihre Partitionen read-only setzen:
sudo blockdev --setro /dev/nvme0n1
sudo blockdev --setro /dev/nvme0n1p1
sudo blockdev --setro /dev/nvme0n1p2
sudo blockdev --setro /dev/nvme0n1p3
sudo blockdev --setro /dev/nvme0n1p4
sudo blockdev --setro /dev/nvme0n1p5
Kontrolle:
lsblk -o NAME,SIZE,RO,TYPE,MOUNTPOINTS
In der Spalte RO sollte bei nvme0n1 und den Partitionen eine 1 stehen.
Erst wenn das so ist, weiterarbeiten.
Wichtig: ddrescue darf trotzdem lesen
Read-only bedeutet:
Das System darf nicht auf die Schad-SSD schreiben.
ddrescue darf aber weiterhin von ihr lesen.
Geschrieben wird nur auf die externe Rettungsplatte.
Der nächste ddrescue-Test im anderen Rechner wäre dann:
sudo ddrescue -f -n /dev/nvme0n1 /media/mint/MyPassport_3TB/ssd_anderer_rechner.img /media/mint/MyPassport_3TB/ssd_anderer_rechner.log
Falls genug Platz vorhanden ist, neue Image-Datei nehmen.
Falls nicht, vorher bewusst entscheiden, ob man mit dem vorhandenen Image weiterarbeitet.
Was wir mit diesem ddrescue-Lauf prüfen
Es gibt jetzt zwei mögliche Ergebnisse:
Fall 1:
ddrescue stoppt wieder bei ca. 61 GB.
Dann ist ziemlich sicher:
Die Grenze sitzt in der SSD selbst.
Der andere Rechner ändert nichts Grundsätzliches.
Fall 2:
ddrescue kommt deutlich über 61 GB hinaus.
Dann war der andere Rechner ein Gewinn.
Dann unbedingt laufen lassen und nicht unterbrechen.
Das wäre dann die Chance, weitere Teile der fehlenden ~929 GB zu retten.
PhotoRec direkt auf der SSD?
Ich wäre damit weiterhin vorsichtig.
PhotoRec auf dem vorhandenen Image war richtig und erfolgreich.
Dort konnte nichts mehr an der Original-SSD beschädigt werden.
PhotoRec direkt auf der defekten SSD ist riskanter, weil es viele Such- und Lesezugriffe erzeugt. Wenn die SSD intern instabil ist, kann das den Controller stärker belasten als ein sauberer ddrescue-Lauf.
Deshalb bleibt die Reihenfolge:
-
SSD schreibgeschützt setzen.
-
Mit ddrescue so viel wie möglich in ein Image holen.
-
PhotoRec/TestDisk auf dem Image verwenden.
-
Direktes PhotoRec auf der SSD nur als spätere Notlösung.
Noch ein sehr wichtiger Punkt
Die bisherigen PhotoRec-Erfolge sind Gold wert.
Die bereits geretteten 35 GB solltest du sofort zusätzlich sichern, idealerweise auf ein zweites Medium.
Denn das sind keine theoretischen Daten mehr, sondern echte gerettete Familien- und Geschäftsdaten.
Also bitte nicht nur auf derselben MyPassport liegen lassen, falls darauf weiter experimentiert wird.
Meine aktuelle Einschätzung
Jetzt ist der Fall klarer als vorher:
Der Laptop ist sehr wahrscheinlich in Ordnung.
Die alte 1-TB-SSD ist eindeutig krank.
Die neue dmesg-Ausgabe zeigt echte Medium-/I/O-Fehler.
Linux hat leider Schreibversuche auf der SSD unternommen, deshalb jetzt unbedingt read-only arbeiten.
Der nächste sinnvolle Schritt ist ein sauberer ddrescue-Lauf im anderen Rechner, aber erst nach gesetztem Schreibschutz.
Kurz gesagt:
Nicht mehr mounten.
Nicht mehr anklicken.
Nicht mehr reparieren.
Schreibschutz setzen.
Dann ddrescue.
Danach PhotoRec/TestDisk nur auf dem Image.
Das ist jetzt die professoral saubere Linie.
