Fedora senza rollback? Una nuova soluzione porta snapshot completi

Fedora adotta Btrfs come filesystem predefinito dalla versione 33, una scelta che prometteva snapshot efficienti e gestione avanzata dei dati. A distanza di anni, tuttavia, una funzionalità chiave resta assente per chi utilizza Fedora Workstation o KDE: il rollback completo del sistema dopo aggiornamenti problematici. In un periodo in cui il ciclo di rilascio rapido (Fedora non usa comunque l’approccio rolling release) introduce modifiche frequenti a kernel, librerie e stack grafico, la mancanza di un meccanismo affidabile che consenta il ritorno a uno stato precedente espone gli utenti a interruzioni operative e complessità nella risoluzione dei problemi.

Alcune distribuzioni hanno affrontato il tema con approcci maturi. openSUSE, ad esempio, integra da tempo Snapper, uno strumento che permette di creare e gestire snapshot, ovvero copie dello stato del sistema in un determinato momento, e di effettuare rollback atomici, cioè ripristini completi e coerenti a uno stato precedente senza lasciare il sistema in una condizione intermedia inconsistente.

Fedora ha discusso soluzioni simili, come il progetto snapm, ma senza arrivare a un’implementazione concreta nel sistema principale. Allo stesso tempo, Red Hat ha realizzato versioni del sistema operativo immutabili come Silverblue e Kinoite, basate sulla tecnologia OSTree (un sistema che gestisce il sistema come una serie di snapshot versionati): permettono di tornare facilmente a uno stato precedente ma richiedono un modo di utilizzo diverso rispetto al classico desktop tradizionale.

Limiti strutturali del layout Btrfs in Fedora

La configurazione standard di Fedora con Btrfs presenta un limite evidente: gli snapshot non includono componenti critici come il contenuto di /boot, spesso formattato in ext4.

Ciò impedisce un rollback completo, perché kernel e initramfs restano fuori dall'”immagine” del sistema. Anche le voci di avvio non risultano allineate, rendendo impossibile ripristinare un ambiente funzionante con un’unica operazione.

La separazione di alcune directory, come /var, introduce ulteriori complessità. Sebbene sia utile isolare dati dinamici come database o container, un rollback che non considera correttamente tali elementi può produrre inconsistenze difficili da diagnosticare.

Una soluzione basata su snapshot coerenti e rollback atomico

Un nuovo strumento, atomic-rollback, sviluppato dalla comunità interviene direttamente su queste criticità. Il passaggio chiave riguarda la migrazione di /boot su Btrfs, eliminando la dipendenza da ext4 e consentendo l’inclusione del kernel negli snapshot.

Dopo la configurazione iniziale, un plugin per dnf crea automaticamente uno snapshot prima di ogni aggiornamento. In caso di errore, il sistema può tornare allo stato precedente con un singolo e semplice comando.

Il rollback sfrutta un’operazione a livello di kernel progettata per essere atomica: o viene completata interamente oppure non viene applicata. In questo modo si evitano condizioni intermedie, spesso causa di sistemi non avviabili.

La soluzione atomic-rollback separa esplicitamente /var in un sottovolume dedicato. Tale scelta consente di eseguire rollback del sistema senza alterare dati persistenti come database, log o ambienti containerizzati. Si tratta di un compromesso importante: garantisce stabilità applicativa evitando di perdere informazioni aggiornate, pur mantenendo la possibilità di ripristinare lo stato del sistema operativo.

Il meccanismo prevede anche specifici hook (punti di integrazione automatica) per kernel-install, il processo che gestisce l’installazione e l’aggiornamento del kernel Linux, in modo tale da garantire che ogni modifica resti in linea con l’organizzazione del file system Btrfs. In assenza di questi accorgimenti, il bootloader, cioè il componente che avvia il sistema operativo, potrebbe riferirsi a percorsi non più validi, compromettendo l’avvio corretto del sistema.

Requisiti e limitazioni operative

Uno strumento come atomic-rollback richiede Fedora 43 o versioni successive, avvio in modalità UEFI e l’uso di libdnf5-plugin-actions. Non è compatibile con Silverblue e Kinoite, che adottano già un modello immutabile con rollback integrato.

Alcune limitazioni tecniche restano presenti. Il driver Btrfs di GRUB supporta solo operazioni in lettura, quindi il menu di avvio può comparire per un tempo molto breve. Inoltre, non è supportata la cifratura LUKS per /boot, un vincolo rilevante per ambienti che richiedono elevati livelli di sicurezza.

L’introduzione di un sistema di rollback completo, seppur non ufficialmente supportato da Fedora, colma una lacuna evidente nell’esperienza desktop con l’apprezzata distribuzione Linux. Permette di affrontare aggiornamenti critici con maggiore tranquillità e riduce i tempi di recupero in caso di malfunzionamenti.

Non si tratta solo di comodità: in ambienti di sviluppo o produzione, la capacità di tornare rapidamente a uno stato funzionante può fare la differenza tra continuità operativa e interruzione del servizio.