Transaktionale Updates auf SUSE Linux Micro, openSUSE MicroOS und Leap Micro: schreibgeschütztes Root-Dateisystem und Aktivierung per Neustart

Ziel

Eine Systemänderung auf SUSE Linux Micro, openSUSE MicroOS oder Leap Micro (sowie auf einem SLES-15-SP6-Host, der bewusst auf ein schreibgeschütztes Root-Dateisystem umgestellt wurde) anwenden, aktivieren und bei Bedarf zurückrollen, wenn / nicht direkt beschreibbar ist.

Voraussetzungen

Ein laufendes System mit schreibgeschütztem Root-Dateisystem (bei den Images von SUSE Linux Micro, MicroOS und Leap Micro der Standard); Root-Zugriff; das Bewusstsein, dass das laufende System nie direkt verändert wird.

Schritte

1. Zuerst das Modell verstehen: Der Befehl transactional-update "enables you to modify a read-only file system", so die SUSE-Linux-Micro-Dokumentation von SUSE. Jeder Aufruf erstellt aus dem aktuellen Root-Dateisystem einen neuen Btrfs-Snapshot, wendet die gewünschte Änderung (Paketinstallation, Patch oder ein beliebiger Shell-Befehl) innerhalb dieses Snapshots an und lässt das laufende System unberührt. Laut SLES 15 SP6 Administration Guide gilt: "no changes are activated until after the system is rebooted". Dieses Handbuch dokumentiert den Mechanismus auch für SLES selbst, dort jedoch als Technology Preview bei schreibgeschütztem Root-Dateisystem.
2. Pakete installieren oder aktualisieren: sudo transactional-update pkg install <package>, sudo transactional-update patch (SUSE Linux Micro, Leap Micro) oder sudo transactional-update dup (der Update-Weg beim Rolling Release openSUSE MicroOS). Ohne Unterbefehl aufgerufen, aktualisiert der Befehl das System. Jeder dieser Aufrufe erstellt einen neuen Snapshot und endet, ohne das gebootete System anzutasten.
3. Um mehrere Änderungen aufeinander aufzubauen, statt dass jeder Befehl wieder vom gebooteten System ausgeht, --continue ergänzen: Die Option "is for making multiple changes to the root file system without rebooting"; jeder Lauf baut auf dem vorherigen Snapshot auf, und mit --continue <number> lässt sich ein bestimmter Basis-Snapshot wählen.
4. Zum Aktivieren des neuen Snapshots neu starten: sudo reboot (oder den Neustart dem Reboot-Manager der Plattform, rebootmgrd, überlassen – SUSE Linux Micro führt täglich einen systemd.timer aus, der Updates anwendet und anschliessend rebootmgrd mitteilt, dass ein Neustart ansteht).
5. Ist der neu aktivierte Snapshot defekt, den vorherigen wieder als Standard setzen: sudo transactional-update rollback last, danach neu starten. Lässt sich das System gar nicht mehr booten, stattdessen im Bootloader-Menü den vorherigen Snapshot auswählen – analog zu einer Btrfs-/snapper-Wiederherstellung auf einer regulären Installation.

Erwartetes Ergebnis

transactional-update kehrt zur Eingabeaufforderung zurück, nachdem es einen neuen Snapshot angelegt hat (die Nummer erscheint in der Ausgabe). Nach dem Neustart zeigt snapper list diesen Snapshot als aktives Root-Dateisystem, und die Änderung (Paket, Patch oder Befehl) ist vorhanden.

Grenzen und Prüfbasis

Wird transactional-update zweimal ohne zwischenzeitlichen Neustart und ohne --continue ausgeführt, entstehen zwei voneinander unabhängige Snapshots statt einer zusammengeführten Änderung; für den nächsten Start zählt nur der zuletzt erstellte. /var gehört nicht zum Snapshot und ist aus ihm heraus nicht erreichbar. Eine Transaktion kann dort also keine Daten ändern, und ein Rollback stellt sie nicht wieder her. Ohne Neustart ist keine Wirkung sichtbar, und SUSE bezeichnet in der Dokumentation Neustarts als störend; ihn daher einplanen, statt anzunehmen, eine Änderung sei sofort aktiv.