Ripristina da un filesystem danneggiato quando fsck non aiuta

Qualcosa è andato storto nel mio filesystem, Ubuntu lo ha impostato in sola lettura e ora sotto Ubuntu Live Disc, fsck non può risolverlo.

Sono in esecuzione 13.04 e non si avvia - all'avvio, mostra solo il prompt di salvataggio di grub.

È una configurazione semplice, solo un disco rigido su / dev / sda1 ma non si monta nemmeno.

Il programma di installazione può vedere la partizione, che è ext4 e che è la partizione di avvio.

Tuttavia sembra che non riesca a salvare il filesystem eseguendo un'installazione Ubuntu con il disco live di Ubuntu perché non dà alcuna indicazione se sta per sovrascrivere l'intero lotto, quindi non voglio rischiare.

Ho un backup usando backuppc ma stupidamente ho perso i miei dischi di salvataggio. Preferirei evitare un'installazione completa seguita da un ripristino che non ho esperienza nell'esecuzione.

Il nocciolo della questione è che fsck dice che risolve tutto ma in realtà non lo fa, quindi la prossima volta che lo eseguo, ricevo esattamente gli stessi messaggi di errore e correzioni.

Ecco l'output:

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:~$

È esattamente lo stesso di 10 volte prima e sono sicuro che le successive dieci volte lo provo - esattamente gli stessi checksum e gli ID di blocco. Qualsiasi aiuto ricevuto volentieri!

Grazie.

EDIT: fondamentalmente immagino che la domanda sia: questo filesystem è riparabile in situ ora o che le informazioni da fsck significano che il mio disco è morto? E se non è morto, cosa posso fare al di là di quello che ho fatto con fsck?

EDIT: usato tune2fs per identificare i superblocchi e ha eseguito e2fsck -b 01234 / dev / sda1 come alternativa a fsck ... nessun effetto.

EDIT: provare testdisk che mi dice che la partizione è sbagliata. ... OK testdisk non sembra offrire molto.

filesystem ext4 fsck

— Adamo
fonte

provare help.ubuntu.com/community/FilesystemTro troubleshooting

— Avinash Raj

non ho sostanzialmente trattato le cose in quel collegamento con fsck.ext4 -vy / dev / sda1? L'unica differenza è il flag '-p' e con ciò mi dice solo di farlo manualmente - cioè quello che ho tagliato e incollato sopra.

— Adam,

Risposte:

Finalmente ho trovato questo link in cui il tipo di file system ext4 ottiene un bashing ma dopo aver dato tutti i suggerimenti che avevo già provato, dice finalmente di fare questo:

sudo mkfs.ext4 -S /dev/sda1
Questo sostituirà tutti i tuoi superblocchi con i dati corretti, supponendo che la dimensione del blocco sia indovinata correttamente (il valore predefinito è corretto per la maggior parte dei sistemi.) Se è necessario utilizzare questo, leggere il pagina man su -S. Non incolparmi!

ma solo se ti senti fortunato.

Ha riparato la partizione in modo che potessi rileggerla. Tuttavia, ho dovuto correre fsckper correggere gli errori che erano ancora lì e che hanno scaricato il contenuto di / etc e molte altre cose in / lost + trovato, quindi dovrò fare una reinstallazione e ripristinare da backup per farlo ripartire.

— Adamo
fonte

Grazie, interessante Ho avuto il problema con una partizione root ext2 alla quale ho rinunciato alla correzione. Ho testato il comando e "ha funzionato" (ho specificato la dimensione del blocco), ma la partizione è risultata comunque non avviabile dopo che fsck ha dovuto riparare molti settori. Ora mi chiedo cosa sarebbe successo con unix.stackexchange.com/a/193778/59808 .

— Nemo,

Primo: se si dispone di dati importanti su questo disco, sarebbe un buon momento (in realtà un brutto momento) per fare un backup. Vedere Recupero dati: imaging di un dispositivo, un file system o un'unità danneggiati . Forse il tuo disco rigido sta morendo.

Secondo: guarda questo: come posso risolvere il montaggio del mio disco dati dopo un crash?

Terzo: controlla il tuo Harddrive usando Smartmontools ed eventualmente i badblock: sudo badblocks -vsn /dev/sda(Questo potrebbe richiedere del tempo, non farlo se hai un SSD)

— innerand
fonte

Grazie per la modifica! È divertente guardare un fungo di risposta del genere. La risposta a cui ti riferisci riguarda i numeri magici, e non è quello che sto vedendo - in effetti è una delle numerose risposte su askubuntu che ho già visto. Proverò anche il percorso di recupero dei dati mentre non ho altre soluzioni. Ho eseguito il test breve di smartmontools e non ha trovato errori.

— Adam,

Ci scusiamo per la modifica. Perché i filesystem moderni come ext4 sono difficili da rompere, penso sempre prima a un errore hardware. Quando smart dice che il disco è ok non è necessario davvero ok. Perché il tuo fs è corrotto? Se io e te dove fsck non sono in grado di riparare fs, farei un'installazione pulita. Probabilmente sarebbe più facile quindi provare a riparare manualmente gli fs.

— interno e il

OK non preoccuparti, grazie solo per aver risposto! Non ero sarcastico. Ti seguo completamente su quello che stai dicendo. Devo solo riavviare il sistema al più presto possibile. Nel peggiore dei casi ci vorranno 3 giorni per consegnare un nuovo disco rigido, quindi mi piacerebbe trovare una soluzione "senza nuovo hardware" per questo.

— Adam,

secondo il link nella risposta che ho dato di seguito, apparentemente ext4 non è così difficile da rompere. ma comunque.

— Adam,

Host virtuale con 9 Windows e 1 Ubuntu. L'host è andato giù portando con sé tutti e 10. Quando è tornato, Windows è stato avviato correttamente. La macchina Linux mostrava "INCONSISTENZA INASPETTATA" e richiedeva fsck manuale. Non ho mai visto così tante correzioni iNode [dai tempi di Solaris negli anni '90]. Questo non era hardware, era semplicemente un'interruzione di corrente. Non avrei mai pensato di vedere il giorno in cui NTFS avrebbe lanciato EXT4.

— Brain2000,