linux - picard - puddletag
Implementación de un sistema de actualización/actualización para dispositivos Linux incorporados (5)
Tengo una aplicación que se ejecuta en un dispositivo Linux incorporado y de vez en cuando se realizan cambios en el software y ocasionalmente también en el sistema de archivos raíz o incluso en el kernel instalado.
En el sistema de actualización actual, los contenidos del antiguo directorio de la aplicación simplemente se eliminan y los nuevos archivos se copian sobre él. Cuando se han realizado cambios en el sistema de archivos raíz, los nuevos archivos se entregan como parte de la actualización y simplemente se copian sobre los anteriores.
Ahora, hay varios problemas con el enfoque actual y estoy buscando formas de mejorar la situación:
- El sistema de archivos raíz del objetivo que se utiliza para crear imágenes del sistema de archivos no está versionado (no creo que tengamos siquiera los rootfs originales).
- Los archivos de rootfs que entran en la actualización se seleccionan manualmente (en lugar de un diff)
- La actualización crece continuamente y eso se convierte en pita. Ahora hay una división entre actualización / actualización donde la actualización contiene cambios más grandes de rootfs.
- Tengo la impresión de que las comprobaciones de coherencia en una actualización son bastante frágiles si es que están implementadas.
Los requisitos son:
- El paquete de actualización de la aplicación no debe ser demasiado grande y también debe poder cambiar el sistema de archivos raíz en caso de que se hayan realizado modificaciones.
- Una actualización puede ser mucho más grande y solo contiene las cosas que entran en el sistema de archivos raíz (como nuevas bibliotecas, kernel, etc.). Una actualización puede requerir que se haya instalado una actualización.
¿Podría la actualización contener el sistema de archivos raíz completo y simplemente hacer undden la unidad flash del objetivo? - La creación de paquetes de actualización / actualización debe ser lo más automática posible.
Necesito absolutamente alguna forma de hacer versiones del sistema de archivos raíz. Esto tiene que hacerse de una manera que yo pueda calcular algún tipo de diff que pueda usarse para actualizar los rootfs del dispositivo de destino.
Ya examiné Subversion porque lo usamos para nuestro código fuente, pero eso no es apropiado para el sistema de archivos raíz de Linux (permisos de archivos, archivos especiales, etc.).
Ahora he creado algunos scripts de shell que pueden darme algo similar a un svn diff pero realmente me gustaría saber si ya existe una solución que funcione y haya sido probada.
Usando tales diff supongo que una actualización simplemente se convertiría en un paquete que contiene actualizaciones incrementales basadas en un estado de sistema de archivos raíz conocido.
¿Cuáles son sus pensamientos e ideas sobre esto? ¿Cómo implementarías tal sistema? Prefiero una solución simple que pueda implementarse en poco tiempo.
Actualmente, cada vez hay más herramientas de actualización de Linux integradas de código abierto, cada una con un enfoque diferente.
Otro que vale la pena mencionar es RAUC , que se enfoca en el manejo de instalaciones seguras y atómicas de paquetes de actualización firmados en su objetivo, a la vez que es realmente flexible en la forma de adaptarlo a su aplicación y entorno. Las fuentes están en GitHub: https://github.com/rauc/rauc
En general, una buena descripción general y una comparación de las soluciones de actualización actuales que puede encontrar en la página Wiki del Proyecto Yocto sobre las actualizaciones del sistema:
Creo que está viendo mal el problema: cualquier actualización que no sea atómica (p. Ej., Una imagen del sistema de archivos, reemplazar archivos en un directorio) está rota por diseño; si se apaga en el medio de una actualización, el sistema es un ladrillo y para el sistema integrado, la energía se puede apagar en el medio de una actualización.
He escrito un libro blanco sobre cómo actualizar / actualizar correctamente en sistemas Linux embebidos [1]. Fue presentado en OLS. Puede encontrar el documento aquí: https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf
[1] Ben-Yossef, Gilad. "Construir sistemas Linux embebidos compatibles con Murphy". Simposio Linux . 2005.
Estoy totalmente de acuerdo en que una actualización debe ser atómica: recientemente comencé un proyecto de código abierto con el objetivo de proporcionar una forma segura y flexible para la administración del software, con actualizaciones locales y remotas. Sé que mi respuesta llega muy tarde, pero tal vez podría ayudarlo en los próximos proyectos.
Puede encontrar fuentes para "swupdate" (el nombre del proyecto) en github.com/sbabic/swupdate .
Stefano
La atomicidad es crítica para los dispositivos integrados, una de las razones destacadas es la pérdida de potencia; pero podría haber otros como problemas de hardware / red.
La atomicidad es tal vez un poco malentendida; esta es una definición que uso en el contexto de los actualizadores:
- Una actualización siempre se completa completamente, o no se completa
- Ningún componente de software además del actualizador ve una actualización instalada a medias
La actualización de imagen completa con un diseño de partición A / B dual es la forma más simple y probada de lograr esto.
Para Embedded Linux, hay varios componentes de software que quizás desee actualizar y diferentes diseños para elegir; hay un documento más reciente sobre esto disponible aquí: https://mender.io/resources/Software%20Updates.pdf
El archivo se movió a: https://mender.io/resources/guides-and-whitepapers/_resources/Software%2520Updates.pdf
Si está trabajando con Yocto Project, podría estar interesado en Mender.io , el proyecto de código abierto en el que estoy trabajando. Consiste en un cliente y servidor y el objetivo es hacer que sea mucho más rápido y fácil integrar un actualizador en un entorno existente; sin necesidad de rediseñar demasiado ni pasar tiempo en la codificación personalizada / local. También le permitirá administrar actualizaciones centralmente con el servidor.
Puede registrar en diario una actualización y dividir su flash de actualización en dos espacios. La falla de energía siempre lo regresa a la ranura que se está ejecutando actualmente. El último paso es modificar el valor del diario. No atómico y no hay forma de hacerlo de ladrillo. Incluso si falla en el momento de escribir las banderas de la revista. No hay tal cosa como una actualización atómica. Nunca. Nunca lo he visto en mi vida Iphone, Android, mi conmutador de red, ninguno de ellos es atómico. Si no tienes suficiente espacio para hacer ese tipo de diseño, entonces arregla el diseño.