Techniques recommandées pour la mise à jour sur site de Linux embarqué en toute sécurité

Question

Les périphériques Linux embarqués nécessitent souvent un mécanisme pour mettre à jour les applications et les fichiers système. Par exemple, un instrument de laboratoire (non connecté au réseau) avec un port USB peut obtenir des mises à jour logicielles à partir d'une clé USB.

Il serait très simple d'exécuter un script pour copier des fichiers dans la mémoire flash interne de l'appareil. Cependant, il existe un risque que l'appareil perde de sa puissance au milieu de la mise à jour et finisse par se briser. La situation des fichiers d'application est un peu plus facile car il est possible de dupliquer le répertoire de l'application, de mettre à jour une copie et d'échanger rapidement les anciens et les nouveaux répertoires en minimisant la fenêtre d'échec.

Les choses sont plus difficiles pour les fichiers du noyau et du système car ils sont dispersés dans le système de fichiers.

Nous avons utilisé des liens physiques et matériels dans le système de fichiers pour identifier les fichiers critiques. Nous utilisons des hachages sur les fichiers et les archives pour vérifier l'intégrité des fichiers. Nous avons envisagé d'utiliser un ramf d'urgence dans le noyau pour fournir une solution de repli si le démarrage du système de fichiers mis à jour échoue.

Quelle est votre approche de cette exigence?

Answer 1

Je voudrais aller avec la même approche qu'avec les fichiers d'application: Faire pour les fichiers critiques et compléter propre partition, lien vers eux, et dupliquer la partition. Dans tout votre init, vous devez d'abord vérifier si les liens montrent tous vers la même partition, sinon, les réinitialiser (sur la partition avec les fichiers avec la date la plus récente d'un certain fichier). Si vous voulez mettre à jour il suffit de copier tout sur la nouvelle partition, et si tout va bien (crcs ok) boucle sur les fichiers et définir pour chaque le lien d'un système de fichiers à l'autre. De cette façon, vos fichiers critiques doivent toujours être dans un état sain.

Scénarios:

1. mise à jour échoue lors de la copie des fichiers sur une nouvelle partition

   Pas de problème, car les liens montrent encore les anciens de travail.

2. mise à jour échoue tout en reliant

   Pas de problème, car tous les nouveaux fichiers sont valides et déjà copié (sinon l'étape de Relink wouldnt ont démarrage), vérification de la configuration correcte cette

Answer 2

Si vous devez assurer la fiabilité, vous pouvez avoir deux partitions flash (ou même des puces), une avec la configuration de travail actuelle et une avec la nouvelle configuration. Ensuite, utilisez un chien de garde matériel qui réinitialisera l'unité et basculera la partition de démarrage flash active vers la configuration du «dernier élément connu».

Answer 3

Avoir au moins deux partitions .Je suggère 4

• boot

• démarrage alternatif

• sauvegarde des données du programme

• programme des données volatiles

Utilisez le démarrage de secours sans tête pour démarrer alternative si le démarrage échoue Donc, si la mise à jour échoue, l'alternative fonctionne.

NE JAMAIS mettre à jour le chargeur de démarrage.

Si la partition de données est grillée, reformatez et copiez sur la partition de données de sauvegarde.

Maintenant vous ne pouvez pas échouer sauf si le disque flash meurt. Si vous utilisez du matériel COTS, et disons que le disque principal, Compact flash, vous pourriez avoir une sauvegarde physiquement isolée, disons, une petite clé USB.

Answer 4

IMHO toute mise à jour qui n'est pas atomique peut casser le système ou rendre la vérification de la cohérence assez difficile. Je suis d'accord que la mise à jour du chargeur de démarrage doit être évitée car elle n'est pas hors tension. Généralement, un fabricant souhaite une mise à jour de Firmware x.x.x vers la version y.y.y, sans se préoccuper de savoir si le noyau et/ou un seul fichier a été mis à jour. La mise à jour de fichiers individuels peut devenir un cauchemar pour le service, car il est très difficile de comprendre ce qui se passe sur le matériel du client. Peut-être que vous mélangez une approche double copie (l'application est redondante) avec une approche de copie unique. Je pense que cela n'aide pas beaucoup, car l'intégrité du système est assurée par la composante faible de la chaîne. Si une mise à jour du système de fichiers racine échoue, il n'est pas important que l'application soit dupliquée.

Une approche double copie peut garantir une mise à jour sans mise hors service, si vous en avez besoin. Mais cela nécessite beaucoup de ressources, car tous les composants doivent être dupliqués. Personnellement, j'utilise une approche de secours, où un petit rootfs dans la RAM est démarré si l'application principale échoue ou si la dernière mise à jour a échoué. Ce système de secours, lancé automatiquement par le bootloader en cas de problème, met à jour le système depuis un stylo USB (si une mise à jour locale est requise).

Je n'ai jamais trouvé de projet OSS sur ces problèmes et j'ai commencé récemment un nouveau, basé sur mon expérience précédente. J'ai plusieurs produits en cours d'exécution et mes clients sont satisfaits.

Peut-être pouvez-vous jeter un coup d'œil. Vous pouvez trouver des sources pour "swupdate" (le nom du projet) au github.com/sbabic/swupdate.

Stefano

Answer 5

Je pense que ce que vous essayez d'atteindre ici est atomicité du processus de mise à jour. L'atomicité est critique pour les dispositifs embarqués, l'une des raisons soulignées est la perte de puissance; mais il pourrait y avoir d'autres problèmes matériels/réseau.Une définition que j'utilise pour atomicité dans le cadre des mises à jour est:

• Une mise à jour est toujours soit terminée complètement, ou pas du tout
• Aucun composant logiciel en plus Updater voit jamais un demi-installé la mise à jour

Pour Linux embarqué, il existe plusieurs composants logiciels que vous souhaitez mettre à jour et différents modèles à choisir; il y a un papier sur ceci ici: https://mender.io/user/pages/04.resources/_white-papers/Software%20Updates.pdf