Muchas tarjetas SD son bastante frágiles. He tenido un pi durante aproximadamente 2 años y las principales fallas se debieron a que la tarjeta SD se corrompió por una razón u otra.
Me pregunto si se ha realizado algún desarrollo para "fortalecer" la tarjeta SD en el arranque. Recuerdo haber tenido algo como esto en un proyecto anterior, donde uboot elegiría entre 12 tarballs si alguno de ellos tuviera una suma de verificación crc32 no válida. Luego volvería a copiar el validado a todos los demás que se modificaron después de un arranque exitoso.
Me gustaría usar mi pi en una configuración "permanente" y sería genial si pudiera funcionar sin volver a flashear la tarjeta.
¿Hay algún desarrollo ya hecho de esta manera? Si bien la idea general es bastante trivial, hacer que uboot funcione correctamente suele ser un proceso bastante doloroso que me gustaría evitar.
EDITAR:
Después de una excavación más profunda, parece que lo que estaba imaginando podría no ser posible, o posible de una manera que ofreciera alguna ventaja significativa. Aquí se describe el proceso de arranque . El código en el que trabajé se estaba ejecutando en el primer nivel de arranque ya que mi placa tenía un flash programable para esto. Con el pi, esto se almacena en una ROM de fábrica. Todo lo demás proviene de la tarjeta SD, por lo que si la tarjeta se daña, el gestor de arranque de la segunda etapa tiene tantas posibilidades de ser destruido como cualquier otra partición.
Tal vez sea posible abusar del cargador de arranque ROM para este propósito, pero es difícil decir cómo. El código también parece patentado.
Edición 2:
La explicación real del proceso de arranque está en conflicto dependiendo de las fuentes. Trataré de leer más sobre eso.
No debería experimentar una corrupción dramática frecuente, incluso si el poder se pierde ocasionalmente.
Si un sistema de archivos tiene un valor distinto de cero en la sexta columna de
/etc/fstab, se verificará para ver si es necesario escanearlo en busca de errores antes de montarlo. Las distribuciones regulares de pi (deberían) tener este conjunto/dev/mmcblk0p1y la partición del sistema de archivos raíz (en Raspbianmmcblk0p2). Lo que esto significa para los sistemas de archivos ext4 (como la raíz fs) es que esto sucede independientemente de cada N monta; para el valor de N, consulte "Recuento de montaje máximo" en la salida detune2fs -l /dev/[partition]; puede ajustar este valor usandotune2fs -c(verman tune2fs).También se escaneará si el sistema de archivos no se desmontó correctamente. Esto se hace con
e2fsck. En la mayoría de los casos, todo saldrá bien. Sin embargo, existe la posibilidad de que pueda perder datos por corrupción; se dejará evidencia de esto/lost+found. Si es posible (y generalmente lo es), el sistema de archivos se dejará en un estado utilizable y no dañado después. La pregunta entonces es si se perdió algún componente crítico en la solución, pero nuevamente, esto sería muy inusual.La razón por la que es poco probable que afecte algo crítico es que la mayoría de esas cosas, aunque técnicamente no son de solo lectura, no cambian en el curso normal de las cosas. El sistema tiene toneladas de cosas
/biny se/libcarga en la memoria en cualquier punto dado, pero no hay intención de alterar su fuente en el disco, por lo que no hay posibilidad de que el disco se desincronice con esos cambios inexistentes.Aunque no sé cuáles son las reglas para la primera partición vfat que contiene el kernel y el firmware (ya que no está formateado por extensión), asumiría que es posible realizar una verificación similar y, en cualquier caso, la lógica del último párrafo se aplica: esas cosas solo cambian para las actualizaciones del sistema. De hecho, si quieres ser realmente paranoico, podrías tenerlo montado solo para lectura, excepto para las actualizaciones (o no montado en absoluto, ya que no es necesario una vez que se completa el arranque normal).
Después de todo esto, nunca debería experimentar una corrupción grave a menos que realmente tire los dados con frecuencia cortando el poder (e incluso entonces debería ser poco frecuente). Si a menudo experimentas corrupción, hay algo muy gravemente mal. Ha habido al menos algunas personas aquí que informan problemas de corrupción incluso cuando usan un sistema de archivos de solo lectura , lo cual es un poco desconcertante. Implica que la corrupción es causada arbitrariamente por hardware defectuoso o un error de software.
Y, de hecho, creo que hubo un error que podría haber afectado pis arbitrariamente desde 2013 hasta mediados de 2014 (suponiendo que el sistema operativo se mantenga actualizado). Tengo el presentimiento de que hemos tenido menos "¡Mi tarjeta SD está dañada!" publicaciones en los últimos 4-6 meses (pero Nota: no he hecho ninguna contabilidad real para confirmar eso).
fuente
Es posible que desee utilizar una unidad flash USB / disco duro USB.
Son usualmente más confiables que las tarjetas SD
Aquí hay un hilo que describe cómo hacerlo
fuente
La autocuración es un problema con cualquier distribución de Linux donde fsck está en el sistema de archivos más propenso a la corrupción. Ese es un problema que raspbian comparte con casi todas las distribuciones de Linux: en estos días les gusta poner todo [incluido / boot en el caso de Ubuntu !! ??] en una gran partición ext4.
Una partición raíz de solo lectura hace maravillas para evitar el problema de eliminación de arranque donde Linux se encuentra con problemas del sistema de archivos antes de que haya tenido la oportunidad de ejecutar fsck.
Pero incluso una raíz de lectura / escritura que rara vez se actualiza es un gran paso adelante.
Raspbian funciona bien en una raíz de solo lectura. La configuración requiere un poco de esfuerzo y, por supuesto, debe estar preparado para "montar -o remontar, rw /" antes de cualquier cambio en el sistema de archivos raíz.
fuente