New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos: warn on missing stateVersion
#39447
nixos: warn on missing stateVersion
#39447
Conversation
fbbc318
to
754dfee
Compare
Can you verify that this would be set in the vms? I belivenit was missing on those configs. |
Can you verify that this would be set in the vms? I belivenit was missing on those configs.
You mean VMs? Is there a use case where this warning should not be given? Can you elaborate?
The original thread doesn't mention any such things.
|
So some VMs don’t generate their config with the perl script. I just want to make sure these have it set correctly (it may be in the profile but i can’t remember). |
Well, building `.vm` attribute should work exactly as before as it uses normal `configuration.nix`. VM tests might generate some warnings, but that could be cleaned up later.
Let's just check, I guess
@GrahamcOfBorg test boot
|
Failure on aarch64-linux (full log) Partial log (click to expand)
|
Failure on x86_64-linux (full log) Partial log (click to expand)
|
Yeah, it's ugly. But it's the minimal change that doesn't break anything else.
… is explicitly set
754dfee
to
1f0b692
Compare
Rebased.
@GrahamcOfBorg test boot
|
Success on x86_64-linux Attempted: tests.boot No partial log is available. |
Success on aarch64-linux Attempted: tests.boot No partial log is available. |
Ok sounds good as a warning. Look out for issues regarding this though. I think the fixes should be easy it’s just generated somewhere I can’t find now |
Thanks!
|
When doing release upgrades with nixos-rebuild, it is untrue that you get unbroken behavior without To make warning more justified, we can do like this:
(I don't think we can check whether |
Sure, we can do that, but I think that's an overkill as it introduces yet another general warning mechanism for a single use case. But if we had more of those, I would be ok with something like that.
As it stands now I'd prefer we go the way I specified above: split `stateVersion` into a bunch of per service options. That way you could migrate your services one by one between releases and we then could do warnings only when the service is enabled with the default warning system.
|
Motivation for this change
The first patch is OCD. The last patch is the part of #35366 everyone agreed upon. The middle one is plumbing.
Things done