Skip to main content

Warum A/B-Partitionierung?

In eingebetteten Systemen können fehlgeschlagene Updates die Geräte lahmlegen. Ein A/B-Layout löst dieses Problem, indem es zwei Root-Dateisysteme unterhält:

  • Slot A - aktives Rootfs
  • Slot B - Standby-Rootfs für die nächste Aktualisierung

Wenn eine Aktualisierung erfolgreich ist, wechselt der Bootloader zum neuen Slot. Wenn der Bootvorgang fehlschlägt, wird auf die letzte bekannte gute Version zurückgesetzt.

Dieser Ansatz setzt voraus, dass Slot A und Slot B die gleiche Größe der Partition haben, was in eingebetteten Systemen, in denen die Ressourcen begrenzt sind, manchmal schwierig sein kann.

swupdate mit Rettungssystem

Ein anderer Ansatz ist, Partitionen für ein kleines Rettungssystem und eine größere Partition für das normal laufende System zu erstellen.

Beispiel Partitionslayout

Ein typisches Raspberry Pi Compute Module 5 (CM5)-Layout könnte wie folgt aussehen:
PartitionTypZweck
p1FAT32/boot_A (Kernel, cmdline, Bootloader)
p2ext4rootfs A
p3FAT32/boot_B (Kernel, cmdline, Bootloader für Rettungssystem)
p4ext4rootfs_B
p5ext4Daten / Konfiguration
Der Bootloader kann ein Flag verwenden (z.B. GPIO17=1 im rpi-eeprom), um zu bestimmen, ob von der Rettungspartition gebootet werden soll.

Praktisches Beispiel

Dieses Setup wird in zwei Beispielprojekten demonstriert rpi-image-genBeispielprojekten demonstriert:

Die erste erstellt das Rettungssystem und die zweite kombiniert das Rettungssystem mit einem anderen laufenden System, wobei die Partitionsbezeichnungen in cmdline.txt und fstab.

Update verwalten

Sie können die inaktive Systempartition manuell mounten, um Konfigurationen, Anwendungen oder Systemkomponenten zu aktualisieren.
Bei Produktionssystemen werden die Aktualisierungen normalerweise über SWUpdateverwaltet, wodurch dieser Prozess sicher automatisiert wird.

Integration mit SWUpdate

SWUpdate unterstützt von Haus aus Dual-Rootfs (A/B) Aktualisierungsstrategien.
Partitionen und Aktualisierungslogik werden direkt in der sw-description Datei definiert.

Dieser Ansatz gewährleistet atomare Systemaktualisierungen mit eingebauter Rollback-Sicherheit - eine wichtige Funktion für Headless- oder Remote-Geräte, bei denen eine manuelle Wiederherstellung nicht möglich ist.