Skip to content
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

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

Open
montchr opened this issue Dec 12, 2023 · 7 comments
Open

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

montchr opened this issue Dec 12, 2023 · 7 comments

Comments

@montchr
Copy link
Contributor

montchr commented Dec 12, 2023

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
Copy link
Contributor Author

montchr commented Dec 12, 2023

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
Copy link
Collaborator

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
Copy link
Contributor Author

montchr commented Dec 13, 2023

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
Copy link
Contributor Author

montchr commented Dec 13, 2023

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

@blaggacao
Copy link
Collaborator

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
Copy link
Contributor Author

montchr commented Dec 14, 2023

@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 🙃

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
Copy link
Collaborator

blaggacao commented Dec 14, 2023

If understanding is accurate, there are two failure modes:

  • nixos-rebuild using a past unsuitable version of nix for the current evaluation
  • the current evaluation of a configuration failing to provide a suitable version of Nix (e.g. because no channel-update is desired)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants