Perché il partizionamento A/B?
Nei sistemi embedded, gli aggiornamenti non riusciti possono mandare in tilt i dispositivi. Un layout A/B risolve questo problema mantenendo due filesystem root:
- Slot A - rootfs attivo
- Slot B - rootfs di riserva per il prossimo aggiornamento
Quando un aggiornamento ha successo, il bootloader passa al nuovo slot. Se l'avvio fallisce, si torna all'ultima versione buona conosciuta.
Questo approccio presuppone che lo slot A e lo slot B abbiano la stessa dimensione della partizione, il che può essere talvolta complicato nei sistemi embedded, quando le risorse sono limitate.
Un altro approccio consiste nel creare partizioni per un piccolo sistema di salvataggio e una partizione più grande per il sistema in esecuzione normale.
Esempio di layout di partizione
| Partizione | Tipo | Scopo |
|---|---|---|
| p1 | FAT32 | /boot_A (kernel, cmdline, bootloader) |
| p2 | ext4 | rootfs A |
| p3 | FAT32 | /boot_B (kernel, cmdline, bootloader per il sistema di salvataggio) |
| p4 | ext4 | rootfs_B |
| p5 | ext4 | dati / configurazione |
Esempio pratico
Questa configurazione è dimostrata in due rpi-image-genprogetti di esempio:
- https://github.com/interelectronix/rpi-image-gen-projects/blob/main/deb12-cm5-rescue/README.md
- https://github.com/interelectronix/rpi-image-gen-projects/blob/main/deb12-cm5-ix-base/README.md
Il primo crea il sistema di salvataggio e il secondo combina il sistema di salvataggio con un altro sistema in esecuzione, regolando le etichette delle partizioni in cmdline.txt e fstab.
Gestione dell'aggiornamento
Può montare manualmente la partizione di sistema inattiva per aggiornare le configurazioni, le applicazioni o i componenti del sistema.
Per i sistemi di produzione, gli aggiornamenti sono in genere gestiti tramite SWUpdateche automatizza questo processo in modo sicuro.
Integrazione con SWUpdate
SWUpdate supporta in modo nativo le strategie di aggiornamento dual-rootfs (A/B).
Le partizioni e la logica di aggiornamento sono definite direttamente nel file sw-description file.
Questo approccio garantisce aggiornamenti atomici del sistema con sicurezza di rollback incorporata - una caratteristica essenziale per i dispositivi headless o remoti, dove il ripristino manuale non è fattibile.
Articoli in questa serie
- Building a Production-Ready Linux for Raspberry Pi Compute Module 5
- Dal sistema operativo stock alla piattaforma di produzione
- Customizing Raspberry Pi OS with rpi-image-gen
- Robustezza del sistema - Progettazione di un layout di file system radice A/B
- Provisioning — Automating First Boot with rpi-sb-provisioner
- OTA and Lifecycle — Software Updates with SWUpdate
Fonti
- rpi-image-gen: https://github.com/raspberrypi/rpi-image-gen
- rpi-sb-provisioner: https://github.com/raspberrypi/rpi-sb-provisioner
- SWUpdate: https://github.com/sbabic/swupdate
- swugenerator: https://github.com/sbabic/swugenerator