Beim Ändern der Größe einer Partition innerhalb von gparted live stieß der Kernel auf einen GPF, was mich zu einem Neustart des Rechners zwang. (dmesg hierhttps://pastebin.com/LGqXA3p9). Zufällig befand sich die verschobene Partition auf einem MD-RAID5-Array und war für den Systemstart überhaupt nicht relevant. Das heißt, ich bin jetzt wieder einsatzbereit und kann noch ein bisschen herumstöbern.
Das Ausführen von dumpef2s ergibt „dumpe2fs: Beschädigter Extent-Header beim Lesen des Journal-Superblocks“ und fsck.ext4 sagt „Superblock hat ein ungültiges Journal (Inode 8)“. Das habe ich noch nicht gelöscht. testdisk sieht nur die neue Partition und keine der Dateien; Photorec wäre mehr Aufwand als es wert ist. Testdisk zeigt nur eine halb verschobene Datei und sonst nichts.
Die letzte Meldung des Tools resize2fs war „Knoten 279256 / 593596231“, was ich nicht genau interpretieren kann. Gibt es eine Möglichkeit, auf die nicht verschobenen Dateisystemdaten zuzugreifen?
Antwort1
Nachdem ich mich tiefer in die Materie vertieft hatte, hatte ich Glück – ein (proprietäres) Tool namens r-studio fand den Superblock des Dateisystems – e2image hatte das ursprüngliche Dateisystem noch nicht überschrieben. Mit den Sektornummern bewaffnet konnte ich die alte Partition einfach neu erstellen und stellte fest, dass keinerlei Daten verloren gingen. Ich war gerade dabei, mich durch das Volume zu grappen und nach der UUID zu suchen, die ich noch hatte, was ungefähr der gleiche Ansatz war, aber manuell durchgeführt wurde, im Gegensatz zum oben genannten Tool. Selbstverständlich habe ich e2image-Backups der Metadaten des Dateisystems erstellt und werde untersuchen, warum gparted fehlgeschlagen ist.