stuck on old nixos generation due to nix version incompatibility about std HOT 7 OPEN

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]

from std.

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!

from std.

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?

from std.

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

from std.

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).

from std.

@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).

from std.

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.

from std.