I was trying to build a disk image and it failed with a hash mismatch. I can reproduce it with:
$ nix copy --to $PWD/foo nixpkgs#openssh
error: hash mismatch importing path '/nix/store/p15q75vmlkhvmjgdc18whrn690lkghls-openssh-9.1p1';
- Rebuilding it (
nix build nixpkgs#openssh --rebuild) made no difference.
- I can’t delete it (
nix store delete nixpkgs#openssh) “since it is still alive”.
How can I fix this?
What version of nixpkgs are you using? What is your version of Nix?
I can’t reproduce here.
I’m following nixos-22.11.
Now, after a restart, the problem got magically solved.
I got a similar error, but from a different command. (Just documenting here for archive / myself.)
I was building a NixOS VM and got this:
error: hash mismatch importing path '/nix/store/l2vgw2r8wf3xqbjjmrdxl338bbs9y852-dictd-dbs';
copying path '/nix/store/nzakqfsym2z7ladf3iav43q9a8xpp2vf-diffoscope-233-man' to 'local'...
error: build of '/nix/store/2xwkfcgy1r506ll8sbhwn9yz1xd8sdip-nixos-system-bf-laptop-23.05.git.bb8b573' failed
error: build of '/nix/store/hjid5ich8kq13jkzgmh1hljllsgnkbxs-nixos-disk-image.drv' on 'ssh://nix-remote-build@builder' failed: builder for '/nix/store/hjid5ich8kq13jkzgmh1hljllsgnkbxs-nixos-disk-image.drv' failed with exit code 1;
After some debugging, I think I know what happened.
- dictd-dbs was built independently on local host and on the remote builder (because I sometimes build stuff locally on both machines). But the derivation wasn’t reproducible and ended up with different content hashes on local machine vs remote builder. (That specific derivation was made reproducible/fixed in Sign in to GitHub · GitHub)
- The VM image derivation with the Nix store registration paths was instantiated on the local machine but built on the remote machine (where /nix/store/HASH-dict-dbs had differing content hash).
nix-store --load-db < registration failed on the remote builder with the above error.
Replying because I encountered this issue today.
If you see that error, it usually means your disk got corrupted. If that happened, there might be other store paths that are also facing this issue. So the first thing to do is to run
nix store verify --all --no-trust to get a list of all of the broken store paths.
Then for each of the broken store path, run
nix store repair <store-path>. Eg:
nix store repair /nix/store/l2vgw2r8wf3xqbjjmrdxl338bbs9y852-dictd-dbs.
The reason this surfaces during a closure copy is that Nix assembles back the NAR file to send over the wire, and compares its checksum with the one it got from cache.nixos.org (which is recorded in
/nix/var/nix/db/db.sqlite). And because of the disk corruption, the assembled NAR ends up with different content.