Embedded Linux-basierte Geräte benötigen oft einen Mechanismus zum Aktualisieren von Anwendungen und Systemdateien. Zum Beispiel kann ein (nicht vernetztes) Laborgerät mit einem USB-Anschluss Softwareupdates von einem USB-Stick erhalten.
Es wäre sehr einfach, ein Skript auszuführen, um Dateien in den internen Flash-Speicher des Geräts zu kopieren. Es besteht jedoch die Gefahr, dass das Gerät mitten in der Aktualisierung ausfällt und am Ende ein Baustein wird.
Die Situation für Anwendungsdateien ist ein wenig einfacher, da es Platz gibt, das Anwendungsverzeichnis zu duplizieren, eine Kopie zu aktualisieren und schnell alte und neue Verzeichnisse auszutauschen, wodurch das Fehlerfenster minimiert wird.
Die Dinge sind für Kernel und Systemdateien entscheidend, da sie im gesamten Dateisystem verteilt sind.
Wir haben harte und weiche Links im Dateisystem verwendet, um kritische Dateien zu identifizieren. Wir verwenden Hashes für Dateien und Archive, um die Dateiintegrität zu überprüfen. Wir haben überlegt, einen Notfall-Ramf im Kernel zu verwenden, um ein Fallback bereitzustellen, wenn das Starten des aktualisierten Dateisystems fehlschlägt.
Was sind Ihre Ansätze für diese Anforderung?
Ich würde mit dem gleichen Ansatz wie bei den Anwendungsdateien gehen: Erstellen Sie die kritischen Dateien und schließen Sie die eigene Partition ab, verlinken Sie sie und duplizieren Sie die Partition. In allen Ihrer Init sollten Sie zuerst prüfen, ob die Links alle auf die gleiche Partition zeigen, wenn nicht, setzen Sie sie zurück (auf die Partition mit den Dateien mit dem neuesten Datum einer bestimmten Datei). Wenn Sie aktualisieren möchten, kopieren Sie einfach alles auf die neue Partition, und wenn alles in Ordnung ist (crcs ok), führen Sie eine Schleife über die Dateien aus und stellen Sie für jede die Verbindung von einem Dateisystem zum anderen ein.
Auf diese Weise sollten Ihre kritischen Dateien immer in einem vernünftigen Zustand sein.
Szenarien:
Aktualisierung schlägt beim Kopieren von Dateien auf neue Partition fehl
Kein Problem, da die Links immer noch zu den alten funktionieren.
Aktualisierung schlägt beim Verknüpfen fehl
Kein Problem, da alle neuen Dateien gültig sind und bereits kopiert wurden (sonst hätte der Relink-Schritt keinen Start), Setup-Check korrigiert dies
Wenn Sie die Zuverlässigkeit sicherstellen müssen, können Sie zwei Flash-Partitionen (oder sogar Chips), eine mit der aktuellen Arbeits Konfiguration und einer mit der neuen Konfiguration. Dann einen Hardware-Watchdog verwendet werden, die das Gerät zurückgesetzt wird und schaltet die aktive Boot-Flash-Partition auf den „letzten bekannten guten“ -Konfiguration.
Haben Sie mindestens zwei Partitionen. Ich würde vorschlagen, 4
booten
alternativer Start
Programmdatensicherung
Programm volatile Daten
Verwenden Sie grub fallback booten, um alternativ zu booten, wenn das Booten fehlschlägt.
Wenn die Aktualisierung fehlschlägt, funktioniert die Alternative.
Aktualisieren Sie den Bootloader NIEMALS.
Wenn die Datenpartition getoastet wird, formatieren Sie sie neu und kopieren Sie sie über die Backup-Datenpartition.
Jetzt können Sie nicht fehlschlagen, es sei denn, die Flash-Disk stirbt ab. Wenn Sie COTS-Hardware verwenden und Hauptfestplatte war, Compact Flash, könnten Sie eine physisch isolierte Sicherung auf sagen, ein wenig USB-Schlüssel.
IMHO jede Aktualisierung, die nicht atomar ist, kann das System brechen oder die Überprüfung auf Konsistenz ziemlich schwierig machen. Ich stimme zu, dass das Aktualisieren des Bootloaders vermieden werden muss, da er nicht sicher ist. Im Allgemeinen möchte ein Hersteller ein Update von Firmware x.x.x auf Version y.y.y, ohne sich darum zu kümmern, ob der Kernel und / oder eine einzelne Datei aktualisiert wurde. Das Aktualisieren einzelner Dateien kann für den Dienst zu einem Albtraum werden, da es sehr schwierig ist zu verstehen, was auf der Hardware des Kunden läuft. Vielleicht mischen Sie einen Doppelkopie-Ansatz (Anwendung ist redundant) mit einem Einzelkopie-Ansatz. Ich denke, dass das nicht viel hilft, weil die Integrität des Systems durch die schwache Komponente in der Kette erfolgt. Wenn eine Aktualisierung des Root-Dateisystems fehlschlägt, ist es nicht wichtig, dass die Anwendung dupliziert wird.
Ein Dual-Copy-Ansatz kann ein Update ohne Außerbetriebnahme garantieren, wenn Sie dies benötigen. Aber es erfordert eine Menge Ressourcen, weil alle Komponenten dupliziert werden müssen. Persönlich verwende ich einen Fallback-Ansatz, bei dem ein kleines rootfs im RAM gestartet wird, wenn die Hauptanwendung fehlschlägt oder wenn die letzte Aktualisierung nicht erfolgreich war. Dieses Fallback-System, das vom Bootloader automatisch gestartet wird, wenn etwas schief geht, aktualisiert das System von einem USB-Stift (wenn ein lokales Update erforderlich ist).
Ich habe noch nie ein OSS-Projekt zu diesen Problemen gefunden und habe vor kurzem ein neues angefangen, basierend auf meinen früheren Erfahrungen. Ich habe mehrere Produkte und meine Kunden sind damit zufrieden.
Vielleicht können Sie es sich ansehen. Quellen für "swupdate" (der Name des Projekts) finden Sie unter github.com/sbabic/swupdate .
Stefano
Ich denke, was Sie hier erreichen wollen, ist die Atomizität des Update-Prozesses. Atomarität ist kritisch für eingebettete Geräte, einer der Gründe, die hervorgehoben werden, ist der Leistungsverlust; aber es könnte andere wie Hardware- / Netzwerkprobleme geben. Eine Definition, die ich für die Atomarität im Kontext von Aktualisierungen verwende, ist:
Für Embedded Linux gibt es mehrere Softwarekomponenten, die Sie aktualisieren und verschiedene Designs auswählen können; Es gibt ein Papier dazu hier: Ссылка
Tags und Links linux embedded maintenance reliability