Mientras cambiaba el tamaño de una partición dentro de gparted live, el kernel alcanzó un GPF, lo que me obligó a reiniciar la máquina. (dmesg aquíhttps://pastebin.com/LGqXA3p9). Da la casualidad de que la partición que se estaba moviendo estaba en una matriz md RAID5 y no era en absoluto relevante para que el sistema arrancara, lo que significa que estoy nuevamente en funcionamiento y puedo husmear un poco más.
La ejecución de dumpef2s produce 'dumpe2fs: encabezado de extensión dañado al leer el superbloque del diario' y fsck.ext4 dice "El superbloque tiene un diario no válido (inodo 8)". Aún no lo he aclarado. testdisk sólo ve la nueva partición y ninguno de los archivos; Photorec sería más complicado de lo que vale. Testdisk solo muestra la mitad del archivo movido y nada más.
El último mensaje de la herramienta resize2fs fue "nodo 279256/593596231", que no estoy seguro de cómo interpretar. ¿Hay alguna manera de aprovechar los datos del sistema de archivos no movidos?
Respuesta1
Después de investigar debajo de la superficie, tuve suerte: una herramienta (patentada) llamada r-studio encontró el superbloque del sistema de archivos; e2image aún no había anulado el sistema de archivos original. Armado con los números de sector, pude simplemente recrear la partición anterior y no encontré ninguna pérdida de datos. Estaba en el proceso de intentar abrirme camino a través del volumen buscando el UUID que todavía tenía, que era más o menos el mismo enfoque pero hecho manualmente en comparación con la herramienta antes mencionada. No hace falta decir que hice copias de seguridad de e2image de los metadatos del sistema de archivos y estaré investigando por qué falló gparted.