Unpopular opinion: Maybe `stateVersion` shouldn't exist at all

At build time system.stateVersion would be used, the check would only be made when running nixos-rebuild {switch,boot,test} or switch-to-configuration {switch,boot,test} (or other commands capable of independently changing a system’s configuration).

The reason I include nixos-rebuild in this is to stop the following chain of events leading to a potentially unbootable system:

  1. A user changes system.stateVersion
  2. The user runs nixos-rebuild boot creating /nix/var/nix/profiles/system-x
    2.1. switch-to-configuration boot catches the stateVersion change and refuses to update the bootloader entries
  3. The user reverts the change
  4. The user runs nixos-rebuild boot again creating /nix/var/nix/profiles/system-x+1
    4.1 switch-to-configuration then updates the bootloader entries including system-x

By preventing step 2 by adding a check in nixos-rebuild boot, a potential avenue for an unsafe update is stopped.

1 Like

it’s still leaking abstraction… Something considered bad…

“Fix or fail loudly”… You can’t fix stateVersion-changes, so you should break out of activation very early. Leaving you with services to fix the problem and nothing more.

Yeah no, that’s just not acceptable. It would break current and possibly past generations, making the system unbootable.

Activation runs at every boot, btw.

2 Likes

But every generation has it’s activation. Past generations won’t be affected (although they could be broken by changed stateVersions)

NixOS doesn’t generally attempt to abstract away the underlying services. It’s often just mappers from attrsets to the softwares own configuration format (sometimes with templates, sometimes with serialiation like toJSON) and in most nontrivial cases you learn how to configure a service by reading the software documentation.

To be honest, a NixOS option that breaks the current and previous generations sounds very bad. Perhaps therefore, the stateVersion option shouldn’t exist at all.

This has nothing to do with state version. They’re just coming up with a proposal that’s never going to happen.

Not with this Mindset. Therefore, we’ll need to change it. :wink:

If you believe a mindset needs to be changed, it would be much more convincing to provide reasoning. In particular, your understanding of the proposed solution and the objections, and why you believe the objections are unfounded or overstated.

You’re completely confused. The breakage comes from their proposal, not from stateVersion itself. Their proposal should never be implemented, and it won’t, since anyone familiar with NixOS would know better.

If you don’t understand a conversation, ask as an aside instead of derailing with assumptions.

3 Likes

So far, the only proposal in thread that seems sensible is adding a check comparing the system.stateVersion with some stateful file to switch-to-configuration, and maybe the bootloader or some service in stage1.

The latter could even use the systemd boot assessment mechanism, so the system is automatically rolled back.

This would solve the problem of accidentally switching or booting into a generation with incompatible state. I think this is really useful and would be happy if someone would implement this.

All other proposals would make things even worse or are really nonsensical.

3 Likes