Open montchr opened 11 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]
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!
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?
I updated the original example to include my current workaround using nix run nix
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).
@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).
If understanding is accurate, there are two failure modes:
nixos-rebuild
using a past unsuitable version of nix for the current evaluationMaybe 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.
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:and yet:
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 devshelli'm hesitant to run the nixos activation script manually because it's been so long