NixOS & Wiederherstellung

NixOS-Rollback: Generationen und Updates rückgängig machen

Vorhandene Systemstände lokal auswählen

Vorhandene Generationen liegen im lokalen Nix-Store. Ein Neubau kann Pakete und Quellen herunterladen. Rollbacks ersetzen kein Backup deiner Dokumente, Spielstände oder Datenbanken.

In diesem Artikel
  1. Eine Generation ist kein kompletter Festplatten-Snapshot
  2. Den aktiven Stand und vorhandene Generationen ansehen
  3. Wenn der Desktop noch erreichbar ist
  4. Wenn nur noch das Bootmenü erreichbar ist
  5. Die Quelldatei anschließend korrigieren
  6. build, test, boot und switch unterscheiden
  7. Aufbewahrung und stateVersion richtig verstehen
  8. Quellen

Nach einer NixOS-Änderung startet der Desktop nicht mehr wie erwartet. Ein vorheriger Systemstand kann dann ein wertvoller Rückweg sein. NixOS hält gebaute Systemkonfigurationen als Generationen bereit, solange ihre benötigten Store-Pfade erhalten bleiben.

Dieser Artikel vertieft meinen configuration.nix-Einstieg. Als konkreter Bezug dient Cthulhu: Die aktuelle Datei verwendet systemd-boot, begrenzt dessen angezeigte Konfigurationen auf fünf und verzichtet ausdrücklich auf automatische Garbage Collection. Diese Entscheidungen erleichtern bewusstes Zurückwechseln, ersetzen aber keine Datensicherung.

Eine Generation ist kein kompletter Festplatten-Snapshot

Eine Systemgeneration verbindet unter anderem gebaute Programme, Dienste und Systemkonfiguration zu einem aktivierbaren Stand. Bereits gebaute Ausgaben sind im Nix-Store verfügbar. Dadurch musst du für einen Rückweg nicht jedes Paket einzeln wieder auf eine frühere Version bringen.

Dein Home-Verzeichnis, Datenbanken und viele veränderliche Anwendungsdaten sind davon getrennt. Eine neue Anwendung kann eine Datenbank bereits migriert haben; die alte Anwendung versteht dieses Format möglicherweise nicht mehr. Ein Rollback stellt auch eine gelöschte private Datei nicht wieder her.

Enthalten beziehungsweise referenziert Separat sichern
Gebaute Systempakete und Dienstkonfiguration Dokumente und Spielstände
Kernel und systembezogene Store-Ausgaben Datenbanken und mutable App-Daten
Aktivierbarer Systemstand Deine bearbeiteten Konfigurationsquellen

Den aktiven Stand und vorhandene Generationen ansehen

Zeige zunächst den laufenden Systempfad:

readlink -f /run/current-system

Liste anschließend die Generationen des üblichen Systemprofils:

sudo nix-env --profile /nix/var/nix/profiles/system --list-generations

Die Ausgabe enthält Nummern, Zeitpunkte und eine Markierung für die aktuelle Profilgeneration. Ein bewusst älterer Boot und die aktuelle Profilwahl müssen nicht dieselbe Geschichte erzählen. Notiere deshalb sowohl den laufenden Pfad als auch die Profilübersicht, bevor du etwas änderst.

Diese Prüfung löscht keine Generation. Eine leere oder verkürzte Historie kann auf vorheriges Aufräumen oder einen anderen Profilaufbau hindeuten. Verwende nur Stände, deren Herkunft du nachvollziehen kannst.

Wenn der Desktop noch erreichbar ist

Für das vorherige Systemprofil gibt es den üblichen Rollback-Befehl:

sudo nixos-rebuild switch --rollback

Er aktiviert die vorherige Generation des Systemprofils. Das ist nicht automatisch der zuletzt von dir erfolgreich getestete Boot. Dienste können dabei neu gestartet werden; führe den Schritt bewusst aus und sichere vorher offene Arbeit.

Ein Kernelwechsel wird vollständig erst durch Booten des entsprechenden Kernels wirksam. Prüfe nach dem Wechsel die Funktion, die zuvor Probleme machte, und starte bei einem nötigen Kernelwechsel neu. Nutze dafür einen passenden Zeitpunkt, besonders bei einem Rechner, der gerade Dienste bereitstellt.

Vorhandene Store-Ausgaben sparen einen Neubau. Wenn benötigte Pfade inzwischen entfernt oder defekt sind, kann der Rückweg trotzdem scheitern. Ein Rollback ist ein Werkzeug mit Voraussetzungen, keine Garantie gegen jede Form von System- oder Datenträgerfehler.

Wenn nur noch das Bootmenü erreichbar ist

Wähle im Bootmenü eine bekannte ältere NixOS-Generation. Cthulhu verwendet systemd-boot; andere NixOS-Rechner können GRUB nutzen. Der genaue Zugang zum Menü hängt von Bootloader, Firmware und Timeout ab.

In meiner Datei steht:

boot.loader.systemd-boot.configurationLimit = 5;
boot.loader.timeout = 2;

Zwei Sekunden sind kurz. Plane den Zugriff auf dein Menü, bevor eine Änderung kritisch wird. Die Grenze von fünf Einträgen begrenzt Bootloader-Konfigurationen; sie bedeutet nicht, dass pauschal alle anderen Nix-Store-Daten gelöscht werden.

Nach einem erfolgreichen älteren Boot untersuchst du die misslungene Änderung und bringst die Konfigurationsquelle wieder in einen nachvollziehbaren Zustand. Wenn kein passender Stand bootet, brauchst du gegebenenfalls ein Installationsmedium und eine gezielte Reparatur. Dieser Artikel ist kein universeller Live-USB-Reparaturablauf.

Die Quelldatei anschließend korrigieren

Ein Rollback spult deine handbearbeitete /etc/nixos/configuration.nix oder dein Git-Repository nicht automatisch zurück. Bleibt die fehlerhafte Änderung darin stehen, kann ein neuer Build sie wieder einführen.

Vergleiche daher die zuletzt geänderten Optionen mit deinem gesicherten beziehungsweise versionierten Stand. Nimm nur die betroffene Änderung zurück. Mein Backup-Artikel erklärt, warum Dotfiles und echte Datenbackups unterschiedliche Aufgaben haben.

Baue zunächst ohne Aktivierung:

sudo nixos-rebuild build

Ein erfolgreicher Build bestätigt den Bau, aber noch nicht das Verhalten auf deiner Hardware. Teste den gewünschten Stand anschließend bewusst und halte fest, welche Generation du als funktionierend erkannt hast.

build, test, boot und switch unterscheiden

Aktion Wirkung
build Bauen, ohne das laufende System umzuschalten
test Aktivieren, ohne die normale Bootvorgabe neu festzulegen
boot Für den nächsten Boot vorbereiten, jetzt nicht aktivieren
switch Aktivieren und die Bootvorgabe aktualisieren

Auch test kann laufende Dienste verändern und eine Sitzung beeinträchtigen. Der Vorteil ist die getrennte Bootvorgabe, keine risikofreie Simulation. Für grafische oder Netzwerkänderungen ist ein funktionierender Rückweg besonders sinnvoll.

Cthulhus Datei benutzt einen channelbasierten Aufbau mit hardware-configuration.nix; sie aktiviert keine Flakes. Wenn du Flakes nutzt, gehören deine tatsächliche Flake-Auswahl und Lock-Datei zum Ablauf. Kopiere nicht einfach den Projektpfad eines fremden Rechners in einen Systembefehl.

Aufbewahrung und stateVersion richtig verstehen

Das Entfernen alter Generationen und Garbage Collection können einen zuvor verfügbaren Rückweg aufheben. Räume erst auf, wenn du den neuen Stand ausreichend geprüft und die nötigen Daten gesichert hast. Für diese Übung gibt es bewusst keinen Löschbefehl.

system.stateVersion ist keine Rollback-Auswahl und kein Schalter, den du bei jedem Update auf die neueste Version setzt. In Cthulhus Datei steht 26.05; der Wert dokumentiert Kompatibilitätsvorgaben des ursprünglichen Systemaufbaus. Seine Änderung benötigt eine eigene begründete Prüfung.

Quellen

Quellenstand: 8. Oktober 2026. Ein Rückwechsel sollte sich auf eine bekannte Generation und ein konkretes beobachtetes Problem beziehen.