El sistema de ficheros de la fonera

Creo que a raiz de la gente inquieta que escribe a mi email, que anda cacharreando con la fonera, voy a poner una descripción del sistema de ficheros de la fonera, más que nada para que quede escrito y evitarme así reiteraciones en las explicaciones por email.

Resulta un poco triste el hecho de que Fon no ponga ningún medio ni facilidad para los que nos gusta cacharrear con la fonera.
¿Sería mucho pedir una paginita web en dónde explicasen estas cosillas en lugar de hacernos perder el tiempo experimentando?

En fin... si no tienen tiempo ni de responder los interrogantes abiertos en sus foros, como la pérdida reiterativa de los SSIDs, la mala implementación del WAP que funciona sólo en determinados aparatos, y otra serie de consultas abiertas por los usuarios que quedan sin respuesta, dado que el foro no es visitado por alguien con 'potestad' como para responder esas preguntas a los usuarios...

No sirve con poner un foro... hay que poner a alguien que derive las preguntas hacia los empleados de fon a quienes competan dichas preguntas y que se vean respuestas 'oficiales' y no el murmullo y el rumoreo existente ahora en los foros fon, en los que no se resuelve nada de nada.

¿La fonera no tiene discos ni particiones?

Efectivamente, no tiene discos no, ni particiones (pensando en particiones como la idea a la que estamos acostumbrados).

En su lugar, tiene una memoria flash, en la que se han definido una serie de zonas o bloques, que actuan a modo de 'particiónes'.

En primer lugar, vamos a repasar cómo es el arranque de un PC normalito, y luego lo compararé con el de la fonera.

Los microprocesadores, por construcción, cuando se les 'enchufa', es decir, cuando se les aplica corriente, lo primero que hacen es ir a un 'punto de entrada', leen lo que allí hay y desde ahí, ejecutan código.
El fabricante de la placa base donde va enchufado el micro, ha de 'mapear' en dicho punto de entrada, que a ver si nos entendemos no es más que una dirección de memoria, algún sistema de almacenamiento de datos para que el mircro lea de él y ejecute el código que allí está contenido.

En el caso de los PCs, este sistema de almacenamiento es la BIOS, que es lo primero que el micro ejecuta. La BIOS no es más que un chip que almacena el código que inicializa los periféricos de la placa base.
Una vez que el micro ejecuta el código de la bios (con las configuraciones que hayamos realizado en cuanto a nuestros discos, que queremos que arranque primero, si el diskette, el disco duro o el cd, etc), pasa a ejecutar el procedimiento de arranque, que en el caso de los PCs consiste en leer un determinado sector del disco (el sector de arranque), cargándolo en memoria y, ejecutándolo después.
Este mecanismo es el que nos permite instalar con posterioridad un sietema operativo, como el linux, el windows, etc...

En la fonera las cosas son algo diferentes.
No existe un chip dedicado para esto como es la BIOS, en su lugar, el microprocesador, en su punto de entrada, tiene mapeada una FLASH, en cuya dirección correspondiente al punto de entrada tiene instalado un programilla llamado RedBootque es el encargado de realizar el arranque del chisme.

El RedBoot no sólo es un programa de arranque, sino que dispone de una serie de mecanismos para poder reflashear cuanquiera de los bloques de la flash mediante varios protocolos: por http, por ftft o por consola serie.
Es una pena que en fon hayan seguido la política del oscurantismo, y hayan grabado el RedBoot de manera que cuando arranca, inicializa el interface de red con dirección ip 0.0.0.0, lo cual hace imposible el reflasear cuanquiera de los bloques usando un simple servidor tftp desde otro ordenador.
En fin, que están empañados en negar al usuario el que trasteé con la fonera por SSH, ya que para poder liberar el SSH nos obliga a entrar por la consola serie (para lo cual hace falta el circuitillo para traducir los niveles de las señales eléctricas).
Si el RedBoot inicializase al arrancar el interface de red con una dirección 'normalita' podríamos actualizar el sistema de ficheros raiz, poniendo en su lugar una copia en la que el SSH no estuviese capado... :) pero en fin, que de momento tendreis que procuraros el circuitillo, vamos...

He dicho que la flash está organizada en zonas o 'bloques', pues bien, el primero de ellos está precisamente reservado para el RedBoot, y el resto... el resto los vemos ahora mismo:

Los bloques de la flash

La flash de la fonera está dividida o compartimentada de la siguiente manera:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 006f0000 00010000 "rootfs"
mtd2: 00570000 00010000 "rootfs1"
mtd3: 00010000 00010000 "config"
mtd4: 000b0000 00010000 "vmlinux.bin.l7"
mtd5: 0000f000 00010000 "FIS directory"
mtd6: 00001000 00010000 "RedBoot config"
mtd7: 00010000 00010000 "board_config"
root@OpenWrt:~# root@OpenWrt:~# cat /proc/mtd

Bien, como podeis ver, hay 7 boques diferentes.
El primero hemos dicho que es la del programa de arranque, el RedBoot.
El RedBoot vendría a ser una mezcla de bios y de gestor de arranque (como el Lilo, o el gestor de arranque de los Windows).
En la fonera, es el encargado de cargar la imagen del kernel de Linux, que está situada en el bloque 4, y de ejecutarla una vez cargada, pasándole los parámetros necesarios para que encuentre la partición raiz y el resto de cosas que necesita.

Vemos tambien que el bloque 1 está titulado como rootfs, es decir, root file system, pero tambien vemos que el bloque 2 está titulado como rootfs1, ¿para que será esto?, :)

Bien, aqui va, el bloque 1 contiene el sistema de ficheros raiz de la fonera, y el bloque 2, contiene los cambios que se han realizado en el sistema de ficheros a partir de lo que contiene el bloque 1.
Así explicado parece lioso... vamos a explicar un poquito cómo está montado el asunto:

El sistema de ficheros mini_fo

Es una práctica común usar en sistemas embebidos como el de la fonera un sistema que permita 'restaurar' el chisme al estado en el que salió de la fábrica, ya sea haciendo un reset o de alguna otra manera.

La fonera para esto, usa un módulo del kernel llamado mini_fo

El mini_fo, consiste en un tipo de sistema de ficheros un poquito especial.
Su utilidad es la de permitir hacer que un sistema de ficheros de 'sólo lectura' se pueda utilizar como si se tratase de un sistema de 'lectura/escritura'.

Su funcionamiento es el siguiente: partiendo de un sistema de ficheros de sólo lectura (en el caso de la fonera, el sistema de ficheros situado en el bloque 1 de la flash) y de un segundo sistema de ficheros, (que en el caso de la fonera es el sistema montado en el directorio /jffs, que realidad está montado sobre el bloque 2 de la flash), es capaz de ''interceptar' todos los cambios que realicemos en los ficheros, haciendo que dichos cambios sean grabados en el directorio /jffs

Es decir, cuando entramos por ssh en la fonera, el sistema de ficheros que estamos viendo al hacer un simple ls, es la mezcla 'en directo' del contenido del sistema de ficheros raiz más los cambios efectuados con anterioridad, que son grabados en el directorio /jfss, que a su vez son grabados en un bloque diferente de la flash.

Esto es algo muy interesante, ya que nos permite deshacer fácilmente los cambios que hayamos hecho en nuestra fonera con suma facilidad, ya sea borrando ese directorio (el /jffs) o ejecutando el proceso de reseteado de la fonera, que consiste en mantener pulsado el botón de reset unos 15 segundos mientras enchufamos la fonera.

Con esta premisa, siempre y cuando no toquemos el contenido del bloque 1 de la flash, estaremos tranquilos de poder retornar la fonera a su estado inicial, lo cual nos da mucho juego a la hora de experimentar cosas en ella.

La única ocasión en la que el bloque 1 es modificado es cuando actualizamos el firmware con un fichero de los proporcionados por fon, los cuales pueden ser, o bien una actualización, es decir, que cambien algunos ficheros, añadan o borren algúno de ellos o bien una substitución total.

El único upgrade publicado por fon hasta ahora es el que actualiza las foneras de la versión Version 0.7.0 rev 2 a la versión Version 0.7.0 rev 4
(es un poco triste que en la página de fon no pongan para que coño es el fichero, y uno haya tenido que averiguarlo destripando a ver que es lo que hace la fonera cuándo intentas actualizarla. Si me animo pondré un resumen de cómo se realiza esa actualización).

Formas de revivir tu fonera ante un desastre

Hace dos dias, creí haber convertido mi fonera en un ladrillo inservible, y ya estaba liándome la manta a la cabeza y poniéndome las pilas investigando cómo restaurarla mediante el RedBoot.
En mi caso, el invento del mini_fo se había vuelto un poco loco... ocultándome todo el directorio /lib , (a pesar de estar vacío el directorio /jfss).
Se conoce que en alguno de mis cacharreos, algo se corrompió durante el proceso y me era imposible restaurar el /lib porque el mini_fo me decía que ya existia un directorio con ese nombre, sin embargo ni me dejaba verlo ni me dejaba copiarlo ni borrarlo ni nada de nada.
Como consecuencia, al no tener el directorio /lib, el programa busybox, que es quien gestiona la mayor parte de los comandos de la fonera no me dejaba hacer casi nada... asi que la fonera arrancaba pero luego así se quedaba, ni inicializaba los interfaces de red (con lo cual ni ssh ni nada) ni llamaba a fon ni nada de nada.

Tuve que entrar por la consola serie, borrar el /jfss y su bloque de flash correspondiente y asi pude restaurar mi fonera a su estabo de fábrica.

Sin embargo, hay otros métodos antes que probar, que están resumidos en la página web de freddy (no sé su nombre real).
El enlace es el siguiente: Howto factory reset en el que basicamente resume unos cuántos métodos para resetear la fonera a su estado de fábrica.
Os pongo por aqui una breve traducción del documento:

Método 1
Presionar el botón de reset durante 15 segundos (o más).
Esto requiere una fonera que no en la que no haya sido corrompido el bloque de flash que contiene el sistema de ficheros raiz.
Supongo que lo que hará es formatear el bloque de la flash que contiene el /jfss deshaciendo así los cambios que se hayan hecho en la fonera.

Método 2
Consiste en borrar el directorio /jfss ejecutando desde una consola de la fonera:

rm -R /jffs/*

Para lo cual, necesitamos tener acceso a una consola dentro de la fonera, ya sea por SSH o por puerto serie.

Método 3
Cuando todo lo anterior falla, y no sonsigues tener acceso por la consola serie:

(Has de estar conectado por el puerto serie con un programa teminal y usando el circuito propuesto, claro):

Tan pronto como aparezca el mensaje:

Please press Enter to activate this console.

pulsa Enter y ahora, dándote un poco de prisa:

Pega la línea: (es decir, tecleala en algun editor, la copias y la pegas en la consola:)

cat /proc/mtd

y pulsas el Enter.
Te ha de aparecer la lista de bloques de la flash, que tiene esta pinta:

        dev:    size   erasesize  name
        mtd0: 00030000 00010000 "RedBoot"
        mtd1: 006f0000 00010000 "rootfs"
        mtd2: 00560000 00010000 "rootfs1"
        mtd3: 00010000 00010000 "config"
        mtd4: 000b0000 00010000 "vmlinux.bin.l7"
        mtd5: 0000f000 00010000 "FIS directory"
        mtd6: 00001000 00010000 "RedBoot config"
        mtd7: 00010000 00010000 "board_config"

Bien, has de buscar que número de bloque tiene el bloque etiquetado como 'rootfs1', y quedarte con qué número de bloque es (en este caso el bloque mtd:2, osea, bloque 2)

Para después hacer lo siguiente:

Resetea de nuevo la fonera (apaga y enciende)
Y cuando aparezca de nuevo el mensaje de que pulses Enter para activar esta consola, pegas la siguiente línea esta vez:

echo -ne '\xde\xad\xc0\xde' > "/dev/mtdblock/2"

(Usando claro está el número de bloque correspondiente que hemos obtenido anteriormente, en este caso el bloque 2).

Una vez hecho esto, reseteamos de nuevo, solo que esta vez, la fonera nos soltará este mensaje:

Please press Enter to activate this console. 
jffs2_scan_eraseblock(): End of file system marker found at 0x0
jffs2_build_filesystem(): unlocking the mtd device... done.
jffs2_build_filesystem(): erasing all blocks after the end marker...
        

Es decir, lo que hará es reinicializar ese bloque, que como hemos visto más arriba, corresponde al bloque asignado al directorio /jfss cargándonos así aquellos cambios que hayamos realizado respecto al contenido original de fábrica de la fonera.

Hay otro método no expuesto por freddy que consiste en enviar vía serie al RedBoot una imagen nueva para el sistema de ficheros raiz (el bloque 1), pero que es un poco más rollo de acometer y sinceramente, no me apetece probar, por si la imagen que tengo está mal generada, no vaya a ser que definitivamente convierta mi cacharrín en un ladrillo ó pisapapeles :)
Esa prueba la reservo para el día que me cargue algo más serio... XD