divnix / std

A DevOps framework for the SDLC with the power of Nix and Flakes. Good for keeping deadlines!
https://std.divnix.com
377 stars 41 forks source link

stuck on old nixos generation due to nix version incompatibility #363

Open montchr opened 7 months ago

montchr commented 7 months ago

i'm trying to update a nixos machine that's been sitting in my closet for a year. however, any time i try to run nixos-rebuild i get the following:

[root@ryosuke:~]# nixos-rebuild build
building the system configuration...
error: The truth is: you'll need a newer nix version to use Standard (minimum: v2.13).

and yet:

[root@ryosuke:~]# nix --version
nix (Nix) 2.19.2

this has become increasingly frustrating as i have tried many workarounds, and all i want to do is update, but i seem to be stuck in some kind of catch-22 limbo situation

i'm not even sure why this error only shows up with nixos-rebuild -- i am not in a devshell

i'm hesitant to run the nixos activation script manually because it's been so long

montchr commented 7 months ago

I managed to get around it with:

# Uses the flake registry for Nix repo
# Requires building Nix HEAD from source (but can prob specify a different branch)
# HEAD is not guaranteed to work properly
alias nix='nix run nix --'
nix build /etc/nixos#nixosConfigurations."ryosuke".config.system.build.nixos-rebuild
sudo ./result/bin/nixos-rebuild boot

[Edited from my original comment for accuracy]

blaggacao commented 7 months ago

This is probably relevant data when discussing dynamic vs static linking of libnix in https://github.com/water-sucks/nixos — thanks for bringing this up!

montchr commented 7 months ago

I managed to get around it by running nix build /etc/nixos#nixosConfigurations."ryosuke".config.system.build.nixos-rebuild and then using the resulting binary via ./result/bin/nixos-rebuild boot. Writing now from the new system.

Correction: it is not so simple. I am also updating another machine and running into the same issue, even when running that nix build command. Somehow I need to install the most recent version of Nix (hence the catch-22). I think I left something out of my comment -- I will edit to include the additional steps.

Considering this seems to me like a blocker without an obvious solution, can the error message provide some further advice about how to proceed? I am guessing that anyone who is using Standard for their system flake configuration would run into this trap if they had an outdated system.


Update: This other system (called boschic, not ryosuke as in the above console output) might be even more out of date. Its nixpkgs seems to have no compatible Nix version:

✖1  nix profile install nixpkgs#nix_2_13
error: flake 'flake:nixpkgs' does not provide attribute 'packages.x86_64-linux.nix_2_13', 'legacyPackages.x86_64-linux.nix_2_13' or 'nix_2_13'
       Did you mean one of nix_2_3, nix_2_4, nix_2_5 or nix_2_6?
montchr commented 7 months ago

I updated the original example to include my current workaround using nix run nix

blaggacao commented 7 months ago

There's no way to tell nixos-* which Nix binary it should use? I'm not familiar with the nixos-* family and its design seems rather scattered and somewhat occasional to me (e.g. some are bash, some are c++, etc).

montchr commented 7 months ago

@blaggacao From what I can tell, there's nothing so obvious or direct, which certainly supports your description of nixos-* as scattered. Like many things Nix, I suspect that there might be some "happy" path out there to provide a workaround, but such happy paths seem impossible to find when I'm actually looking for them :upside_down_face:

Regardless, even if I could specify a nix binary to use, the issue is that until the system is rebuilt with updated flake inputs, nix and all of its related commands have absolutely no idea that there is any version past v2.11. That's why I've resorted to building nixos-rebuild from the system's flake output with a shimmed nix version via nix run 'github:NixOS/nix?ref=2.19.2' -- build <...>.build.nixos-rebuild (updated from my previous comments to make use of a pinned version for its cached binary).

Since this is feeling more like a log of my journey (and I'm done with updating old systems now), I could close this issue, though I still feel as though there is something strange in the way that Standard blocks nixos-rebuild. Like, I don't even understand why that is happening.

In the end, it effectively leads me towards thinking I should avoid Standard for anything but the most up-to-date use cases with extensive CI updates automation etc. (it's hard to keep up sometimes) and not so much for personal NixOS machines that could sit in a closet for a while, subject to decay (this one laptop I'm working on had its clock stuck back in October 2022 cos of some WIP system generation breaking DNS...)). I guess that's kinda the point of Hive but in the end I just want the project structure to work reliably even if it's not updated in a long time (and, really, I don't think a year is that long of a time).

blaggacao commented 7 months ago

If understanding is accurate, there are two failure modes:

Maybe both problems could be tackled by ignoring system-available nixos-* and instead fetch newer ones (nix shell github:nixos/nixpkgs#nixos-*). These then also come with a newer version of Nix.

Wouldn't that bring in the right version of nixos-build, and thus Nix, in both cases?

The system, by pinning the Nix version to reproduce itself, effectively forbids language innovation. I think Nixlang should be mentally considered exogenous to the system. Thus, it might have even been a better design choice for nixos-rebuild to not pin it's Nixlang version, i.e. the Nix binary.