Linux ext2 Journal & Super block corrupted, fsck Reperatur nicht möglich

[Ambrosius]

Noch ein linux problem thread... they keep coming

Ich hab versucht grad in mein MX Linux zu booten und bekomme ständig eine Fehlermeldung dass was mit meiner Boot Partition nicht stimmt. Es startet dann in die BusyBox und gibt folgenden Output:

RootMX: Unexpected Inconsistency: RUN fsck manually. Fsck exited with status code 4

Also hab ich in eine live umgebung gebootet und versucht dort im Terminal fsck laufen zu lassen:

sudo fsck.ext4 -v -f -c /dev/sdx

Soweit so gut, hab dann die folgende Ausgabe erhalten:

Ext2fs_open2: Bad magic number in super block. Super block has an invalid journal (inode 8) Clear<y> yes

Also habe ich es gelöscht. Problem ist, es hat zwar die

****Filesystem was modified****

Meldung gegeben,was gut ist, aber das journaling ist nachwievor beschädigt. Weil auch siehe hier:

Ext2fs_block_iterate: Inode checksum does not match inode while sanity checking the bad blocks inode

Hmm ich bin jetzt etwas überfragt, weiss jmd wie ich das Problem weiter eingrenzen und diagnostizieren kann??

 

[ubu]

Welche Partition ist betroffen, poste mal vom rescuesystem die Ausgaben von fdisk -l und lsblk

ext2 3 oder 4 filesystem?

 

[µkrobe]

UEFI ?

 

[ubu]

Hat mit UEFI nix zu tun

 

[Gamepower]

Einige Informationen zum System, wo dieser Fehler auftritt, wären hilfreich. Außerdem eine Beschreibung dessen, was Du zuvor getan hast, bevor dieser Fehler auftrat.

 

[Ambrosius]

Welche Partition ist betroffen, poste mal vom rescuesystem die Ausgaben von fdisk -l und lsblk

es ist die Root Partition, mit luks verschlüsselt

$ lsblk
NAME                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                                    7:0    0   2,6G  1 loop  /live/linux
sda                                      8:0    0 238,5G  0 disk
├─sda1                                   8:1    0   256M  0 part
├─sda2                                   8:2    0   512M  0 part
├─sda3                                   8:3    0   220G  0 part
└─sda4                                   8:4    0  17,7G  0 part
sdb                                      8:16   0 476,9G  0 disk
└─sdb1                                   8:17   0 476,9G  0 part
  └─luks-741hc523-f7a4-40g5-am92-0579c8ha960f
                                       254:1    0 476,9G  0 crypt /media/AMG/homeMX

sda3 ist root, sda 4 ist swap, 1,2, sind efi respektive boot. Home ist auf sdb1 ausgelagert

Beitrag automatisch zusammengeführt: 4 Mai 2023

Einige Informationen zum System, wo dieser Fehler auftritt, wären hilfreich. Außerdem eine Beschreibung dessen, was Du zuvor getan hast, bevor dieser Fehler auftrat.

Natürlich, hier die Ausgabe von..

$ uname -ar
Linux May 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

Beitrag automatisch zusammengeführt: 4 Mai 2023

Hab inzwischen auch mal

sudo e2fsck -n -v -b 32768 /dev/sda3

laufen lassen und folgende Ausgabe:

Root was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear? no

Inode 221 has the casefold flag set but is not a directory.  Clear flag? no

Directory ??? has the casefold flag, but the
casefold feature is not enabled.  Clear flag? no

es folgen viiiiele koruppte Inodes, ich kann nur nicht verstehen wieso?

Ich fahre das OS immer sauber herunter, so auch gestern Abend. Nix auffälliges vorher passiert, auch keine Updates gemacht oder Ä.

Beitrag automatisch zusammengeführt: 4 Mai 2023

[...]

Inode 253 has encrypt flag but no encryption extended attribute.
Clear flag? no

Error while iterating over blocks in inode 253: Cannot iterate data blocks of an inode containing inline data

Root: ********** WARNING: Filesystem still has errors **********

e2fsck: aborted

Root: ********** WARNING: Filesystem still has errors **********

Dann habe ich abgebrochen, da ich glaube, dass die Verschlüsselung hier auch iwie einer richtigen Reperatur im Wege steht... Das ist so bisher mein letzter Stand

Beitrag automatisch zusammengeführt: 4 Mai 2023

ext2 3 oder 4 filesystem?

ich habe das fs mit ext4 installiert, aber es scheint vor allem das jounraling zu betreffen, siehe auch hier:

$ sudo fsck /dev/sda

fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sda

 

[ubu]

1. Bist du sicher dass die rootpartitition auf LUKS-Crypt liegt, nach der lsblk Ausgabe sieht das nur nach einem LUKS auf sdb1 aus.

2. fsck muss auf das Filesystem/ die Partition ausgeführt werden, d.h. auf z.B. /dev/sdg3 NICHT auf /dev/sdg

3. Für ein LUKS device muß dieses erst entschlüsselt werden:
3.1 Entschlüsseln: sudo cryptsetup open /dev/sda3 mycryptdevice --type luks --> Passwort eingeben
3.2 Unter /dev/mapper sollte es jetzt mycryptdevice geben, darauf fsck
3.3 fsck -f /dev/mapper/mycryptdevice
3.4 Danach versuchen zu mounten: mount /dev/mapper/mycryptdevice /mnt
3.5 Testen ls -l /mnt
3.6 umount /mnt

 

[Ambrosius]

Bist du sicher dass die rootpartitition auf LUKS-Crypt liegt, nach der lsblk Ausgabe sieht das nur nach einem LUKS auf sdb1 aus.

Ja sehr sicher, warum das nicht bei lsblk auftaucht hat mich auch gewundert, vielleicht weil ich sdb1 in dem Moment gemounted hatte, und sda nicht.

fsck muss auf das Filesystem/ die Partition ausgeführt werden, d.h. auf z.B. /dev/sdg3 NICHT auf /dev/sdg

Hab ich auch im zweiten Anlauf getan.

Zu 3.

Ja das wär jetzt mein nächster Schritt gewesen, danke für den Hint. Werd ich heute Abend nochmal versuchen. Es stellt sich nur die Frage, wenn wie ich erwarte mit fsck nicht weiterkomme ob ich dann mit e2fsck doch diesmal nicht im readonly Mode einen Suchlauf starten sollte? Kann ich mir da nicht was auch mit zerschießen wenn die 'Reparatur zu invasiv' werden sollte?

Welche Variablen und Parameter würdet ihr mir empfehlen für den Befehl?

Krenn - FSCK Best Practices
E2fsck _ Man Page

 

[ubu]

Wenn du kein Backup hast zieh dir mit dd Kopien auf eine externe Festplatte.

Die kannst du dann hinterher für Backups verwenden

Komplettkopie:
dd if=/dev/sda of=/media/usbdisk/sda.img für den Notfall

Kopie für fsck
dd if=/dev/sda3 of=/media/usbdisk/sda3.img

Dann sudo fsck.ext4 -c /media/usbdisk/sda3.img

sudo mount -o loop /media/usbdisk/sda3.img /mnt

ls /mnt


Beispiel:
ubu:# sudo dd if=/dev/nvme0n1p2 of=nvme0n1p2.img
3500032+0 Datensätze ein
3500032+0 Datensätze aus
1792016384 Bytes (1,8 GB, 1,7 GiB) kopiert, 26,482 s, 67,7 MB/s

ubu:# file nvme0n1p2.img
nvme0n1p2.img: Linux rev 1.0 ext4 filesystem data, UUID=d7fda5b9-f3dd-4e16-8130-0b70b801be8f (needs journal recovery) (extents) (64bit) (large files) (huge files)

ubu:# sudo fsck.ext4 -c -c nvme0n1p2.img
e2fsck 1.47.0 (5-Feb-2023)
nvme0n1p2.img: Journal wird wiederhergestellt
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet: erledigt
nvme0n1p2.img: Updating bad block inode.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

nvme0n1p2.img: ***** DATEISYSTEM WURDE VERÄNDERT *****
nvme0n1p2.img: 321/109536 Dateien (1.2% nicht zusammenhängend), 92489/437504 Blöcke

ubu:# sudo mount -o loop nvme0n1p2.img /mnt/

ubu:# ls /mnt/
config-5.19.0-40-generic initrd.img invaders.exec memtest86+x64.bin vmlinuz
config-6.2.0-20-generic initrd.img-5.19.0-40-generic lost+found memtest86+x64.efi vmlinuz-5.19.0-40-generic
efi initrd.img-6.2.0-20-generic memtest86+ia32.bin System.map-5.19.0-40-generic vmlinuz-6.2.0-20-generic
grub initrd.img.old memtest86+ia32.efi System.map-6.2.0-20-generic vmlinuz.old

 

[Ambrosius]

1. Bist du sicher dass die rootpartitition auf LUKS-Crypt liegt, nach der lsblk Ausgabe sieht das nur nach einem LUKS auf sdb1 aus.

2. fsck muss auf das Filesystem/ die Partition ausgeführt werden, d.h. auf z.B. /dev/sdg3 NICHT auf /dev/sdg

3. Für ein LUKS device muß dieses erst entschlüsselt werden:
3.1 Entschlüsseln: sudo cryptsetup open /dev/sda3 mycryptdevice --type luks --> Passwort eingeben
3.2 Unter /dev/mapper sollte es jetzt mycryptdevice geben, darauf fsck
3.3 fsck -f /dev/mapper/mycryptdevice
3.4 Danach versuchen zu mounten: mount /dev/mapper/mycryptdevice /mnt
3.5 Testen ls -l /mnt
3.6 umount /mnt

es scheint als hätte ich jetzt ein noch ernsteres Problem an der Backe -> ich kann die Partition nicht mehr entschlüsseln..weder übers Terminal, noch über die Partitionsverwaltung. Krieg den Fehler:

Das verschlüsselte Dateisystem auf der Partition kann nicht entsperrt werden

und

Gerät »/dev/sdax« ist kein gültiges LUKS-Gerät.

Alle anderen Partitionen kann ich problemlos entschlüsseln..sogar über Dolphin, aber mein Root nicht! Das ist jetzt echt Horse s***!

Kann es sein, dass ich mir die Part. zerschossen habe als ich fsck drüber hab laufen lassen während sie noch verschlüsselt war? Weil eine andere Erklärung habe ich nicht...der hat nämlich ziemlich viele Inodes mit Fehlern gefunden, die ja so gesehen in dem verschlüsselten Zustand keine Fehler gewesen sein müssen. Kann fsck grundsätzlich Änderungen/Reperaturen an einer verschlüsselten Part vornehmen??? Sollte ja per Design gar nicht möglich sein....gibts noch ein Schlupfloch hier irgendwo?

 

[ubu]

Das ist leider sogar sehr wahrscheinlich, nein fsck kann ein verschlüsseltes LUKS Volume nicht fixen wenn es verschlüsselt ist.
Erst entschlüsseln, dann fsck auf das cryptdevice nicht auf die partition (siehe 3.3)

 

[zwieblum]

FSCK auf einem verschlüsselten Device soll gar nicht funktionieren, weil fsck das Dateisystem ja nicht erkennt und mit Fehler abbricht.

 

[Ambrosius]

FSCK auf einem verschlüsselten Device soll gar nicht funktionieren, weil fsck das Dateisystem ja nicht erkennt und mit Fehler abbricht

Soweit war auch meine Schlussfolgerung, Problem dabei ist nur, dass ich mir nicht erklären kann weshalb ich jetzt die root_part nicht mehr entschlüsseln kann. Bevor ich fsck liefen lass, konnte ich zwar auch nicht ins OS booten, aber zumindest konnte ich die Partition entschlüsseln um wenigstens dann ins busybox Terminal zu gelangen. Das ist nun auch alles nicht mehr möglich.
Cryptsetup gibt mir nun durchgehend die Meldung:

device /dev/sdx is not a valid luks device
ERROR: root.fsm: cryptsetup failed, bad password pr options?

Und das noch ehe ich überhaupt eine passphrase eingegeben habe.

Also das Problem das ich eingangs hatte ist nicht mehr mein dringenderes Problem, sondern eher das hier jetzt. Und das scheint sich nicht so ohne weiteres auflösen zu lassen.

 

[zwieblum]

Da hast du jetzt aber schlechte Karten, der LUKS Header ist im Eimer

 

[Ambrosius]

Ok, also es besteht wohl auch nicht die Chance dass cryptsetup selbst korrupt ist und der Header intakt? Leider hab ich keine Sicherung des Headers, sonst wär das reversibel.

Ich bin grad nur zu blöd nachzuvollziehen was ich kaputt gemacht habe, eine Neuinstallation ist immer möglich, Daten wurden keine verloren, aber so richtig toll finde ich das alles nicht.

Das einzige was ich gemacht habe, war fsck auf eine verschlüsselte Partition laufen zu lassen. eine Fehlermeldung dazu dass es zuvor entsperrt werden müsste, wär an der Stelle hilfreich gewesen. Dass ich damit den Header zerschossen habe könnte ist aber etwas sehr abenteuerlich.