Implementación de un sistema de actualización/actualización para dispositivos Linux embebidos

Tengo una aplicación que se ejecuta en un dispositivo Linux incrustado 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 núcleo 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 antiguos.

Ahora, hay varios problemas con el enfoque actual y estoy buscando maneras de mejorar la situación:

  • El sistema de archivos raíz del destino que se utiliza para crear imágenes del sistema de archivos no está versionado (no creo que tengamos los rootfs originales).
  • Los archivos 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 un pita. Ahora hay una división entre actualización / actualización donde la actualización contiene cambios de raíces más grandes.
  • Tengo la impresión de que los controles de coherencia en una actualización son bastante frágiles si se implementan.

Los requisitos son:

  • El paquete de actualización de la aplicación no debe ser demasiado grande y también debe ser capaz de 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 todo el sistema de archivos raíz y simplemente hacer un dd en la unidad flash del destino?
  • La creación de los paquetes update/upgrade debe ser lo más automática posible.

Necesito absolutamente alguna manera de hacer el control de versiones del sistema de archivos raíz. Esto tiene que hacerse de una manera, que puedo calcular algún tipo de diff a partir de él que se puede utilizar para actualizar los rootfs del dispositivo de destino.

I ya investigamos Subversion ya que usamos eso para nuestro código fuente, pero eso es inapropiado para el sistema de archivos raíz de Linux (permisos de archivo, 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 de trabajo y probada para esto.

Usando tales diff Supongo que una actualización simplemente se convertiría en un paquete que contiene actualizaciones incrementales basadas en una raíz conocida estado del sistema de archivos.

¿Cuáles son sus pensamientos e ideas sobre esto? ¿Cómo implementaría tal sistema? Prefiero una solución simple que se pueda implementar en poco tiempo.

Author: Craig McQueen, 2011-08-04
Source

5 answers

Creo que usted está mirando mal en el problema - cualquier actualización que no es atómica (por ejemplo, dd una imagen del sistema de archivos, reemplazar archivos en un directorio) está roto por el diseño - si la energía se apaga en el medio de una actualización del sistema es un ladrillo y para el sistema integrado, la energía puede apagarse 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. "Building Murphy-compatible embedded Linux systems." Linux Symposium . 2005.

 31
Author: gby,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-12-02 21:28:24

Estoy totalmente de acuerdo en que una actualización debe ser atómica - He comenzado recientemente un proyecto de Código Abierto con el objetivo de proporcionar una forma segura y flexible para la gestión de software, con actualización local y remota. Sé que mi respuesta llega muy tarde, pero tal vez podría ayudarle en los próximos proyectos.

Puede encontrar fuentes para "swupdate" (el nombre del proyecto) en github.com/sbabic/swupdate.

Stefano

 9
Author: sbabic,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-12-30 09:15:50

Actualmente, hay bastantes herramientas de actualización de Linux embebidas de código Abierto en crecimiento, con un enfoque diferente cada una.

Otro que vale la pena mencionar es RAUC, que se centra en el manejo de instalaciones seguras y atómicas de paquetes de actualizaciones firmadas en su destino, mientras que es realmente flexible en la forma en que lo adapta a su aplicación y entorno. Las fuentes están en GitHub: https://github.com/rauc/rauc

En general, una buena visión general y comparación de soluciones de actualización actuales que puede encontrar en la página Wiki del Proyecto Yocto sobre actualizaciones del sistema:

Https://wiki.yoctoproject.org/wiki/System_Update

 2
Author: ejoerns,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-27 15:04:29

La atomicidad es crítica para los dispositivos embebidos, una de las razones resaltadas es la pérdida de energía; pero podría haber otras como problemas de hardware/red.

La atomicidad es quizás un poco malinterpretada; esta es una definición que uso en el contexto de los actualizadores:

  • Una actualización siempre se completa completamente, o no se completa en absoluto
  • Ningún componente de software además del actualizador ve una actualización a la mitad instalada

La actualización completa de la imagen con un diseño de partición dual A/B es la la manera más simple y más probada de lograr esto.

Para Linux Embebido hay varios componentes de software que puede que desee actualizar y diferentes diseños para elegir; hay un artículo más reciente sobre esto disponible aquí: https://mender.io/resources/Software%20Updates.pdf

Archivo movido a: https://mender.io/resources/guides-and-whitepapers/_resources/Software%2520Updates.pdf

Si estás trabajando con el Proyecto Yocto te puede interesar Mender.io - el proyecto de código abierto en el que estoy trabajando. Consiste en un cliente y un 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 o gastar tiempo en codificación personalizada/de cosecha propia. También le permitirá administrar las actualizaciones de forma centralizada con el servidor.

 2
Author: rduio,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-04-05 10:22:07

Puede registrar una actualización y dividir su flash de actualización en dos ranuras. La falla de energía siempre te devuelve 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 ladrillo. Incluso si falla en el momento de escribir las banderas del diario. No existe tal cosa como una actualización atómica. Nunca. Nunca lo había visto en mi vida. Iphone, adroid, mi conmutador de red none ninguno de ellos es atómico. Si no tienes suficiente espacio para hacer ese tipo de diseño, luego arregla el diseño.

 0
Author: MaxDeusPhallus,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-14 18:02:49