Esta semana pasé un mal momento con mi instalación de FreeBSD, provocado por un journal corrupto que causaba kernel panics:

root@hal9000:/usr/home/emi # last | grep "Jul 12" | grep crash
emi        ttyv0                           Thu Jul 12 11:18 - crash  (00:06)
emi        pts/1    :0                     Thu Jul 12 10:55 - crash  (00:12)
emi        pts/0    :0                     Thu Jul 12 10:55 - crash  (00:12)
emi        :0                              Thu Jul 12 10:55 - crash  (00:12)
emi        pts/1    :0                     Thu Jul 12 10:47 - crash  (00:07)
emi        pts/0    :0                     Thu Jul 12 10:47 - crash  (00:07)
emi        :0                              Thu Jul 12 10:47 - crash  (00:07)
emi        ttyv0                           Thu Jul 12 10:28 - crash  (00:12)
emi        pts/1    :0                     Thu Jul 12 10:05 - crash  (00:08)
emi        pts/0    :0                     Thu Jul 12 10:05 - crash  (00:08)
emi        :0                              Thu Jul 12 10:05 - crash  (00:09)

Luego de pelear varias horas pensando que se trataba de un problema con el upgrade (sí, los panics comenzaron justo después de reiniciar luego del upgrade a 11.2, es increíble, cuando te tiene que pasar algo malo, te pasa en el peor momento).



Luchando para intentar debuggear sin éxito el panic (nunca logré grabar a disco el crash dump ni evitar que el kernel se reinicie automáticamente en caso de panic), decidí directamente filmarlo para poder recuperar el cuadro exacto donde ocurría y no perder más tiempo:

panic: ffs_valloc: dup alloc

La función ffs_valloc (parte del sistema de archivos UFS) se encarga de alocar un vnodo en el sistema de archivos. Al detectar algún tipo de duplicación (el inodo obtenido ya está en uso) que pueda corromper el sistema de archivos y provocar pérdida de datos, arroja este panic:

/sys/ufs/ffs/ffs_alloc.c

/sys/ufs/ufs/inode.h

Ahora bien, la situación es clara: el sistema de archivos está corrupto. Sin embargo (y aquí es donde se complica el asunto) ya había sido recuperado. El problema es que había sido recuperado utilizando el journal de UFS, con lo cual posiblemente se haya corrompido también el journal.

La solución entonces es correr un chequeo completo del sistema de archivos, ignorando completamente el journal, proceso conocido como "full fsck".

Por supuesto antes de correr fsck en modo exhaustivo, se debe verificar que el sistema de archivos no esté montado, o esté montado en modo de sólo escritura:

Como se observa, es posible re-montar el sistema de archivos a analizar en modo de sólo lectura utilizando el comando:

# mount -o rw /

Luego, para realizar el análisis completo del filesystem, simplemente se debe correr fsck como de costumbre, pero indicar que no use el journal en el modo interactivo:

El proceso de análisis y recuperación ignorando el journal se inicia, y tal como (apenas) se observa en la captura subrayado en color verde, fsck indica que se procede en modo "full fsck":

Es recomendable correr este proceso dos veces seguidas para asegurarse de que el sistema de archivos quede en un estado consistente.

De esta forma logré recuperar mi sistema personal.

Cabe destacar que es recomendable ejecutar este tipo de recuperación (especialmente cuando se trata del sistema de archivos raíz) en single user mode (iniciar con la opción 2 en el menú del gestor de inicio de FreeBSD).

Referencias


Tal vez pueda interesarte


Compartí este artículo