Startseite > Embedded > Software > Updateszenarien für und mit Linux

Systemdesign / Safety&Security

Updateszenarien für und mit Linux

13. August 2018, 15:42 Uhr | Jan Altenberg, Leiter des technischen Vertriebs bei Linutronix

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Paradigmenwechsel bei Updatekonzepten

Eine wesentliche Anforderung an ein Updatekonzept ist die Robustheit. Im Fehlerfall muss mindestens die Möglichkeit bestehen, ein Update zu wiederholen. Auf gar keinen Fall darf ein fehlgeschlagenes Update zum Ausfall eines Gerätes führen.

Traditionell wurden Updates daher über den Bootloader eingespielt. Dieser wurde als elementare und nicht austauschbare Komponente betrachtet und bildete damit den Fallback bei einem fehlgeschlagenen Update. Der Bootloader war immer vorhanden und somit bestand permanent die Möglichkeit ein Update einzuspielen.
Technisch ist dies durchaus eine valide Lösung, bringt aber einige Nachteile mit sich: die Umsetzung ist in der Regel sehr gerätespezifisch und für neue Gerätegenerationen entsteht ein hoher Portierungsaufwand. Weiterhin müssen viele Treiber mehrfach implementiert werden, einmal im Betriebssystem und einmal im Bootloader; zumindest für jegliche Peripherie, die am Einspielen neuer Software beteiligt ist.

Obwohl die Umsetzung eines Updatekonzeptes aus dem Bootloader zwar eine technisch akzeptable Lösung ist, besteht dazu aber keine Notwendigkeit. Dieses Vorgehen hat sich historisch so entwickelt, da Speicher oft limitiert und sehr teuer war. In Anbetracht der Tatsache, dass moderne Systeme mit deutlich mehr Speicher ausgestattet sind, bestehen ganz neue Möglichkeiten.

Grundsätzlich geht man auf Linux-basierten Systemen daher dazu über, ein Update nicht mehr aus dem Bootloader, sondern aus einem redundanten Linuxsystem einzuspielen; dieses kann durchaus sehr minimalistisch gestaltet sein. Damit können alle Treiber wiederverwendet werden und es stehen für die Umsetzung alle Linuxmöglichkeiten zur Verfügung. Die stabilen Schnittstellen zur Applikation sorgen dafür, dass ein solches Konzept auch für neue Gerätegenerationen wiederverwendet werden kann, da die Implementierung weitestgehend generisch erfolgt.
Konzeptionell lassen sich daraus zwei Lösungswege ableiten: Implementierung eines Rescue-Systems, Implementierung eines redundanten Systems.

Rescue-System

Bei einem Rescue-System wird parallel zum Produktivsystem ein redundantes Linux abgelegt. Dies besteht üblicherweise aus einem einfach konfigurierten Linuxkern und einem RAM-File-System mit allen notwendigen Werkzeugen zur Updatedurchführung. Das Einspielen von neuer Software erfolgt grundsätzlich aus dem Rescue-System.

Dieser Weg erfüllt die Minimalanforderung an ein Updatekonzept: das Gerät bleibt über das Rescue-System immer updatefähig. Bei einem fehlgeschlagenen Update kann dieses wiederholt werden.

Bild 1 veranschaulicht den grundsätzlichen Aufbau eines solchen Systems. Die Aktualisierung der Software in System A würde wie folgt ablaufen: System A lädt die Softwareaktualisierung von einem definierten Ort und legt über ein Setting im Boot-Environment fest, dass beim nächsten Reboot das Rescue-System gebootet werden soll. Anschließend wird (ebenfalls im Bootloader-Environment) System A als ungültig markiert und ein Reboot angestoßen. Das Rescue System spielt das Update ein und überschreibt damit die Daten von System A. Die „Bootweiche“ wird auf System A zurückgesetzt und ein Reboot wird angestoßen. Dieser Reboot wird über einen Watchdog abgesichert. Im „Gutfall“ wird System A am Ende des Bootprozesses sich selbst als gültig markieren. Im Fehlerfall (es wurde beispielsweise eine fehlerhafte Software eingespielt) wird der Watchdog das System zurücksetzen. Stellt der Bootloader als Resetgrund einen Watchdogreset fest und ist System A noch nicht als gültig markiert, so wird von einem fehlerhaften Update ausgegangen und das Rescue-System gebootet. Dieses kann dann dazu genutzt werden, wieder eine korrekte Software einzuspielen.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Die Vorteile einer solchen Umsetzung sind der geringe Speicherbedarf und die Möglichkeit, Produktivsystem und Rescue-System unterschiedlich zu konfigurieren und mit unterschiedlichen Zugriffsrechten zu versehen. Der Nachteil: Das Produktivsystem ist während des Updates und im Fehlerfall nicht nutzbar und für jedes Update sind mindestens zwei Reboots erforderlich.

Redundantes System (A-B-Update)

Bei einem redundanten System (häufig auch als A-B Update bezeichnet) werden zwei voll funktionale Softwarestände parallel gehalten. Der aktive Softwarestand aktualisiert den jeweils redundanten Pfad.

Bild 2 zeigt den Aufbau eines A-B Updates. Das Einspielen der Software passiert analog zum Rescue-System: System A kann die Software von einem definierten Ort laden. System B wird dann mit den neuen Daten überschrieben und zeitgleich als ungültig markiert. Anschließend wird im Boot-Environment festgelegt, dass System B gebootet werden soll. Der folgende Reboot wird wiederum per Watchdog abgesichert.
Im Gutfall markiert sich System B als gültig. Im Fehlerfall erkennt der Bootloader den Watchdogreset und kann wegen dem ungültigen System B wieder System A booten. Nachteilig ist bei dieser Methode nur der erhöhte Speicherbedarf (die Software muss immer doppelt vorgehalten werden). Im Gegensatz zum Rescue-System wird pro Update allerdings nur ein Reboot benötigt und das System ist auch im Fehlerfall immer voll funktional!