error: path is not valid using nix ==2.18.0 #9052
Comments
|
I'm on commit edolstra@3494c29 in lazy-trees parent for that merge is edolstra@7f8c99c Should help with bisecting because 2.17 was released on July 24
Also seen in the #nix-dev:nixos.org room @trofi said
#4628 was a big PR so could be that |
|
If anyone is trying to reproduce, I should add to @avdv's description of the bug that if you happen to already have I can reliably reproduce the error with Nix 2.18.0 on a new Nix installation, though. |
|
@Artturin I'm one of the maintainers of the https://github.com/digital-asset/daml repo and I can reliably reproduce the bug on 2.18.0 and can confirm it does not appear in with 2.17.0. Are there reasonably-easy-to-follow instructions on how to install arbitrary Nix commits instead of released versions? If so I could help with bisecting. |
|
@Artturin spot on! (oh, it's not from PR #4628, but seems related) It is from #8829 |
|
This started affecting my nixos-unstable-small system flake after a |
|
I was able to get things back up and running |
|
I can confirm |
Re the path, are you sure the next one isn't a different bash output? At first I thought it didn't work because there was |
|
FWIW, I ran into this with the following store paths:
while upgrading with this commit https://or.computer.surgery/charles/dotfiles/-/commit/7d406812e27e254486ec7a8a01d28bc20eee7694. My workaround was to run |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/amd-rx-7700-xt-not-being-detected-properly/33683/5 |
This reverts commit 13ec865. This has caused widespread pain because of NixOS/nix#9052
|
It would be handy if someone had a way to reproduce that worked with I will work on this as the issue is assigned to me, but posting this here in case someone already has one. |
|
I'm seeing the same problem in CI using 2.18.0 (and not locally, using 2.17.0). |
This reverts commit 5e3986f. This un-implements RFC 92 but fixes the critical bug NixOS#9052 which many people are hitting. This is a decent stop-gap until a minimal reproduction of that bug is found and a proper fix can be made. Mostly fixed NixOS#9052, but I would like to leave that issue open until we have a regression test, so I can then properly fix the bug (unbreaking RFC 92) later.
This reverts commit 5e3986f. This un-implements RFC 92 but fixes the critical bug NixOS#9052 which many people are hitting. This is a decent stop-gap until a minimal reproduction of that bug is found and a proper fix can be made. Mostly fixed NixOS#9052, but I would like to leave that issue open until we have a regression test, so I can then properly fix the bug (unbreaking RFC 92) later.
This reverts commit 5e3986f. This un-implements RFC 92 but fixes the critical bug NixOS#9052 which many people are hitting. This is a decent stop-gap until a minimal reproduction of that bug is found and a proper fix can be made. Mostly fixed NixOS#9052, but I would like to leave that issue open until we have a regression test, so I can then properly fix the bug (unbreaking RFC 92) later.
This reverts commit 5e3986f. This un-implements RFC 92 but fixes the critical bug NixOS#9052 which many people are hitting. This is a decent stop-gap until a minimal reproduction of that bug is found and a proper fix can be made. Mostly fixed NixOS#9052, but I would like to leave that issue open until we have a regression test, so I can then properly fix the bug (unbreaking RFC 92) later.
This reverts commit 5e3986f. This un-implements RFC 92 but fixes the critical bug NixOS#9052 which many people are hitting. This is a decent stop-gap until a minimal reproduction of that bug is found and a proper fix can be made. Mostly fixed NixOS#9052, but I would like to leave that issue open until we have a regression test, so I can then properly fix the bug (unbreaking RFC 92) later.
|
EDIT: I can't reproduce this anymore. To avoid confusing people I've commented off the rest of this message. |
|
@garyverhaegen-da Also, I would be happy to get on a call with you about this, if that might help. |
Can you give me the exact syntax for the NIX_CONFIG option? I'm not very familiar with Nix and the naive |
|
I think this is the smallest I can make it: #!/usr/bin/env bash
set -euo pipefail
DIR="$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
cd "$DIR"
./ad-hoc.sh create ubuntu
source .envrc.private
trap "./ad-hoc.sh destroy $MACHINE" EXIT
ssh="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=$(mktemp)"
while ! $ssh gary@$IP "echo connected" 2>/dev/null; do sleep 1; done
($ssh gary@$IP <<'EOF'
bash <(curl -sSfL https://releases.nixos.org/nix/nix-2.18.0/install)
source $HOME/.nix-profile/etc/profile.d/nix.sh
cat <<'REPRO' > repro.nix
let
system = builtins.currentSystem;
src = builtins.fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/9a82a9b5248919805a2400266ebd881d5783df2a.tar.gz";
sha256 = "142x1zq3cjadgmvfv0paydlq268pfinllqpq2vl0vxwdiq2nr9iz";
};
pkgs = import src {};
flatten = builtins.concatMap (x: if builtins.isList x then x else [x]);
env = pkgs.buildEnv {
name = "posix-toolchain";
paths = flatten [ pkgs.stdenv.initialPath ];
};
cmd_glob = "${env}/bin/*";
in
{
semver = pkgs.callPackage (
{ lib, stdenv, fetchFromGitHub }:
stdenv.mkDerivation rec {
version = "7cd86658";
name = "semver-tool-${version}";
src = fetchFromGitHub {
inherit name;
owner = "fsaintjacques";
repo = "semver-tool";
rev = version;
sha256 = "1v70dgp5yl4di90p8gzbj97zylgc9q971ds5g84id78c2fh3xh28";
};
phases = [ "unpackPhase" "installPhase" ];
installPhase =
''
mkdir -p $out/bin
cp $src/src/semver $out/bin/
patchShebangs $out/bin/semver
'';
}) {};
repro = pkgs.runCommand "repro" {}
''
echo ${cmd_glob}
'';
}
REPRO
nix-build repro.nix -A "semver"
nix-build repro.nix -A 'repro'
EOF
) 2>&1 | grep -oP 'path .* is not valid'At this point everything I can think of either fails in another way or succeeds. |
roberth
changed the title
|
same issue here, I was able to fix it as follows: ❯ sudo nixos-rebuild switch --flake .
warning: Git tree '/home/homeserver/nixos-config' is dirty
building the system configuration...
warning: Git tree '/home/homeserver/nixos-config' is dirty
error: path '/nix/store/wjizx94ksgs39haljg9pn2yinr5ic9az-bash-interactive-5.2-p21-doc' is not valid
❯ nix copy --from https://cache.nixos.org /nix/store/wjizx94ksgs39haljg9pn2yinr5ic9az-bash-interactive-5.2-p21-doc
❯ sudo nixos-rebuild switch --flake .
warning: Git tree '/home/homeserver/nixos-config' is dirty
building the system configuration...
warning: Git tree '/home/homeserver/nixos-config' is dirty
error: path '/nix/store/1bv944c4z7f3d62j462i184aj5lv9nqn-bash-interactive-5.2-p21-info' is not valid
❯ nix copy --from https://cache.nixos.org /nix/store/1bv944c4z7f3d62j462i184aj5lv9nqn-bash-interactive-5.2-p21-info
❯ sudo nixos-rebuild switch --flake .
warning: Git tree '/home/homeserver/nixos-config' is dirty
building the system configuration...
warning: Git tree '/home/homeserver/nixos-config' is dirty
error: path '/nix/store/74jgj1g3sab05jyp7hyppp777cpzjgs3-gnugrep-3.11-info' is not valid
❯ nix copy --from https://cache.nixos.org /nix/store/74jgj1g3sab05jyp7hyppp777cpzjgs3-gnugrep-3.11-info
❯ sudo nixos-rebuild switch --flake .
warning: Git tree '/home/homeserver/nixos-config' is dirty
building the system configuration...
warning: Git tree '/home/homeserver/nixos-config' is dirty
error: path '/nix/store/xg2z6k8zjm2r4xyk8mzycpz09nxv2klc-findutils-4.9.0-info' is not valid
❯ nix copy --from https://cache.nixos.org /nix/store/xg2z6k8zjm2r4xyk8mzycpz09nxv2klc-findutils-4.9.0-info |
|
If you want to
|
|
I have another reproduction of what I believe to be this issue, on Nix 2.18.1. In https://github.com/a-h/nix-copy I've got scripts to set up two NixOS VMs - The The first command is
Once the VMs are stared, the Export package to diskFirst, I SSH onto the nix copy --to file://$PWD/hello nixpkgs#hello --extra-experimental-features nix-command --extra-experimental-features flakesCopy from source to target using scpNext, I copy the results via SCP to the [adrian@nixos:~]$ scp -r ./hello adrian@192.168.122.182:/home/adrian/hello
The authenticity of host '192.168.122.182 (192.168.122.182)' can't be established.
ED25519 key fingerprint is SHA256:O8ltjoGolRWGEFxQV4dK+RktPvTt347gqV8s/QfKA+0.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.122.182' (ED25519) to the list of known hosts.
(adrian@192.168.122.182) Password:
ji01n9vinnj22nbrb86nx8a1ssgpilx8.narinfo 100% 606 581.0KB/s 00:00
i93s7xxblavsacpy82zdbn4kplsyq48l.narinfo 100% 567 5.6MB/s 00:00
9y8pmvk8gdwwznmkzxa6pwyah52xy3nk.narinfo 100% 659 7.2MB/s 00:00
ldrslljw4rg026nw06gyrdwl78k77vyq.narinfo 100% 513 5.6MB/s 00:00
zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm.narinfo 100% 600 6.7MB/s 00:00
12116yvlqh0sszlf6ipagkivxgh4ybn15d7qynvl34k87bmwkyv6.nar.xz 100% 49KB 95.4MB/s 00:00
168qxfl2rswcwbpvajr43r7s2fxan4lk69kyf7wasffga1ava9g8.nar.xz 100% 6357KB 100.9MB/s 00:00
0crc324g4mk9qv2kawr3w0rklvix854m7iarg8z848pibm3sxjfv.nar.xz 100% 87KB 197.6MB/s 00:00
1qi9kgysh7rpfnj20zxiys6xg15265ws0sc5kybmw1zdj8asc37j.nar.xz 100% 50KB 198.3MB/s 00:00
1rm2gqcly43l1mnd7iwyhslcfxnlg91y5c7y49y8dww1qwl0lsyp.nar.xz 100% 402KB 366.1MB/s 00:00
nix-cache-info 100% 21 206.8KB/s 00:00 Get the store path on the source machineWith the data copied to the target machine, I can print out the path. For some reason, there's no newline. [adrian@nixos:~]$ nix path-info nixpkgs#hello --extra-experimental-features nix-command --extra-experimental-features flakes
evaluating derivation 'flake:nixpkgs#hello'/nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1SSH into target machine and import the results of nix copyNext, I exit the connection with [adrian@nixos:~]$ exit
logout
Connection to 192.168.122.175 closed.
(nix:nix-shell-env) bash-5.2$ ssh adrian@192.168.122.182
(adrian@192.168.122.182) Password: Then, I try to run the nix copy operation to add the SCP'd files to the store. [adrian@nixos:~]$ nix copy --all --no-check-sigs --from file://$PWD/hello --extra-experimental-features nix-command --extra-experimental-features flakes
error: path '/nix/store/ji01n9vinnj22nbrb86nx8a1ssgpilx8-libidn2-2.3.4' is not validGot unexpected errorAs seen, I got the "error: path '/nix/store/ji01n9vinnj22nbrb86nx8a1ssgpilx8-libidn2-2.3.4' is not valid". Why does SSH work?If I log on to ssh adrian@192.168.122.175
[adrian@nixos:~]$ nix copy --to ssh-ng://192.168.122.182 nixpkgs#hello --extra-experimental-features nix-command --extra-experimental-features flakes
(adrian@192.168.122.182) Password: Then... on the target... (nix:nix-shell-env) bash-5.2$ ssh adrian@192.168.122.182
(adrian@192.168.122.182) Password:
Last login: Wed Jan 10 12:57:10 2024 from 192.168.122.1
[adrian@nixos:~]$ nix shell /nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1 --extra-experimental-features nix-command --extra-experimental-features flakes
[adrian@nixos:~]$ hello
Hello, world!So, it's interesting that the Code |
|
I gave @solidsnakedev's workaround a try to help debug the issue further. I noticed that it is possible to download from the cache to disk, and restore from disk on the target machine. So, I reproduced the issue, having copied the package from But if I download it from the Nix cache to disk... [adrian@nixos:~]$ nix copy --from https://cache.nixos.org /nix/store/ldrslljw4rg026nw06gyrdwl78k77vyq-xgcc-12.3.0-libgcc --to file://$PWD/libgcc --extra-experimental-features nix-command Then from disk into the cache... [adrian@nixos:~]$ nix copy --all --no-check-sigs --from file://$PWD/libgcc --extra-experimental-features nix-command --extra-experimental-features flakesThe operation succeeds: [adrian@nixos:~]$ nix copy --all --no-check-sigs --from file://$PWD/hello --extra-experimental-features nix-command --extra-experimental-features flakes Was the narinfo or NAR file corrupted during transfer?My first thought was that perhaps the scp operation didn't work, so I compared the narinfo files, and the one received from the In addition, the NAR files themselves are identical. I think this shows that the problem doesn't seem to be caused by the download or transfer of the archives. So what else could be causing this? |
Reproducible bisectionNow that I have a reproducible testing process, I noticed that the nixpkgs version was changing between each run, and that I was using a recent commit, so I tried with [adrian@nixos:~]$ nix copy --to file://$PWD/hello github:NixOS/nixpkgs/23.11#hello --extra-experimental-features nix-command --extra-experimental-features flakesSince it was working in 23.11, and not in the latest master branch, I decided to hunt it down. I got all the commits since 23.11 on the main branch with There had been 13,269 commits since the latest, so I had to do 13 checks to find the exact commit when it started to break. So I tracked it down to here. Why on earth would NixOS/nixpkgs@67fc0e51da63 cause a |
Reproduction in Nix 2.19.2Since the workaround was apparently to use Nix 2.18.1, and I was able to reproduce the issue in it, I decided to check if it had been fixed in a subsequent version of Nix accidentally. I updated the reproduction repo to use 2.19.2 in a-h/nix-copy@e855ecb and then created two new virtual machines - 192.168.122.153 (source) and 192.168.122.152 (target). |
|
@roberth - I would appreciate your thoughts on how to proceed. @'ing you because it says to in your profile. 😁
But the commit doesn't seem to make sense as the cause - I can't see how a minor change to a Rust package would result in Any ideas? |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tiny-nixos-virtualbox-appliance/38145/3 |
|
Reading through the comments above, I noticed that there was a suggestion that it worked in Nix 2.17, but it doesn't. |
|
The Nix copy output does contain everything required to restore the store, but it probably isn't doing it in the right order. The store that's being copied from the source passes verification. And, the Including recursively. Here's the graph of packages produced by
From the graph, it's clear that the order of installation must be This is exactly the checking order I see in the logs above. However, The original logs aren't very helpful, because instead of I don't know what it's supposed to be doing, but it looks like it's releasing the glibc lock too early to me. Shouldn't it be holding the lock until all dependencies of Reading through Lines 1087 to 1169 in e6e160a Does that help at all? |
|
Since all of the paths are actually available on disk, you can copy them one at a time with a shell script without having to go to the Internet to fetch them again with this (assumes nix-export is the folder containing the results of for x in `grep StorePath nix-export/*.narinfo | awk '{print $2}'`; do nix copy $x --from file://$PWD/nix-export/ --offline; done |
Describe the bug
On CI, we were seeing this problem:
This started to happen around the time when nix 2.18.0 was released. Downgrading to 2.17.0 has resolved this problem.
Steps To Reproduce
git clone https://github.com/digital-asset/daml.gitcd damlgit checkout 662a4417912df90ba9d9a99817b8ad9703480d06# not really needed, also fails for commits from 2021bash <( curl -sSfL https://nixos.org/nix/install ) --no-daemonpath_invalid.nix:NIX_PATH=nixpkgs=$DADE_NIXPKGS nix-build path_invalid.nixExpected behavior
I would expect the nix-build command to succeed.
nix-env --versionoutputAdditional context
I have tracked down the error message to
nix/src/libstore/store-api.cc
Line 727 in 57eb62d
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: