NAR hash mismatch in flake input

Help
1

Hi, I have a few projects setup as nix flakes and everything has been going very smoothly for the past few months until today when I ran into an issue I haven’t been able to resolve. On a CI job that builds the project, I’m seeing a NAR hash error for one of the flake inputs (which is another flake/repo that I’m in control of). The error is:

error: NAR hash mismatch in input 'git+ssh://git@{URL}?ref={REF}&rev={REV}' (/nix/store/9rlg5jbjmxf4czb8yzqf6z3a4lzz3wpk-source), expected 'sha256-1BEMZQ6U1hDb5sxVbiio/BCAtapmhjJBIQSn5D0peJw=', got 'sha256-RpY/JLE1MK2lOoiPZqzvMrpHDa+cA4Paiy953VhbtYE='

It’s odd in that it just started happening and seems to related to state on the CI runner (re-running the CI job for commits that have previously run successfully is resulting in this error), it’s still currently working locally on my machine, as well as on my machine from docker using nixpkgs/cachix-flakes:latest which is the image the CI job runs from.

Does anyone have any ideas about why this might happen? I’ve been having trouble getting to the bottom of it.

Thank you in advance for any help

EDIT: Some additional info:

  • Job is being run with GitLab CI using nixpkgs/cachix-flakes:latest docker image
  • nix --version: nix (Nix) 2.4pre20210707_02dd6bb

EDIT2:
I’m thinking this is potentially a reproducibility problem but I’m not sure where that would be coming from. It seems like /nix/store/9rlg5jbjmxf4czb8yzqf6z3a4lzz3wpk-source is even different since this directory doesn’t exist on my local machine after building.

2

CI , which CI, there are many CI’s, be good to know which one it is? the nixos builtin one hydra perhaps?

3

I’m using GitLab CI with the job running from docker image: nixpkgs/cachix-flakes:latest. Added to EDIT section of main post

4

I fixed this temporarily by omitting the NAR hash from the flake.lock file, but still haven’t figured out why the CI environment is coming up with a different hash than local host and docker environments.

5

hmm, interesting.

can you post your flake and lock file ?

is it the source repo it’s having trouble with, is the CI doing something bizzare with that?

interesting problem.

6

Any chance you could manually check the contents of that store path? I wonder if GitHub is serving a different file due to an authentication error or such, perhaps an expired key?

1 Like
7

In my case, I was getting a similar error trying to build a flake with the following input, after doing a garbage collection:

inputs.hugo-theme-terminal = {
    url = "https://github.com/panr/hugo-theme-terminal";
    flake = false;
  };

error: NAR hash mismatch in input 'https://github.com/panr/hugo-theme-terminal?narHash=sha256-9yVlglChejtGt4RvJAIdZirDEXnnRczECTna%2f4JMasU=' (/nix/store/r1h0ga78r05z3xjihq4q0ayfl0gj3738-source), expected 'sha256-9yVlglChejtGt4RvJAIdZirDEXnnRczECTna/4JMasU=', got 'sha256-eMHTDbv/T4+viT3oRLQlXzB7tJqcMrhCEYgRpp980+g='

After changing to:

  inputs.hugo-theme-terminal = {
    url = "github:panr/hugo-theme-terminal";
    flake = false;
  };

Then I did the build without errors.

flake.lock before:

    "hugo-theme-terminal": {
      "flake": false,
      "locked": {
        "narHash": "sha256-9yVlglChejtGt4RvJAIdZirDEXnnRczECTna/4JMasU=",
        "type": "file",
        "url": "https://github.com/panr/hugo-theme-terminal"
      },
      "original": {
        "type": "file",
        "url": "https://github.com/panr/hugo-theme-terminal"
      }
    },

After:

    "hugo-theme-terminal": {
      "flake": false,
      "locked": {
        "lastModified": 1658296851,
        "narHash": "sha256-6x+UmKHE56aySQqVRaZn/Euwz9QBCG/U+34Ec8FSEI0=",
        "owner": "panr",
        "repo": "hugo-theme-terminal",
        "rev": "161096273113101926c90e6de31a955bdc66c235",
        "type": "github"
      },
      "original": {
        "owner": "panr",
        "repo": "hugo-theme-terminal",
        "type": "github"
      }
    },

Could be something similar?

1 Like
8

did you make a commit to GitHub - panr/hugo-theme-terminal: A simple, retro theme for Hugo , after you generated the lock file?

9

did you make a commit to GitHub - panr/hugo-theme-terminal: A simple, retro theme for Hugo , after you generated the lock file?

I’m not the owner of the repo, but no, there wasn’t a commit between changing the input from http to git (and recreating the lock file) in the project (afaik).

10

hmmmmm, i’m pretty sure something got committed to the repo, thus changing the hash.

or even a force push over the entire repo, that can be very bad for reproducible.

unless there is some bug i’m not aware of here.

11

I think I’m seeing something similar:

I’m also seeing the NAR hash mismatch locally on multiple machines. So far I’ve only ever observed it occurring on this one repo. Could it be something about how the repo is configured in github, resulting in some extra metadata that gets sent? Very confused at this point o_O

12

In my case the issue turned out to be export-subst in .gitattributes of the input repo (used e.g. by python-versioneer). Looking at the store path of the input, I found the string

(HEAD -> main)

indicating that the current commit is the HEAD of the main branch, which is definitely not reproducible. I posted a minimal reproduction here: How to deal with unstable flake input hashes due to export-subst?

1 Like