NixOS & Configuration

A fetched fixed-output source has a different hash

A fetcher output differs from its expected hash. Verify the pinned revision, artifact and hashing mode before accepting the newly reported digest.

On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • The build prints specified and got hashes for a fixed-output derivation.
  • A source URL or revision was edited without its matching hash.

Relevant environment

Nix fixed-output derivations such as fetchurl, fetchzip and fetchFromGitHub; hash mode is fetcher-specific.

Recognizable messages (synthetic examples)
error: hash mismatch in fixed-output derivation '/nix/store/00000000000000000000000000000000-source.drv':

The expected and returned content differ; the line does not establish why.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The upstream artifact or revision may have changed, or the URL may now return unintended content.
  • A flat file digest differs from the hash of unpacked recursive content; switching fetcher semantics can change the required hash.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace package.nix with the local derivation source; this reads it without downloading.

rg -n 'fetchurl|fetchzip|fetchFromGitHub|url|rev|hash|sha256' package.nix

Interpret the result: Compare URL/rev changes with the declared hash and fetcher type. An archive's raw checksum is not interchangeable with unpacked-content hashing.

Check 2

Replace the synthetic path with an existing .drv named in the failure; shows metadata and does not build it.

nix --extra-experimental-features nix-command derivation show /nix/store/00000000000000000000000000000000-source.drv

Interpret the result: Read outputHash, outputHashMode and source URL where present. Metadata confirms what was requested, not that the downloaded bytes are legitimate.

Evidence-guided next steps

Pin the verified artifact and matching hash

If the source change is intentional, verify the artifact against the upstream release or immutable commit and calculate the hash using the selected fetcher's documented mode. Update source reference and hash together.

Precautions: Blindly copying got accepts whatever was returned, including an unexpected replacement. Preserve the old artifact identity and digest.

Recovery / rollback: Restore the prior source URL/revision and hash together, then rebuild the previous package definition.

Did this solution help you?

Share this solution#

Recover an unexpectedly changed source

If the artifact changed without an intended upgrade, retain the mismatch evidence and use a verified immutable release or wait for the upstream or packaging correction. If the fetcher was changed, restore its former hashing semantics first.

Precautions: Deleting caches or weakening hashes does not establish authenticity. A temporary workaround must keep an expected digest.

Recovery / rollback: Revert the temporary source or fetcher selection after a verified upstream correction; preserve the known-good pin for recovery.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.