`nix registry pin nixpkgs/release-22.05` gives "NAR hash mismatch in input"

[pwaller]

Describe the bug

(Originally posted as NixOS/nixpkgs#180160, redirected here by @veprbl , thanks!)

nix registry pin nixpkgs/release-22.05 gives an error message NAR hash mismatch in input which is not clear how to action. I'm unclear on where the mismatched hashes are coming from. A garbage collect causes things to happen again (things get downloaded) but the error is repeatable.

Steps To Reproduce

Steps to reproduce the behavior:

1. nix registry pin nixpkgs/release-22.05
2. Observe output:

error: NAR hash mismatch in input 'github:NixOS/nixpkgs/release-22.05' (/nix/store/kpl6bxwjpirqpvsm98xw5hjfzg33zpcf-source), expected 'sha256-QEWkUBH4gu6ntNkF+9xIqDM22bto4PB+LSHIL6oWFpM=', got 'sha256-1aMu67m+orlGxVwfiX3RxTEVFoq/RmKa/L5u9zU3UNQ='

Expected behavior

I don't know if I'm using this command incorrectly. My intent is to pin references to the nixpkgs/release-22.05 to the current commit, so that I may avoid constantly freshening it, and use nixpkgs/release-22.05. If there is a hash mismatch somewhere, it would be good if it could be clear where the mismatched hashes are coming from. I see that one of them is /nix/store/kpl6bxwjpirqpvsm98xw5hjfzg33zpcf-source, but what's the other reference, and why do they mismatch? Does it mean my local content is bad, or something else?

I was able to delete the 'bad' path using nix-store --query --roots to identify what was keeping it alive. But then the issue is again repeatable. It reproduces on two machines that I've tried and with nixpkgs/release-21.11.

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

nix-info -m
 - system: `"aarch64-linux"`
 - host os: `Linux 5.15.49, NixOS, 22.05 (Quokka), 22.05.20220702.8b9c011`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[thufschmitt]

Mh... Maybe the fetcher cache that Nix uses internally is somehow screwed-up. What happens if you nuke (or just temporarily move) ~/.cache/nix?

[pwaller]

Nuking the eval cache doesn't seem to help, and the issue seems repeatable on different machines and different users. I take it the command as given doesn't reproduce the issue for you?

[thufschmitt]

Nah it doesn't pinning works fine for me (both on 2.9.1 and 2.8.1). I only tried on x86_64 darwin, though It would be surprising if the system changed anything here

[pwaller]

I tried to repro on aarch64-darwin, and it doesn't repro there. I repro'd on aarch64-linux and x86_64-linux though, and I repro'd with nix 2.9.1.

[thufschmitt]

Oh, so it is system-dependent 🤔
I'll try on a Linux box once I have one handy then, see what I can make of it

[cole-h]

FWIW, I was able to run nix registry pin github:nixos/nixpkgs/release-22.05 successfully on x86_64-linux. (Do note that it's not the exact same command, since I have my own local registry.)

[thufschmitt]

Just tried on a Linux machine, but the command succeeded (both with 2.8.1 and 2.9.1).

Anything in your registry that could explain the difference maybe? A custom entry for nixpkgs or something like that maybe

[pwaller]

Could it be this?

user   flake:nixpkgs github:NixOS/nixpkgs/05734e66dd9a7b62e505ba9b1395e378524018c8

[pwaller]

(I was interrupted while looking, so opted to send the message before I could test in case I couldn't get back to it)

Yes, if I move my .config/nix/registry.json out of the way the error doesn't happen any more.

[thufschmitt]

Ahah indeed, the pin seems to confuse Nix, and it apparently can't decide which version to use :)

$ nix registry pin nixpkgs github:NixOS/nixpkgs/05734e66dd9a7b62e505ba9b1395e378524018c8
$ nix registry pin nixpkgs/release-22.05                                                
error: NAR hash mismatch in input 'github:NixOS/nixpkgs/release-22.05' (/nix/store/rxmcf6b928xpi6lnnyhfcx6g2b5qxvph-source), expected 'sha256-jIo0uINeckIwbCrpeyUiUfRootlYvW3wyAhDP2jMua8=', got 'sha256-fTAsYM5Zc+57kaiHH7jRskls5YkKTyyQBBWv0BXF3XM='

Fwiw, I realise that it doesn't seem to be documented and there's apparently no cli interface to it either, but if you add "exact": true, to a registry entry, it won't try to use it for “sub-entries” (we're lacking a good terminology here :p ) and that won't trigger the bug. For example with the registry below, everything works fine:

{
  "flakes": [
    {
      "exact": true,
      "from": {
        "id": "nixpkgs",
        "type": "indirect"
      },
      "to": {
        "lastModified": 1656617302,
        "narHash": "sha256-jIo0uINeckIwbCrpeyUiUfRootlYvW3wyAhDP2jMua8=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "05734e66dd9a7b62e505ba9b1395e378524018c8",
        "type": "github"
      }
    }
  ]
}

[pwaller]

Yeah, I tried my best to understand, reading the docs and even the source, but the inference engine running on the meat computer in my head doesn't understand what's going on here. Why does this cause a NAR hash mismatch? Should it? I take it no.

[thufschmitt]

Nah it definitely shouldn't. I presume that what happens is that

• Having nixpkgs pinned (without exact set to true) means that anything below the nixpkgs “namepace” uses the pin. So for example if nixpkgs is pinned to github:myForkOf/nixpkgs then nixpkgs/abcde will resolve to github:myForkOf/nixpkgs/abcde.
• When running nix registry pin nixpkgs/something, Nix should
  1. Fetch the tip of whatever nixpkgs/something points to (and get its nar hash)
  2. Use that as the target of the pin to write it in the registry json file, along with the nar hash
• I suspect that when nixpkgs is pinned to a specific commit, pinning nixpkgs/something somehow gets Nix confused, so that it
  1. Fetch the tip of whatever nixpkgs/something points to (and get its nar hash)
  2. Use whatever nixpkgs points to as the target of the pin, and write it in the registry json file, along with the nar hash that has just been computed. Which obviously doesn't match since we're not pinning the right commit

So that's definitively a Nix bug (and a pretty weird one, that is)