fsck bei Problem mit verschlüsselter Festplatte

[rara]

Hallo zusammen,
meine Festplatte hat einen Schaden ("Inconsistency"). Beim Booten erfahre ich, dass fsck das ergebnis 4 ausspuckt, also unbearbeiteter Festplattenfehler. Ich soll fsck "manually" durchführen.
Das funktioniert aber nicht. Erst mal macht der Rechner gar nix, auf fsck kommt nur die Antwort, dass der Befehl dem Paket Linux-Utils entstammt. Recovery Mode bringt da auch nix.
Ich hab dann ein Live-System gestartet. Ich bin mittlerweile draufgekommen, dass fsck nicht funktioniert. Es muss fsck.ext4 sein. Wenn ich die Festplatte, die mit LUKS verschlüsselt ist und als Logical Volume konfiguriert ist, entschlüssele, dann kommt auf fsck.ext4 die Antwort, dass nix gehe, weil die Partition (/dev/sda5) in Nutzung ist. Wenn ich die Festplatte nicht entschlüssele, wird fsck.ext4 versucht, aber es kommt sofot die Antwort: Bad magic number in Super-Block. Auch einen anderen Super-Block zu probieren, wie sofort empfohlen wird, bringt dasselbe Ergebnis.
Hat jemand einen Tipp, wie ich an meine Daten rankomme? Ich hab seit einer Woche kein Backup gemacht, es wäre schade um einige Dateien.

Nachtrag: Bin seit Stunden im Internet unterwegs wegen der Sache und hab in einem alten Forum gelesen, dass fsck bei einer eingehängten Partition regelrecht gefährlich sein kann, dass aber andererseits die Partition entschlüsselt sein muss, damit es funktioniert. Das macht das Ganze für mich noch unverständlicher.

[schwedenmann]

Hallo

Ich gehemal davon aus,das du luks + lvm nutzt.

Dann mußt du folgendes machen

1. irgendeine livcd booten
2. luks physikalsiches device entsperren
3. vgchange -ay (ay ist jetzt aus dem Gedächnis zitiert,also googeln)
4. jetzt sind die vg dem livesystem bekannt
5. fsck -a /devicenamedervolumegroup-sollte der in der fstabsein fsck -a bitte auch googeln,m.M. nach ist das die Option bei manuellen Check mit auto.
Korrektur.

mfg
schwedenmann

[bluestar]

Ich glaube da fehlt zwischen 2&3 noch ein: vgscan

[rara]

Danke erst mal.
Die Befehle lauten
vgchange -a y
und
fsck.ext4 -p bzw e2fsck -p (-p steht für automatic repair)
Vgscan ist offenbar unnötig.
Aber es funktioniert nicht. Wieder ist die Antwort:
/dev/sda5 is in use.
e2fsck: Cannot continue, aborting.

Selbst wenn ich
vgchange -a n
versuche, um die Volume Groups stillzulegen, kommt nix anderes raus.

Ich mache das aus einer Shell der Installer-Umgebung (Debian 10), habe kein Root-Verzeichnis gewählt.
Ist fsck.ext4 -p /dev/sda5 nicht der richtige Befehl?
Weitere Ideen?

[schwedenmann]

Hallo

Mach das Gnaze mal extern von einer Livecd aus.

Also Livecd (z.B. finnix oder sysremrescue) booten und dann die obigen Befehle

mfg
schwedenmann

[rhHeini]

Du kannst das Device /dev/sda5 nicht mit fsck prüfen, weil da der Crypto-Container drauf ist und kein ext4-Device, das geht nur mit den entschlüsselten und mit ext4 formatierten Inhalten. Die müssten in /dev/mapper zu finden sein. Eine Übersicht bringt z.B. blkid.

Gruß, Rolf

[rara]

Wie sehen denn solche entschlüsselten Inhalte aus? In /dev/mapper sind nur die partitionen root, swap und sda5_crypt. Und control, was auch immer das sein soll.
blkid zeigt auch nicht mehr. Nur lange Zeichenketten für UUID und PARTUUID.
Ich nehme an, sda1 sowie /dev/dm-1 und /dev/dm-2 spielen keine rolle.

[smutbert]

sda5_crypt ist mit an Sicherheit grenzender Wahrscheinlichkeit das entschlüsselte Gerät. Wenn blkid für /dev/mapper/sda5_crypt eine UUID anzeigt, sollte es auch das richtige Gerät für den Dateisystemcheck sein (die UUID ist eine Eigenschaft des Dateisystems).

[rara]

Aber nach:
fsck.ext4 -p /dev/mapper/sda5_crypt
kommt wieder: /dev/mapper/sda5_crypt is in use.
Es geht nicht.
Ich mach das übrigens aus der Installer-Shell eines Debian-Images auf einem USB-Stick, ohne ein root-Verzeichnis auszuwählen. Vorher mach ich vgchange -a y.
Wenn ich mit:
vgchange -a n
die Logical Volumes inaktiv schalte, kommt:
/dev/mapper/sda5_crypt contains a LVM2_member file system
sowie
Bad magic number in super-block.

[smutbert]

Also doch lvm, dann musst du das logische Volume angeben. Führe doch einmal nacheinander

Code: Alles auswählen

vgscan
vgchange -a y
lvdisplay

aus und poste auch die Ausgaben der Befehle, damit wir sehen können ob bzw. wo etwas schief läuft.
Die Ausgabe des letzten Befehls sollte eine Liste der logischen Volumes liefern, inklusive der Gerätedatei, auf die du fsck loslassen kannst (in der Zeile „LV Name“).

[rara]

Danke. Es war das Volume root. Hab's gleich gesehen, es nimmt fast die gesamte Festplatte ein.
fsck hat relativ schnell ein paar Fehler korrigiert. Rechner läuft.
Jetzt besorg ich mir wohl schnell ne neue Festplatte oder?

[smutbert]

Das hängt eventuell davon ab woher der Fehler kommt. Mit den smartmontools oder besonders in Gnome auch mit gnome-disk-utility könntest du dir eventuell die SMART-Werte ansehen. Da gibt es eine allgemeine Einschätzung zur Gesundheit der Festplatte und auch einzelne Werte, die auf Probleme an bestimmten Punkten hindeuten können (z.B. einen UDMA CRC Error Count, der eher auf ein Problem bei der Verbindung zwischen Festplatte und SATA-Controller hindeutet – das hat zwar normalerweise keine solchen Dateninkonsistenzen zur Folge, aber in Ausnahmefällen eben doch).

Und es gibt ja auch ganz andere mögliche Fehlerursachen, wie fehlerhafter Hauptspeicher

[rhHeini]

Vielleicht solltest Du nebenbei mal checken ob Du während des Boots ein fsck anstösst. Sieht bei mir so aus:

Code: Alles auswählen

/dev/mapper/vgsys-1_root /               ext4    errors=remount-ro 0       1

Die 1 bedeutet fsck mit Prio 1. Wenn Du ein separates /boot bzw. /boot/efi hast sollten die gleich behandelt werden.

Rolf

[rara]

Wo wir schon mal dabei sind - ich hab jetzt zwei Mal smartctl angewendet. Dazwischen hab ich einen Test durchgeführt, mit
sudo smartctl -t long /dev/sda5
Das Ergebnis ähnelt sich, beim zweiten Mal sind ein paar Werte logischerweise ein bisschen höher, nämlich da, wo es um Zeitdauern geht.
Für mich sieht da nix besorgniserregend aus, aber ich verstehe nicht alles. Das "pre-fail" ist allerdings auffällig.
Kann jemand hier ein Problem erkennen?
Der Output nach
sudo smartctl -a /dev/sda5
ist:
41556

[smutbert]

Pre-fail sagt lediglich etwas über die Art des Wertes aus. Würde sich der Wert verschlechtern, was offensichtlich nicht getan hat, dann würde er auf einen drohenden Ausfall hindeuten.
Schlechtestenfalls sagt der Wert also gar nichts aus, weil wir nicht wissen wofür er steht und bestenfalls sagt er aus, dass alles in Ordnung ist, weil 100 der bestmögliche Wert ist.

Bei den anderen Werten („Old_age“) ist es ganz normal, wenn sie sich während das Laufwerk altert, verschlechtern.
(Bei denen könnte also vielleicht keine Verschlechterung an sich sondern eher eine plötzliche Verschlechterung auf ein Problem hindeuten.)