I’m not an expert, but I have a home-manager config managed with fleek on a non-NixOS system. When I went to install it on a new system yesterday, I’m suddenly always getting a nix error.
Narrowing it down, I have a local nix flake thats a git repo (which happens to be a fleek managed home-manager config). The first time I do nix build on the flake it works. If I make any change at all to the repo and commit the change, the next nix build fails with the error:
error:
... while fetching the input 'git+file:///home/{user}/.local/share/fleek
error: getting working directory status: invalid data in index - calculated checksum does not match expected
If I try to run any nix commands that involve the store, I get the same error an no further results. If I delete my flake and re-clone it, I get the same error still. Bascially, once I get the error I haven’t found any way to get rid of it other than to uninstall nix entirely and re-install it.
The only debug info I can get is by running nix store verify --debug, which just tells me that one of the derivations in the flake is being evaluated when the error occurs. No details at all about the actual error it’s saying occurred.
I’m beginning to think this might be a major bug in nix 2.20.3, because that’s the latest version of nix and the one that gets installed by default with the Determinate Nix Installer I’ve been using. My existing systems that are on Nix 2.18.1 are still working fine when using the identical flake and when making changes and rebuilding the flake. I’ve reproduced the error on 3 different systems now, all of them using the same config and receiving different changes as the first change after the initial nix build.
There’s no explanation for what the error is, but it sounds to me like it’s talking about a git working directory status not being able to be parsed. That would definitely be a nix bug since I have the identical version of git installed on both the working and non-working systems.
Any ideas where to go from here in trying to resolve this or determine a root cause?
this is probably a regression caused by Nix switching to libgit2 (imo a mistake). you can file it in the bug tracker with the other libgit2 regressions; repro much appreciated
Oh excellent. I’ve been pulling my hair out assuming I must have done something wrong.
I dug into the settings and was able to uninstall nix and re-install with 2.18.1 instead of the (now) latest 2.20.5. I can indeed confirm that the identical flake works to rebuild after adding changes when using 2.18.1 but not with 2.20.3 or 2.20.5. I’ll file a bug.
For future readers:
# uninstall current nix
/nix/nix-installer uninstall
# re-install specifying the exact 2.18.1 version (assumes LInux x86_64 system, you'll need to find your matching URL)
./determinate-nix-installer.sh install --nix-package-url=https://releases.nixos.org/nix/nix-2.18.1/nix-2.18.1-x86_64-linux.tar.xz
@aaravchen Did you try sudo -i nix upgrade-nix?
I also use Determinate installer but on Mac, and I could not do a full uninstall and reinstall on Mac[reason listed below]
> /nix/nix-installer uninstall
`nix-installer` needs to run as `root`, attempting to escalate now via `sudo`...
Password:
`nix-darwin` installation detected, it must be removed before uninstalling Nix. Please refer to https://github.com/LnL7/nix-darwin#uninstalling for instructions how to uninstall `nix-darwin`.
Uninstalling nix-darwin is a pain, I recommend avoiding uninstalling it.
Can you elaborate on why it’s a pain? I haven’t done it, but the description at that link sounds at least fairly straightforward:
Uninstalling
There’s also an uninstaller if you don’t like the project and want to remove the configured files and services.
nix-build https://github.com/LnL7/nix-darwin/archive/master.tar.gz -A uninstaller ./result/bin/darwin-uninstaller
Speaking broadly, upgrade-nix switches to some explicitly-declared ~stable Nix (which may, of course, not be the most-recent release). Normally the source for this is a declaration in nixpkgs, but it sounds like the detsys installer grafts in its own source for this information. They do try to document this, but unfortunately the link in their README is a 404 at the moment:
Here’s the most-recent corresponding issue on their end, though it looks like several issues on this behavior have been opened at one point or another:
I ran into this issue as well. I believe it was because of the transition to libgit2. In any case, on my system, the underlying problem was the use of features.manyFiles = true in the git config, which under the hood sets index.skipHash = true.
You can fix it in a specific repo by setting either of the aforementioned git settings to false and then running git reset --mixed
