A reading path
NixOS: builds, rollback and mutable state
Understand Nix derivations, build and host platforms, configuration rollback and the database state that needs its own recovery plan.
Build descriptions and runtime state answer different questions
A derivation describes a build’s inputs and builder. Reproducibility also depends on whether the builder stays within that description. At runtime, a service can mutate a database outside the immutable store. A successful configuration rollback therefore does not establish that its persistent state can be read by the older program.
Review a rollback before you need it
Read the rollback note together with the derivation explanation. Identify the previous service binary, its expected database schema and the location of persistent data. A database migration may require a compatible restore or a separately planned reversal. Booting an earlier system generation is only one step in that recovery.
Cross compilation adds another boundary
When a Nix build produces software for another platform, use the build/host/target distinctions to state where each tool runs and what it emits. Follow the primary Nix and GCC manuals below for actual configuration. The current essays are explanations, not an assertion that every package or database supports the same rollback procedure.
Work through the notes
A Nix derivation describes a build; it does not prove reproducibility
A derivation records a build step and its declared dependencies, but matching that recipe does not guarantee identical output bytes when the process can observe undeclared inputs or nondeterminism.
Rolling back NixOS does not roll back a database
NixOS generations let you select an earlier system configuration, while database files and other mutable data follow their own lifecycle and compatibility rules.
Cross compilation: build, host and target are different questions
The build, host, and target labels describe a compiler’s own construction and output roles. Ordinary package cross compilation adds separate questions about headers, libraries, and where the result can run.
A useful setup log starts with the question it can answer
A compact diagnostic record should let someone reproduce a specific observation: state the question, environment, command, exit status, and relevant output. Keep that setup transcript distinct from an inventory of files or storage.
Download the accompanying example