Recuperarse de un sistema de archivos dañado cuando fsck no ayuda

Algo salió mal con mi sistema de archivos, Ubuntu lo configuró en solo lectura y ahora en Ubuntu Live Disc, fsck no puede solucionarlo.

Estoy ejecutando 13.04 y no arrancará: al inicio, solo muestra el mensaje de rescate de grub.

Es una configuración sencilla, solo un disco duro en / dev / sda1 pero ni siquiera se monta.

El programa de instalación puede ver la partición, que es ext4 y que es la partición de arranque.

Sin embargo, parece que no puedo rescatar el sistema de archivos haciendo una instalación de Ubuntu con el disco en vivo de Ubuntu porque no da ninguna indicación de si está a punto de sobrescribir todo, así que no quiero arriesgarme.

Tengo una copia de seguridad usando backuppc pero estúpidamente perdí mis discos de rescate. Prefiero evitar una instalación completa seguida de una restauración que no tengo experiencia en la ejecución.

El quid de la cuestión es que fsck dice que soluciona todo pero en realidad no lo hace, por lo que la próxima vez que lo ejecute, recibo exactamente los mismos mensajes de error y correcciones.

Aquí está el resultado:

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

Eso es exactamente lo mismo que 10 veces antes y estoy seguro de que las próximas diez veces lo intento, exactamente las mismas sumas de comprobación y ID de bloque. Cualquier ayuda recibida con mucho gusto!

Gracias.

EDITAR: básicamente supongo que la pregunta es: ¿este sistema de archivos se puede reparar in situ ahora o esa información de fsck significa que mi disco está muerto? Y si no está muerto, ¿qué puedo hacer más allá de lo que hice con fsck?

EDITAR: usó tune2fs para identificar superbloques y ejecuté e2fsck -b 01234 / dev / sda1 como una alternativa a fsck ... sin efecto.

EDITAR: prueba testdisk que me dice que la partición es mala. ... OK testdisk no parece ofrecer mucho.

filesystem ext4 fsck

— Adán
fuente

intente help.ubuntu.com/community/FilesystemSolución de problemas

— Avinash Raj

¿No he cubierto básicamente las cosas en ese enlace con fsck.ext4 -vy / dev / sda1? La única diferencia es la bandera '-p' y con eso me dice que lo haga manualmente, es decir, lo que corté y pegué arriba.

— Adam

Respuestas:

Finalmente encontré este enlace donde el sistema de archivos tipo ext4 recibe un golpe, pero después de dar todos los consejos que ya había probado, finalmente dice hacer esto:

sudo mkfs.ext4 -S /dev/sda1
Esto reemplazará todos sus superbloques con datos correctos, suponiendo que el tamaño de bloque se adivine correctamente (el valor predeterminado es correcto para la mayoría de los sistemas). Si necesita usar esto, lea primero la página de manual en -S. ¡No me culpes!

pero solo si te sientes con suerte.

Se arregló la partición para que pudiera leerlo de nuevo. Sin embargo, tuve que ejecutar fsckpara corregir los errores que todavía estaban allí, y que arrojaron el contenido de / etc y muchas otras cosas en / lost + found, así que tendré que volver a instalar y restaurar desde copia de seguridad para que vuelva a funcionar.

— Adán
fuente

Gracias interesante. Tuve el problema con una partición raíz ext2 que dejé de arreglar. Probé el comando y "funcionó" (especifiqué el tamaño del bloque), pero la partición terminó siendo no arrancable de todos modos después de que fsck tuvo que arreglar muchos sectores. Ahora me pregunto qué habría pasado con unix.stackexchange.com/a/193778/59808 .

— Nemo

Primero: si tiene datos importantes en este disco, este sería un buen momento (en realidad un mal momento) para hacer una copia de seguridad. Consulte Recuperación de datos: imágenes de un dispositivo, sistema de archivos o unidad dañados . Quizás tu disco duro esté muriendo.

Segundo: Mira esto: ¿Cómo puedo arreglar el montaje de mi unidad de datos después de un bloqueo?

Tercero: revise su disco duro usando Smartmontools y eventualmente bloqueos defectuosos: sudo badblocks -vsn /dev/sda(Esto puede tomar algún tiempo, no haga esto si tiene un SSD)

— innerand
fuente

Gracias por la edición! Es divertido ver un hongo de respuesta como ese. La respuesta a la que se refiere es con respecto a los números mágicos, y eso no es lo que estoy viendo, de hecho, esa es una de varias respuestas en askubuntu que ya vi. Probaré la ruta de recuperación de datos también mientras no tenga ninguna otra solución. Ejecuté la prueba corta de smartmontools y no encontró ningún error.

— Adam

Perdón por la edición. Debido a que los sistemas de archivos modernos como ext4 son difíciles de romper, siempre estoy pensando primero en una falla de hardware. Cuando smart dice que el disco está bien, no es necesario realmente bien. ¿Por qué está corrupto tu fs? Si yo y fsck no pudiéramos reparar el fs, haría una instalación limpia. Probablemente sería más fácil que tratar de arreglar el fs manualmente.

— innerand

OK, no te preocupes, ¡gracias por responder! No estaba siendo sarcástica. Te sigo completamente en lo que estás diciendo. Solo tengo que hacer que mi sistema vuelva a funcionar lo antes posible. En el peor de los casos, tardará 3 días en entregar un nuevo disco duro, por lo que me gustaría encontrar una solución 'sin hardware nuevo' para eso.

— Adam

Según el enlace en la respuesta que di a continuación, aparentemente ext4 no es tan difícil de romper. Pero lo que sea.

— Adam

Host virtual con 9 Windows y 1 Ubuntu. El anfitrión cayó y se llevó los 10. Cuando regresó, todas las ventanas se iniciaron. La máquina Linux mostraba "INCONSISTENCIA INESPERADA" y requería fsck manual. Nunca he visto tantas correcciones de iNode [desde Solaris en los años 90]. Esto no era hardware, era puramente un corte de energía. Nunca pensé que vería el día en que NTFS se extendió EXT4.

— Brain2000