12

How do I diagnose a nix-build failing?

Currently I see output as:

nix build -v
warning: dumping very large path (> 256 MiB); this may run out of memory
building '/nix/store/fdrm6kbm68vld3bhfjizv684ck725lyf-blog.drv'...
builder for '/nix/store/fdrm6kbm68vld3bhfjizv684ck725lyf-blog.drv' failed with exit code 1; last 5 log lines:
  unpacking sources
  unpacking source archive /nix/store/s7r5vlvp49ad6a9d5hqhsiaxw691iyhf-Blog
  source root is Blog
  patching sources
  configuring
[0 built (1 failed), 0.0 MiB DL]
error: build of '/nix/store/fdrm6kbm68vld3bhfjizv684ck725lyf-blog.drv' failed

I'd expect to find some logs / errors of why it failed to build?

Following from https://stackoverflow.com/a/47264375/1663462:

I've tried adding build-cache-failures = true; to the default.nix however I still see no output from:

nix-store --read-log

And nix-store --query-failed-paths results in:

error: no operation specified
Try 'nix-store --help' for more information.
Chris Stryczynski
  • 5,178
  • 5
  • 40
  • 80

4 Answers4

5

see also:

instead of nix-build

nix-build -E '
  with import <nixpkgs> { };
  callPackage ./default.nix { }
'

you can run nix-shell to enter the build environment

nix-shell -E '
  with import <nixpkgs> { };
  callPackage ./default.nix { }
'

and then run the build phases

cd $(mktemp -d)
unpackPhase
cd $sourceRoot

configurePhase

buildPhase # most time is spent here

checkPhase
installPhase
fixupPhase

in this build environment, you can

  • find the cause of build errors (what build phase is failing?)
  • modify the build commands, for example redefine the buildPhase: run type buildPhase to print the old phase, copy the old phase, modify the phase, paste the new phase
  • run the modified build commands. this can be faster than a full rebuild

note: builders can execute different build phases. the actual build phases are stored in the $phases variable, see echo $phases

bonus: large projects recompile faster with a warm cache ("dirty build")

milahu
  • 172
  • 1
  • 8
  • I'm not sure how this relates to the question? – Chris Stryczynski Oct 16 '21 at 15:35
  • added more text from the nixos wiki. clearer now? – milahu Oct 16 '21 at 16:33
  • Sorry I'm a few years late, but yes this finally does make sense now though I think it's missing some context to highlight that these commands or phases relate to building a derivation. It would be useful to know that these commands are likely exactly the ones being run indirectly via `nix-build` and hence you get the full output with no truncation or aggregation. – Chris Stryczynski Jul 28 '23 at 11:15
  • `nix-build` can execute different build phases, for example in `python3.pkgs.buildPythonPackage`. the actual build phases are stored in the variable `$phases`, so in the nix-shell, see `echo $phases`. docs: [Building a stdenv package in nix-shell](https://github.com/NixOS/nixpkgs/blob/master/doc/stdenv/stdenv.chapter.md#building-a-stdenv-package-in-nix-shell-sec-building-stdenv-package-in-nix-shell), issues: [docs: fix nix-shell commands](https://github.com/NixOS/nix/pull/7849), [docs: Building a stdenv package in nix-shell](https://github.com/NixOS/nixpkgs/pull/216650) – milahu Jul 28 '23 at 11:54
4

Reading log should work. Did you specify the derivation? /nix/store/fdrm6kbm68vld3bhfjizv684ck725lyf-blog.drv

Vladimír Čunát
  • 1,258
  • 7
  • 11
3

There is a --debug option as well as a --print-build-logs option that can provide additional info.

Regarding the specific issue - it might be this bug: https://github.com/NixOS/nix/issues/2176

More information

https://nixos.org/releases/nix/nix-1.7/manual/#idm47361538723648 (link now broken... )

Chris Stryczynski
  • 5,178
  • 5
  • 40
  • 80
  • 1
    From the link: `At the beginning of each phase, the set of all shell variables is written to the file env-vars at the top-level build directory. This is useful for debugging: it allows you to recreate the environment in which a build was performed. For instance, if a build fails, then assuming you used the -K flag, you can go to the output directory and “switch” to the environment of the builder` – Ben Creasy Sep 23 '19 at 01:28
  • 1
    thank you! `--debug` is exactly what I was looking for :) – hraban Jun 23 '22 at 07:40
0

Adding breakpointHook to nativeBuildInputs (or buildInputs) of the failing derivation is also a powerful technique ― it allows you to connect with cntr and explore the environment as it was at the point that the derivation's build failed.

Mentioned here in the NixOS Discourse:

I want to also add a few details regarding breakpointHook. It is a really powerful debug hook by @Mic92.

It is enough to put pkgs.breakpointHook into your buildInputs to get it working. In the case of a failure there is an exact “connection” command printed out to the console. You can use this command (cntr) to attach a shell into the build environment. To use it you have to be able to run sudo along with cntr (so you should install cntr package before ;-)).

You can find more interesting details in the @Mic92 NixCon presentation: Jörg 'Mic92' Thalheim - About Nix sandboxes and breakpoints (NixCon 2018)

Here's a link to the relevant section of the manual: https://nixos.org/manual/nixpkgs/stable/#breakpointhook

Robert K. Bell
  • 101
  • 1
  • 2