In this article
A NixOS change leaves your desktop behaving incorrectly. An earlier system configuration can provide a useful way back. NixOS retains built system configurations as generations while their required store paths remain available.
This article extends my configuration.nix introduction. Cthulhu supplies a concrete example: its current file uses systemd-boot, limits displayed configurations to five and deliberately disables automatic garbage collection. These choices support considered recovery but do not replace data backups.
A generation is not a full disk snapshot
A system generation links built programs, services and system configuration into an activatable version. Built outputs remain in the Nix store, so returning to an older configuration does not require manually downgrading every package.
Your home directory, databases and many mutable application files are separate. A newer application may already have migrated a database; an older version may not understand that format. A rollback also does not restore a deleted personal file.
| Included or referenced | Back up separately |
|---|---|
| Built system packages and service configuration | Documents and game saves |
| Kernel and system store outputs | Databases and mutable application data |
| Activatable system configuration | Your edited configuration source files |
Inspect the running system and retained generations
Display the running system path:
readlink -f /run/current-system
List generations of the usual system profile:
sudo nix-env --profile /nix/var/nix/profiles/system --list-generations
The output includes generation numbers, times and a current-profile marker. An intentionally older boot and the profile selection do not necessarily describe the same state. Record both the running path and profile list before changing anything.
This inspection deletes no generation. A shortened history may result from earlier cleanup or another profile arrangement. Select versions whose origin you understand.
Roll back while the desktop is accessible
Use the usual command to select the previous system-profile generation:
sudo nixos-rebuild switch --rollback
The previous profile generation is not automatically the last boot you personally tested successfully. Services may restart during activation. Save open work and perform the switch deliberately.
A kernel change takes full effect only after booting the corresponding kernel. Check the previously failing function after switching, and reboot when a kernel change requires it. Choose an appropriate time, particularly on a machine providing active services.
Retained store outputs avoid a fresh build. If required paths were removed or damaged, recovery may still fail. A rollback has prerequisites; it cannot guarantee recovery from every system or storage failure.
Recover through the boot menu
Choose a known older NixOS generation from the boot menu. Cthulhu uses systemd-boot; other systems may use GRUB. Access depends on the bootloader, firmware and timeout.
My file contains:
boot.loader.systemd-boot.configurationLimit = 5;
boot.loader.timeout = 2;
Two seconds is short. Learn how to reach your menu before a change becomes critical. The limit of five controls bootloader configurations; it does not mean every other store object is automatically deleted.
After successfully booting an older version, investigate the failed change and make the configuration source understandable again. If no suitable version boots, installation media and targeted repair may be needed. This article does not provide a universal live-USB repair procedure.
Correct the source configuration afterwards
A rollback does not automatically rewind your hand-edited /etc/nixos/configuration.nix or Git repository. Leaving the faulty change in that source may reintroduce it at the next build.
Compare recently changed options against your backed-up or versioned configuration. Undo the relevant change deliberately. My backup guide explains why configuration files and data backups serve different purposes.
Build before activating:
sudo nixos-rebuild build
A successful build confirms construction, rather than actual behaviour on your hardware. Test the intended configuration deliberately and record which generation you verified as working.
Distinguish build, test, boot and switch
| Action | Effect |
|---|---|
build |
Build without switching the running system |
test |
Activate without updating the normal boot default |
boot |
Prepare the next boot without activating now |
switch |
Activate and update the boot default |
test can still change running services and disrupt a session. Its benefit is the separate boot default, rather than a risk-free simulation. A working recovery route matters particularly for graphical and networking changes.
Cthulhu uses a channel-based configuration importing hardware-configuration.nix; it does not enable flakes. With flakes, your actual flake selection and lock file belong to the process. Do not copy another computer's project path into a system command.
Understand retention and stateVersion
Deleting old generations and garbage collection can remove an earlier recovery option. Clean up only after checking the new version sufficiently and backing up the required data. This exercise deliberately includes no generation-deletion command.
system.stateVersion does not select a rollback and should not be bumped automatically with every update. Cthulhu specifies 26.05, documenting compatibility choices from the initial system setup. Changing it requires a separate, justified review.
References
- Checked Cthulhu configuration: bootloader, retention choices and setup.
- NixOS manual: rollbacks.
- NixOS manual: changing configuration.
- Nix manual: listing generations.
Sources checked on 8 October 2026. Recovery should refer to a known generation and a specific observed problem.