Unveränderliche Linux-Distributionen auf Servern

Was eine unveränderliche Linux-Distribution ist

Eine unveränderliche Linux-Distribution stellt das Betriebssystem als ein Image bereit. Sie ersetzen daher das System, anstatt es direkt zu aktualisieren. Es gibt kein apt upgrade-Umschreiben von Dateien unter /usr auf einem laufenden System. Sie erstellen ein neues Image oder laden eines herunter. Der Rechner stellt es neben dem aktuell ausgeführten Image bereit. Beim nächsten Reboot wird festgelegt, welches Image aktiv ist. Das vorherige Image bleibt auf der Festplatte. Ein fehlerhaftes Update machen Sie daher durch einen Reboot rückgängig.

Der Begriff „unveränderlich“ ist übertrieben. root wird dadurch nicht physisch daran gehindert, auf die Festplatte zu schreiben. Diese Systeme mounten die Systemverzeichnisse jedoch read only und ordnen sie dem Image zu. Persistente Daten liegen in /var. Maschinenspezifische Konfigurationen liegen in /etc. Alles unter /usr gehört zum Image. Deshalb enthalten zwei Server mit demselben Image-Tag identische Systemdateien.

Die Bezeichnungen von Red Hat für die beiden Modelle sind am eindeutigsten: Paketmodus und Imagemodus. Der Paketmodus ist ein laufendes System mit einem Paketmanager, der es bearbeitet. Der Imagemodus besteht aus einem Build-Schritt an einer anderen Stelle, der ein Artefakt erzeugt, und einem Server, dessen einzige Aufgabe darin besteht, das von Ihnen angegebene Artefakt zu booten. Alles Folgende ergibt sich aus diesem einen Unterschied.

Warum ein schreibgeschütztes System auf einem Server wichtiger ist

Ein Server, der zwei Jahre lang betrieben wurde, hat eine nicht dokumentierte Vorgeschichte. Ein make install aus einem hektischen Abend. Ein zusätzlich eingebundenes Drittanbieter-Repository für ein einziges Paket. Eine Konfigurationsdatei, die während eines Ausfalls bearbeitet und nie wieder in das Configuration Management übernommen wurde. Das wird als Configuration Drift bezeichnet. Deshalb verhält sich ein aus Ihren Notizen neu erstellter „identischer“ Server so häufig anders. Die Notizen enthalten die Absicht. Die Festplatte enthält den tatsächlichen Zustand.

Der Image-Modus beseitigt den Ort, an dem sich Configuration Drift ansammelt. /usr ist zur Laufzeit schreibgeschützt. Eine manuell durchgeführte Installation schlägt daher entweder direkt fehl oder wird als Layer erfasst, den Sie mit einem einzigen Befehl auflisten können. Dadurch wird der Unterschied zwischen zwei Maschinen sichtbar, statt erst mühsam rekonstruiert werden zu müssen. Es handelt sich um dasselbe Problem, das eine reguläre Checkliste für die Linux-Serverwartung mit Disziplin angeht. Hier wird es stattdessen über das Dateisystem gelöst.

Rollback bedeutet einen Reboot. Mehr ist dafür nicht erforderlich.

Das Szenario, für das dieses Modell entwickelt wurde, ist bereits dokumentiert: ein VPS, der nach einem Kernel-Update nicht mehr bootet. Im Paketmodus stellen Sie das System über die Rescue-Konsole des Providers wieder her. Sie mounten das Laufwerk, führen chroot aus und entfernen ein Kernel-Paket manuell. Das funktioniert, weil der Bootloader alte Kernel beibehält. Auf diese Weise wird jedoch nur der Kernel versioniert. Das glibc-Update und die systemd-Änderungen aus derselben Transaktion sind bereits angewendet. Kein einzelner Befehl setzt sie gemeinsam zurück.

Im Imagemodus umfasst die Unit das gesamte System. Auf einem bootc-Host:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback stellt die Reihenfolge der Bootloader-Einträge auf den vorherigen Eintrag zurück. Dabei handelt es sich um das Image, mit dem Sie vor einer Stunde gearbeitet haben, einschließlich Kernel und Userspace. Es wird nichts heruntergeladen und nichts neu erstellt, weil das alte Image das Laufwerk nie verlassen hat.

Fedora CoreOS führt denselben Vorgang unter anderen Bezeichnungen aus:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Beenden Sie zuerst Zincati. Zincati ist der Agent, der einen Fedora-CoreOS-Rechner auf dem neuesten Release hält. Wenn der Agent weiterläuft, stellt er das Update bereit, das Sie gerade zurückgesetzt haben. -r führt einen Reboot aus, sobald das Rollback bereitsteht. Damit eine vertrauenswürdige Deployment-Version nicht durch die Garbage Collection entfernt wird:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status listet die Deployments in der Reihenfolge auf, in der der Bootloader sie anbietet. Die aktuell laufende Version wird mit einem Punkt markiert. Pinned: yes wird bei der Version angezeigt, die Sie festgesetzt haben.

Bei Talos genügt ein API-Aufruf von Ihrer Workstation:

talosctl rollback --nodes 10.20.30.40

Flatcar verwendet zwei /usr-Partitionen und wechselt zwischen ihnen. Jeder Slot enthält in der Partitionstabelle eine Priorität und einen Zähler für Bootversuche. Ein Slot, der nie erfolgreich bootet, verbraucht seine Versuche. Danach wählt der Bootloader den anderen Slot. Prüfen Sie, welchen Slot Sie verwenden und ob er als fehlerfrei markiert wurde:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Ein fehlerfrei laufender Slot gibt eine Zeile aus, die priority=1 tries=0 successful=1 enthält. Wenn keine passende Zeile vorhanden ist, wurde der aktuelle Slot nie bestätigt. In diesem Zustand befindet sich ein Rechner zwischen einem Update und seinem ersten erfolgreichen Boot.

Was ersetzt „ein Paket installieren“: bootc und ein Containerfile

bootc ist das Werkzeug, das dieses Muster verallgemeinert hat. Es beschreibt sich selbst als System für transaktionale Betriebssystemaktualisierungen im laufenden System mithilfe von OCI-Container-Images (Open Container Initiative) und ist ein CNCF-Sandbox-Projekt. Ihr Server wird zu einem Containerfile. Im August 2026 lautet das Fedora-Basis-Image quay.io/fedora/fedora-bootc:44 und das CentOS-Stream-Basis-Image quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

Erstellen und übertragen Sie es wie jedes andere Image:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Anschließend führen Sie auf dem Server Folgendes aus:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade fragt die Image-Quelle ab und stellt das neue Image für den nächsten Bootvorgang bereit. --check meldet, ob ein Update verfügbar ist, und nimmt keine Änderungen vor. --apply startet das System mit diesem Image neu. bootc switch registry.example.com/edge/web:next weist den Rechner auf ein anderes Image hin und bewahrt dabei /etc und /var, sodass Sie einen Server ohne Neuinstallation zwischen Image-Streams verschieben können.

Für unbeaufsichtigte Updates aktivieren Sie den vom Projekt bereitgestellten Timer:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Das ist die Image-Mode-Entsprechung zu unbeaufsichtigten Upgrades unter Ubuntu und zu dnf-automatic unter Rocky und Alma. Der Unterschied besteht darin, was installiert wird. Ein Timer im Package Mode wendet die Versionen an, die das Repository in dieser Nacht bereitstellt. Das resultierende Set unterscheidet sich daher auf jedem Rechner geringfügig. Ein Timer im Image Mode wendet ein einzelnes Artefakt an, das Sie bereits an anderer Stelle gebootet haben.

Aus diesem Containerfile ergeben sich zwei Build-Regeln. Schreibbare Daten gehören unter /var. Software, die unbedingt in ihr eigenes Installationsverzeichnis schreiben muss, benötigt daher entweder einen Symlink oder beim Build eine systemd-BindPaths=-Zeile. Außerdem wird /etc beim Update per Drei-Wege-Merge zusammengeführt. Das bedeutet: Eine Datei, die Sie nie geändert haben, erhält die neue Version aus dem Image. Eine Datei, die Sie lokal bearbeitet haben, bleibt erhalten.

Wenn Sie für eine einzelne Debugging-Sitzung ein Werkzeug auf einem laufenden System benötigen:

sudo bootc usr-overlay
sudo dnf -y install strace

Dadurch wird unter /usr ein temporäres, schreibbares Overlay hinzugefügt. Beim nächsten Reboot wird es verworfen. Es dient dazu, ein Problem zu untersuchen, nicht dazu, es zu beheben. Auf diese Weise können Sie den Kernel nicht ändern. Alles, was Sie installieren, verschwindet beim Reboot absichtlich.

Fedora CoreOS: Einmal bereitstellen, dauerhaft aktualisieren

Fedora CoreOS verfügt über kein interaktives Installationsprogramm. Sie schreiben eine Butane-YAML-Datei, wandeln sie in Ignition-JSON um und übergeben sie der Maschine beim ersten Boot:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition wird nur beim ersten Boot in der initramfs ausgeführt. Das ist der entscheidende Unterschied für Anwender, die von cloud-init kommen. Enthält die Konfiguration keinen SSH-Schlüssel, startet die Maschine ohne Zugriffsmöglichkeit. Dann müssen Sie sie erneut von Grund auf bereitstellen. Testen Sie die Konfiguration auf einer Wegwerfmaschine, bevor Sie sie auf einen wichtigen Server anwenden.

Installation auf eine Festplatte aus einer Live-Umgebung:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Updates erfolgen standardmäßig automatisch. Sie steuern den Zeitpunkt, nicht die Ausführung. Legen Sie unter /etc/zincati/config.d/55-updates-strategy.toml eine TOML-Datei ab, die die periodische Strategie festlegt:

[updates]
strategy = "periodic"

Bei dieser Strategie fügen Sie pro Array-of-Tables-Eintrag ein Wartungsfenster hinzu. Jedes Fenster beginnt mit dem Namen updates.periodic.window in doppelten eckigen Klammern als Überschrift, gefolgt von drei Schlüsseln:

• days, eine Liste von Tagesnamen, beispielsweise "Sat" und "Sun".
• start_time, der Zeitpunkt, an dem das Fenster beginnt, angegeben als "22:30".
• length_minutes, die Dauer des Fensters, beispielsweise 60.

Diese Zeitangaben sind UTC. Um Updates vollständig zu deaktivieren, führen Sie sudo systemctl disable --now zincati.service aus. Dann sind Sie selbst für den Patch-Zeitplan verantwortlich.

Das Layering von Paketen bietet eine Ausweichmöglichkeit:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Dadurch wird ein neues Deployment mit dem hinzugefügten Paket erstellt. Die Änderung wird erst nach dem Reboot wirksam. Die Folgen zeigen sich später. Ihr gelayertes Paketset wird auf jedes neue Basis-Image erneut angewendet. Ist ein Paket am Tag eines Updates nicht mehr im Repository verfügbar, schlägt das Update fehl. Die Fedora-Dokumentation empfiehlt für umfangreichere Änderungen Container und nur dann ein bootc-Image, wenn Sie das Betriebssystem tatsächlich ändern müssen.

Flatcar Container Linux: überhaupt kein Paketmanager

Flatcar ist die Weiterentwicklung von CoreOS Container Linux und die striktste der universell einsetzbaren Optionen. Es gibt keinen Paketmanager, auf den Sie zurückgreifen können. Alles, was Sie ausführen, ist ein Container. Für die Bereitstellung wird Ignition verwendet, ebenso wie bei Fedora CoreOS. Updates erfolgen über die beiden oben beschriebenen A/B-/usr-Partitionen. Gesteuert werden sie von update_engine. locksmithd legt fest, wann der Reboot erfolgt.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT bedeutet, dass der passive Slot bereits das neue Image enthält und nur noch der Reboot aussteht. Die Standardstrategie für den Reboot ist reboot mit einer Verzögerung von fünf Minuten. Ein einzelner Produktions-VPS startet daher nach diesem Zeitplan automatisch neu, sofern Sie nichts anderes festlegen. Setzen Sie ein Zeitfenster in /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off überlässt den Reboot Ihnen. SERVER=disabled in derselben Datei deaktiviert die Update-Prüfung vollständig. In einem Cluster begrenzt REBOOT_STRATEGY=etcd-lock in Verbindung mit locksmithctl set-max 4, wie viele Knoten gleichzeitig neu starten dürfen. Dadurch legt ein Update niemals die gesamte Flotte gleichzeitig lahm.

Talos Linux: keine Shell, kein SSH, keine Konsole

Talos ist das spezialisierteste der vier Systeme und beschreibt seinen Zweck am eindeutigsten. Es führt Kubernetes-Nodes aus. Es gibt keinen SSH-Daemon, keine Shell und keine Konsolenanmeldung. Jeder Vorgang ist ein gRPC-API-Aufruf, den Sie mit talosctl von Ihrer Workstation aus gegen eine Maschinenkonfiguration ausführen, die Sie in git verwalten.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

Ersetzen Sie das Tag durch das Release, auf das Sie aktualisieren. Das Upgrade verwendet ein A-B-Schema und behält den vorherigen Kernel sowie das vorherige OS-Image bei. Wenn das neue Image nicht startet, führt Talos ohne Eingriff automatisch ein Rollback durch. Das Debugging läuft anders ab, weil es keine Shell gibt: Sie verwenden talosctl logs und talosctl dmesg statt journalctl auf dem System selbst.

Wenn Ihre Workloads nicht unter Kubernetes laufen, ist Talos die falsche Wahl. Wenn dies der Fall ist, beseitigt Talos eine gesamte Kategorie von Incidents, weil es keine Möglichkeit gibt, dass sich jemand an einem Node anmeldet und dort etwas ändert.

Was ein VPS-Mieter tatsächlich aufgibt

Ad-hoc-Installationen auf einem laufenden System. Das ist der wichtigste Punkt. sudo apt install htop um 2 Uhr während eines Vorfalls ist nicht verfügbar. Bei bootc erhalten Sie ein transientes Overlay, das beim Neustart verschwindet. Bei Fedora CoreOS erhalten Sie ein geschichtetes Deployment, das einen Neustart erfordert. Bei Flatcar und Talos erhalten Sie nichts.

Eine Build-Pipeline, die zuvor nicht vorhanden war. Das Hinzufügen eines Pakets bedeutet, ein Containerfile zu bearbeiten, das Image zu erstellen, es in eine Registry zu pushen und die Server nacheinander zu aktualisieren. Wenn die Pipeline vorhanden ist, ist das kostengünstig. Wenn sie erst eingerichtet werden muss, ist es echter Aufwand. Außerdem benötigen Sie eine Registry, die von den Servern aus erreichbar ist. Das ist ein weiterer Dienst, den Sie betreiben müssen, oder eine weitere Rechnung, die Sie bezahlen müssen.

Kernel-Module. Der Kernel stammt aus dem Image. Daher bleibt ein gegen den laufenden Kernel kompiliertes Modul beim nächsten Update nicht erhalten. Externe Module und DKMS-Pakete (dynamic kernel module support) müssen in das Image integriert und gegen den Kernel dieses Images gebaut werden. Alles, was ein Modul benötigt, das im Basis-Image nicht enthalten ist, wird zu einem Build-Problem statt zu einem Installationsproblem.

Agenten von Anbietern und Providern. Monitoring- und Backup-Agenten werden normalerweise als .deb oder .rpm mit einem Installationsskript bereitgestellt, das in /usr schreibt und eine Unit aktiviert. Auf einem schreibgeschützten System schlägt dieses Skript fehl. Einige Anbieter veröffentlichen einen Container oder dokumentieren eine Installation im Image-Modus. Viele tun das nicht. Prüfen Sie dies, bevor Sie sich festlegen. Eine Flotte, die Sie nicht überwachen können, ist schlechter als eine Flotte, deren Konfiguration abweicht.

Das Image selbst. Fast kein VPS-Control-Panel führt Fedora CoreOS, Flatcar oder Talos neben Ubuntu und Debian auf. Sie stellen den Datenträger selbst bereit. Das ist das Thema des nächsten Abschnitts.

Diese Systeme auf einen gemieteten VPS bringen

Prüfen Sie zunächst zwei Dinge bei Ihrem Anbieter: ob Sie Zugriff auf eine Out-of-Band-Konsole haben, also eine VNC- oder serielle Konsole, und ob Sie ein Rettungssystem starten können. Ohne Konsole wird ein System, das nicht zurückkommt, zu einem Support-Ticket statt zu einer Reparatur in fünf Minuten.

Wenn der Anbieter benutzerdefinierte Images akzeptiert, laden Sie das Raw- oder qcow2-Image des Anbieters hoch, und die Arbeit ist erledigt. Andernfalls schreiben Sie das Laufwerk selbst aus dem Rettungssystem. Flatcar stellt dafür ein eigenständiges Skript bereit, das unter jedem Linux-System ausgeführt werden kann:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Führen Sie das Skript aus dem Rettungssystem aus, niemals auf dem Server, den Sie ersetzen, da es während der Ausführung die Partitionierung des Ziellaufwerks ändert. Auf dem Laufwerk müssen mindestens 8 GB nutzbarer Speicherplatz vorhanden sein. Die Rettungsumgebung muss außerdem bash, bzip2 oder lbzip2, lsblk, wget, udevadm, gpg und gawk bereitstellen. Ihre ignition.json muss einen SSH-Schlüssel enthalten. Andernfalls bietet das installierte System keine Möglichkeit, sich anzumelden.

Fedora CoreOS funktioniert nach demselben Prinzip, und sein Installer läuft als Container:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Prüfen Sie den Gerätenamen mit lsblk, bevor Sie den Befehl ausführen. Das Schreiben auf das falsche Gerät zerstört dessen bisherigen Inhalt. Eine Bestätigungsabfrage gibt es nicht.

bootc bietet die einzige Möglichkeit, den Rettungsmodus zu überspringen, da es ein laufendes Linux-System direkt vor Ort konvertiert:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Lesen Sie vor der Ausführung die Dokumentation des verwendeten Basis-Images. Testen Sie den Vorgang außerdem auf einem Server, den Sie problemlos verwerfen können. Nach dem Reboot läuft das System mit dem Image. Der zuvor installierte Paketsatz ist nicht mehr vorhanden.

Wer sollte einen unveränderlichen Server betreiben und wer nicht

Das ist sinnvoll, wenn Ihre Server wie Vieh behandelt werden: viele Maschinen aus einem gemeinsamen Rezept. Dazu gehören CI (continuous integration)-Runner, die eine Stunde lang laufen, sowie k3s- oder Kubernetes-Knoten, die ersetzt statt repariert werden. Das gilt für alle Systeme, bei denen die Antwort auf einen defekten Rechner bereits lautet: „Löschen Sie ihn und erstellen Sie einen neuen.“ Ein weiterer Vorteil ergibt sich, wenn Sie einem Auditor nachweisen müssen, was auf einer Maschine läuft. Die Antwort ist dann ein Image-Digest statt einer Paketliste.

Das ist nicht sinnvoll, wenn Sie einen manuell gepflegten VPS mit drei darauf laufenden Diensten haben, bei Bedarf Software installieren und keine Build-Pipeline besitzen. Der Image-Modus beseitigt den Aufwand nicht. Er verlagert ihn vom Server in den Build und verursacht dafür Kosten für eine Registry und eine Pipeline. Wenn Sie diesen Aufwand abbilden können, erhalten Sie identische Server, und ein Rollback besteht aus einem Reboot. Wenn nicht, fügen Sie einem bisher funktionierenden System zusätzliche Komponenten hinzu und machen die Fehlerbehebung um 2am schwieriger.

Der unspektakuläre Mittelweg funktioniert weiterhin: eine normale Distribution mit automatischen Sicherheitsupdates sowie ein Wiederaufbau, den Sie tatsächlich geübt haben. Die Auswahl dieser Basis ist eine eigene Entscheidung und wird unter Auswahl des Betriebssystems für Ihren VPS behandelt. Der Image-Modus ist nur die neueste Runde einer sehr alten Diskussion darüber, wie Software auf eine Maschine gelangen sollte. Die Geschichte der Linux-Distributionen besteht größtenteils aus der Wiederholung dieser Diskussion.

FAQ

Ist eine unveränderliche Linux-Distribution wirklich unveränderlich?

Nein, und der Name sorgt für Verwirrung. root kann weiterhin auf die Festplatte schreiben. Tatsächlich wird /usr zur Laufzeit schreibgeschützt eingehängt und beim nächsten Image vollständig ersetzt, während /etc und /var beschreibbar bleiben und Updates überstehen. Änderungen unter /usr werden entweder sofort abgewiesen oder beim nächsten Update verworfen. Praktisch bedeutet das, dass sich Systemverzeichnisse nur ändern, wenn sich das Image ändert.

Kann ich Fedora CoreOS oder Flatcar auf einem VPS ausführen, der diese Distributionen nicht anbietet?

In der Regel ja, wenn der Anbieter ein Rettungssystem und Konsolenzugriff bereitstellt. Sie starten das Rettungssystem, schreiben das Disk-Image der Distribution auf das Blockgerät und starten anschließend neu. Das flatcar-install-Skript von Flatcar erledigt dies unter jedem Linux-System. Fedora CoreOS stellt coreos-installer als Container bereit, den Sie auf dieselbe Weise ausführen können. Beide benötigen eine Ignition-Datei mit Ihrem SSH-Schlüssel, da es keine Passwortabfrage beim ersten Start gibt, auf die Sie zurückgreifen könnten. Versuchen Sie es ohne Konsolenzugriff nicht. Wenn die Maschine nicht wieder startet, haben Sie keine Möglichkeit, den Fehler zu untersuchen.

Wie installiere ich ein Paket auf einem unveränderlichen Server?

Sie fügen es dem Image hinzu und führen ein erneutes Deployment durch. Bei bootc ist dafür eine RUN dnf -y install ...-Zeile im Containerfile erforderlich, danach ein Rebuild und ein Push sowie sudo bootc upgrade --apply auf der Maschine. Unter Fedora CoreOS können Sie das Paket mit sudo rpm-ostree install als zusätzliche Schicht installieren und anschließend neu starten. Das Paket wird dann bei jedem künftigen Update erneut angewendet. Auf Flatcar und Talos gibt es keinen Paketmanager. Daher lautet die Lösung: ein Container. Für ein einmaliges Debugging-Tool auf einem bootc-Host stellt sudo bootc usr-overlay ein beschreibbares /usr bereit, das beim nächsten Neustart verschwindet.

Behebt der Image-Modus einen VPS, der nach einem Kernel-Update nicht mehr startet?

Die Wiederherstellung wird dadurch von einer Aufgabe an der Rettungskonsole zu einem Neustart. Das vorherige Image bleibt zusammen mit Kernel und Userspace auf der Festplatte. Mit sudo bootc rollback oder sudo rpm-ostree rollback -r kehren Sie dorthin zurück. Talos und Flatcar gehen noch weiter und führen automatisch ein Rollback durch, wenn der neue Slot nicht startet. Ein Boot-Eintrag wird erst nach einem erfolgreichen Start zum Standard. Nichts davon verhindert ein fehlerhaftes Update. Es macht das Rückgängigmachen jedoch einfach.

Welche unveränderliche Distribution sollte ich für einen Server auswählen?

Wählen Sie bootc, wenn Sie einen Linux-Server für allgemeine Zwecke wie ein Container-Image erstellen und auf einer bereits vorhandenen Maschine installieren möchten. Wählen Sie Fedora CoreOS, wenn Sie dieses Modell mit automatischer Erstellung und standardmäßig aktivierten automatischen Updates nutzen möchten. Wählen Sie Flatcar, wenn Sie einen minimalistischen Container-Host mit einem A/B-Update-Verfahren und ohne Paketmanager möchten. Wählen Sie Talos nur, wenn die Maschine ein Kubernetes-Knoten ist, da Talos keine Shell bereitstellt und keine anderen Aufgaben ausführt.