Transactional (atomare) Updates in openSUSE Leap 15

Datum

Ein besonderes Feature von openSUSE Leap 15 sind die atomaren Updates.
Transaktions-Updates (atomare Updates) berühren nie direkt das laufende System. Anstatt das aktuelle System zu patchen, erstellt das Transaktions-Update-Tool einen neuen Snapshot. Alle für das Update erforderlichen Operationen werden vorerst nur in diesem Snapshot ausgeführt. Am Ende des Updates wird bei erfolgreicher Aktualisierung ein abgeschlossener Snapshot als neuer Standard markiert. Diese Updates werden dann beim Neustart des Systems wirksam. Wenn die Aktualisierung nicht erfolgreich war, wird der Snapshot verworfen und keine Änderung am System vorgenommen.

Installation

Sofern openSUSE Leap 15 neu installiert wird ist es möglich, dass direkt bei der Installation angegeben werden kann das Transaktions-Updates eingerichtet werden sollen.

Wenn diese Option bei der Installation nicht ausgewählt wurde, lässt sich dieser Service nachinstallieren:
zypper install transactional-update

Bei diesem Vorgehen kommt es allerdings zu einem Konflikt mit dem snapper-zypp-plugin, wo man sich entscheiden muss ob man dieses Plugin deinstalliert oder das Paket transactional-update halt nicht installiert.

System aktualisieren

Um das System zu aktualisieren verwendet man den Befehl transactional-update dup

$ transactional-update dup                                                                                                                                                                                                 [0/0]
Checking for newer version.
transactional-update 2.3 started
Options: dup
Separate /var detected.
Creating read-only snapshot of current system state (#4)
Copying /etc state into backup snapshot
Copying /etc state into snapshot
Calling zypper dup --no-allow-vendor-change
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.                               
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 11 NEW packages are going to be installed:
  kernel-default-base libestr0 libfastjson4 liblogging0 liblognorm5 openSUSE-release-ftp rsyslog syslog-service terminfo terminfo-iterm terminfo-screen          

Neben der Option dup gibt es auch die Option up zum aktualisieren. Der Unterschied ist hierbei, dass bei dup der Befehl zypper dup --no-allow-vendor-change ausgeführt wird. Dieser verhindert, dass Drittanbieter-Repos beliebige Pakete auf dem System ändern dürfen.

Wie bereits in der Einleitung beschrieben, hat eine Aktualisierung keine Auswirkungen auf das laufende System. Es wird ein Snapshot erstellt und dieser wird dann aktualisiert. Wenn alles erfolgreich durchlief wird in diesen aktualisierten Snapshot nach dem nächsten Neustart gebootet.

Die vor der Aktualisierung gemachten Snapshots lassen sich wie gewohnt bei snapper einsehen:

$ snapper list
Type   | # | Pre # | Date                     | User | Cleanup | Description             | Userdata     
-------+---+-------+--------------------------+------+---------+-------------------------+--------------
single | 0 |       |                          | root |         | current                 |              
single | 1 |       | Tue Jul 10 17:24:43 2018 | root |         | Erstes Root-Dateisystem |              
single | 2 |       | Tue Jul 10 17:31:02 2018 | root | number  | nach der Installation   | important=yes
pre    | 3 |       | Tue Jul 10 17:53:24 2018 | root | number  | RO-Clone of #1          | important=yes
post   | 4 | 3     | Tue Jul 10 17:53:24 2018 | root |         | Snapshot Update         |      
pre    | 5 |       | Tue Jul 10 17:55:58 2018 | root | number  | RO-Clone of #4          | important=yes
post   | 6 | 5     | Tue Jul 10 17:55:59 2018 | root |         | Snapshot Update         |         

Welcher Snapshot aktuell verwendet wird sieht man folgendermaßen:

$ btrfs sub get-default /
ID 275 gen 116 top level 267 path @/.snapshots/6/snapshot

Pakete installieren

Möchte man neue Pakete installieren, ist dies nun per zypper install <Paketname> nicht mehr möglich…

$ zypper install lynx
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 2 NEW packages are going to be installed:
  lynx xli

2 new packages to install.
Overall download size: 1.7 MiB. Already cached: 0 B. After the operation, additional 7.7 MiB will be used.
Continue? [y/n/...? shows all options] (y): 
Retrieving package xli-1.17+git20170726.0bb4fb4-lp150.1.9.x86_64                                                                                                                                        (1/2), 141.9 KiB (320.3 KiB unpacked)
...
(1/2) Installing: xli-1.17+git20170726.0bb4fb4-lp150.1.9.x86_64 ......................................................................................................................................................................[error]
Installation of xli-1.17+git20170726.0bb4fb4-lp150.1.9.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Read-only file system)                                                                                                         

Abort, retry, ignore? [a/r/i] (a):

Wie die Fehlermeldung besagt befindet sich das laufenden System im Nur-lesbar Modus (Read-only file system).

Ein Blick in mount bestätigt dies:

/dev/sda2 on / type btrfs (ro,relatime,space_cache,subvolid=275,subvol=/@/.snapshots/6/snapshot)

Um nun neue Pakete zu installieren, entfernen oder zu aktualisieren verwendet man die entsprechenden transactional-update Befehle:

transactional-update pkg install <Paketname> oder transactional-update pkg in <Paketname> installiert das entsprechende Paket
transactional-update pkg remove <Paketname> oder transactional-update pkg rm <Paketname> entfernt das entsprechende Paket

Um nun z.B. lynx zu installieren verwendet man den Befehl transactional-update pkg install lynx:

$ transactional-update pkg install lynx
Checking for newer version.
transactional-update 2.3 started
Options: pkg install lynx
Separate /var detected.
Creating read-only snapshot of current system state (#6)
Copying /etc state into backup snapshot
Copying /etc state into snapshot
Calling zypper install
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 2 NEW packages are going to be installed:
  lynx xli

2 new packages to install.
Overall download size: 0 B. Already cached: 1.7 MiB. After the operation, additional 7.7 MiB will be used.
Continue? [y/n/...? shows all options] (y): 
Checking for file conflicts: ..........................................................................................................................................................................................................[done]
In cache xli-1.17+git20170726.0bb4fb4-lp150.1.9.x86_64.rpm                                                                                                                                              (1/2), 141.9 KiB (320.3 KiB unpacked)
(1/2) Installing: xli-1.17+git20170726.0bb4fb4-lp150.1.9.x86_64 .......................................................................................................................................................................[done]
In cache lynx-2.8.9~dev.16-lp150.1.9.x86_64.rpm                                                                                                                                                         (2/2),   1.6 MiB (  7.4 MiB unpacked)
(2/2) Installing: lynx-2.8.9~dev.16-lp150.1.9.x86_64 ..................................................................................................................................................................................[done]
Trying to rebuild kdump initrd
Please reboot your machine to activate the changes and avoid data loss.
transactional-update finished

Allerdings ist das Paket nicht sofort nach der Installation einsetzbar. Da auch hier vorher ein Snapshot erstellt wird, in welchem das Paket hinzugefügt wird, ist erst ein Neustart notwendig.
Nach jeder Veränderung am System (installieren, entfernen und aktualisieren von Paketen) ist ein Neustart des Systems notwendig.

Rollback

Wenn man den Befehl transactional-update rollback nach einer Änderung am System, aber noch vor dem nächsten Neustart, ausführt werden die letzten Änderungen wieder rückgängig gemacht und der entsprechende Snapshot wird entfernt.
Sollte nach einer Änderung am System der Neustart nicht mehr funktionieren, springt man per Grub in den letzten funktionierenden Snapshot und führt dann ein transactional-update rollback aus.

Automatische Updates

Wenn man Transactional (atomare) Updates verwendet sind die Systemd-Dienste transactional-update.timer und rebootmgr.service standardmäßig aktiviert.

$ systemctl status transactional-update.timer
● transactional-update.timer - Daily update of the system
   Loaded: loaded (/usr/lib/systemd/system/transactional-update.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2018-07-10 19:10:18 CEST; 4min 44s ago
  Trigger: Wed 2018-07-11 00:20:33 CEST; 5h 5min left
     Docs: man:transactional-update(8)

Jul 10 19:10:18 linux-f33n systemd[1]: Started Daily update of the system.

$ systemctl status rebootmgr.service 
● rebootmgr.service - Reboot Manager
   Loaded: loaded (/usr/lib/systemd/system/rebootmgr.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-07-10 19:10:18 CEST; 6min ago
     Docs: man:rebootmgrd(8)
           man:rebootmgrctl(1)
 Main PID: 1500 (rebootmgrd)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/rebootmgr.service
           └─1500 /usr/sbin/rebootmgrd

Jul 10 19:10:18 linux-f33n systemd[1]: Starting Reboot Manager...
Jul 10 19:10:18 linux-f33n systemd[1]: Started Reboot Manager.

Diese beiden sorgen dafür, dass täglich zwischen 03.30 Uhr und 05 Uhr automatisch neue Aktualisierungen eingespielt werden und im Anschluss daran ein Neustart durchgeführt wird.
Möchte man die Zeitpunkt ändern, so kann man dies in der /etc/rebootmgr.conf tun.
Sofern man dies möchte kann man die beiden Systemd-Dienste natürlich auch deaktivieren.

Arbeiten in der Shell

Wenn man nun trotz des nur-Lesbaren Snapshots, in dem sich das laufende System befindet, mit Befehlen arbeiten will welche Schreibzugriffe benötigen (z.B. btrfs scrub), so verwendet man den shell Parameter:

$ transactional-update shell
Checking for newer version.
transactional-update 2.3 started
Options: shell
Separate /var detected.
Creating read-only snapshot of current system state (#42)
Copying /etc state into backup snapshot
Copying /etc state into snapshot
Opening chroot in snapshot 44, continue with 'exit'
transactional update #

Hierbei wird auch wieder ein neuer Snapshot erstellt. Bevor dieser allerdings unmounted und auf read-only umgestellt wird, wird eine Shell im neuen Snapshot gestartet (chroot Umgebung zum testen und debuggen)

$ transactional update # btrfs scrub start /
scrub started on /, fsid 876298b6-2cbb-4281-a2e1-937ee7f7bc79 (pid=3387)
$ transactional update # btrfs scrub status /
scrub status for 876298b6-2cbb-4281-a2e1-937ee7f7bc79
        scrub started at Thu Jul 12 16:22:43 2018 and finished after 00:00:18
        total bytes scrubbed: 2.76GiB with 0 errors
$ transactional update # exit
Please reboot your machine to activate the changes and avoid data loss.
transactional-update finished

Auch hier sollte im Anschluß an die Arbeiten ein Neustart des Systems erfolgen, damit in den neuen Snapshot gebootet werden kann.

Autor
Kategorien OpenSUSE, Linux

PRTG Map