Wiederherstellung von einem beschädigten Dateisystem, wenn fsck nicht hilft

Bei meinem Dateisystem ist ein Fehler aufgetreten. Ubuntu hat es auf schreibgeschützt gesetzt und jetzt kann es unter Ubuntu Live Disc von fsck nicht behoben werden.

Ich lasse 13.04 laufen und es bootet nicht - beim Start wird nur die Aufforderung zur Rettung von Grubs angezeigt.

Es ist ein einfaches Setup, nur eine Festplatte auf / dev / sda1, aber es wird nicht einmal gemountet.

Das Installationsprogramm kann die Partition erkennen, dass es sich um ext4 und die Boot-Partition handelt.

Es scheint jedoch, dass ich das Dateisystem nicht retten kann, indem ich eine Ubuntu-Installation mit der Ubuntu-Live-Festplatte durchführe, da es keinen Hinweis darauf gibt, ob das Ganze überschrieben werden soll, sodass ich es nicht riskieren möchte.

Ich habe ein Backup mit backuppc, aber ich habe dummerweise meine Rettungsdisketten verloren. Ich würde es vorziehen, eine vollständige Installation zu vermeiden, gefolgt von einer Wiederherstellung, mit deren Ausführung ich noch keine Erfahrung habe.

Der springende Punkt ist, dass fsck sagt, es behebt alles, aber tatsächlich nicht. Wenn ich es das nächste Mal ausführe, erhalte ich genau die gleichen Fehlermeldungen und Fehlerbehebungen.

Hier ist die Ausgabe:

ubuntu@ubuntu:~$ sudo fsck.ext4 -vy /dev/sda1
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
Block bitmap for group 0 is not in group.  (block 2553887680)
Relocate? yes

Inode table for group 0 is not in group.  (block 2440124416)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes

One or more block group descriptor checksums are invalid.  Fix? yes

Group descriptor 0 checksum is 0x761e, should be 0xcf25.  FIXED.
Block bitmap for group 4352 is not in group.  (block 2553887680)
Relocate? yes

Inode table for group 4352 is not in group.  (block 3731970048)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? yes

Group descriptor 4352 checksum is 0x5eda, should be 0x3da3.  FIXED.
Inode bitmap for group 4353 is not in group.  (block 2785042439)
Relocate? yes

Group descriptor 4353 checksum is 0xd8b1, should be 0xedfb.  FIXED.
Inode bitmap for group 4354 is not in group.  (block 838860807)
Relocate? yes

Group descriptor 4354 checksum is 0x1718, should be 0x0438.  FIXED.
Inode bitmap for group 4355 is not in group.  (block 771751943)
Relocate? yes

Group descriptor 4355 checksum is 0x0bc8, should be 0x4170.  FIXED.
fsck.ext4: e2fsck_read_bitmaps: illegal bitmap block(s) for /dev/sda1

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sda1: ********** WARNING: Filesystem still has errors **********

ubuntu@ubuntu:~$

Das ist genau das gleiche wie zehnmal zuvor und ich bin sicher, dass ich es die nächsten zehn Male probiere - genau die gleichen Prüfsummen und Block-IDs. Jede Hilfe gerne erhalten!

Vielen Dank.

EDIT: Grundsätzlich denke ich, die Frage ist: Ist dieses Dateisystem jetzt in situ reparierbar oder bedeuten diese Informationen von fsck, dass meine Festplatte tot ist? Und wenn es nicht tot ist, was kann ich über das hinaus machen, was ich mit fsck gemacht habe?

EDIT: benutzte tune2fs um Superblocks zu identifizieren und lief e2fsck -b 01234 / dev / sda1 als Alternative zu fsck ... no effect.

BEARBEITEN: Versuch testdisk, der mir sagt, dass die Partition schlecht ist. ... OK testdisk scheint nicht viel zu bieten.

filesystem ext4 fsck

— Adam
quelle

versuchen Sie help.ubuntu.com/community/FilesystemTroubleshooter

— Avinash Raj

Habe ich den Inhalt dieses Links nicht im Grunde genommen mit fsck.ext4 -vy / dev / sda1 behandelt? Der einzige Unterschied ist das '-p'-Flag, das mir sagt, dass ich es nur manuell machen soll - dh was ich oben ausgeschnitten und eingefügt habe.

— Adam

Antworten:

Endlich wurde dieser Link gefunden, über den der Dateisystemtyp ext4 ein Bashing erhält. Nachdem ich jedoch alle Tipps gegeben habe, die ich bereits ausprobiert hatte, heißt es schließlich:

sudo mkfs.ext4 -S /dev/sda1
Dies ersetzt alle Ihre Superblöcke mit korrekten Daten, vorausgesetzt, die Blockgröße wird korrekt geschätzt (die Standardeinstellung ist für die meisten Systeme korrekt.) Wenn Sie dies benötigen, lesen Sie bitte zuerst die Manpage auf -S. Beschuldige mich nicht!

aber nur, wenn Sie sich glücklich schätzen.

Die Partition wurde repariert, sodass ich sie erneut lesen konnte. Ich musste jedoch ausführen fsck, um die Fehler zu beheben, die noch vorhanden waren und die den Inhalt von / etc und viele andere Dinge in / lost + found abgelegt haben, sodass ich eine Neuinstallation und Wiederherstellung von ausführen muss Backup, um es wieder in Gang zu bringen.

— Adam
quelle

Danke, interessant. Ich hatte das Problem mit einer ext2-Root-Partition, die ich nicht mehr repariert habe. Ich habe den Befehl getestet und er hat "funktioniert" (ich habe die Blockgröße angegeben), aber die Partition war ohnehin nicht mehr bootfähig, nachdem fsck viele Sektoren reparieren musste. Jetzt frage ich mich, was mit unix.stackexchange.com/a/193778/59808 passiert wäre .

— Nemo

Erstens: Wenn Sie wichtige Daten auf dieser Festplatte haben, ist dies eine gute (eigentlich schlechte) Zeit, um ein Backup zu erstellen. Siehe Datenwiederherstellung: Imaging eines beschädigten Geräts, Dateisystems oder Laufwerks . Möglicherweise stirbt Ihre Festplatte.

Zweitens: Sehen Sie sich Folgendes an: Wie kann ich das Mounten meines Datenlaufwerks nach einem Absturz beheben?

Drittens: Überprüfen Sie Ihre Festplatte mit Smartmontools und eventuell sudo badblocks -vsn /dev/sdafehlerhaften Blöcken.

— innerand
quelle

Danke für die Bearbeitung! Es ist lustig, einen solchen Antwortpilz zu beobachten. Die Antwort, auf die Sie sich beziehen, bezieht sich auf magische Zahlen, und das sehe ich nicht - tatsächlich ist das eine von mehreren Antworten auf askubuntu, die ich bereits angeschaut habe. Ich werde auch die Datenwiederherstellungsroute ausprobieren, solange ich keine anderen Lösungen habe. Habe den smartmontools-Kurztest durchgeführt und keine Fehler gefunden.

— Adam

Entschuldigung für die Bearbeitung. Da moderne Dateisysteme wie ext4 schwer zu knacken sind, denke ich immer zuerst an einen Hardwarefehler. Wenn smart sagt, dass die Festplatte in Ordnung ist, ist das nicht wirklich in Ordnung. Warum ist dein fs korrupt? Wenn ich, wo Sie und fsck nicht in der Lage sind, das fs zu reparieren, würde ich eine saubere Installation machen. Wäre wahrscheinlich einfacher, als zu versuchen, das Problem manuell zu beheben.

— Innerand

OK, keine Sorge, danke nur für die Beantwortung! Ich war nicht sarkastisch. Ich folge dir ganz auf das, was du sagst. Ich muss nur mein System so schnell wie möglich wieder in Betrieb nehmen. Im schlimmsten Fall dauert es 3 Tage, bis eine neue Festplatte geliefert wird. Daher würde ich gerne eine Lösung finden, die keine neue Hardware enthält.

— Adam

Laut dem Link in der Antwort, die ich unten gegeben habe, ist ext4 anscheinend nicht so schwer zu brechen. aber was auch immer.

— Adam

Virtueller Host mit 9 Windows und 1 Ubuntu. Host ging alle 10 mit nach unten. Als es wieder da war, wurde alles von Windows hochgefahren. Der Linux-Rechner zeigte "UNEXPECTED INCONSISTENCY" an und erforderte manuelles fsck. Ich habe noch nie so viele iNode-Korrekturen gesehen [seit Solaris in den 90er Jahren]. Dies war keine Hardware, sondern nur ein Stromausfall. Ich hätte nie gedacht, ich würde den Tag sehen, an dem NTFS EXT4 pwned.

— Brain2000