l...@gnu.org (Ludovic Courtès) skribis: > To see what ‘if_indextoname’ returns in our chroot, I tried this: > > (use-modules (guix store) (guix derivations) (guix monads) (guix utils) > (gnu packages guile)) > > (define builder '(begin > (use-modules (system foreign) > (rnrs bytevectors) > (srfi srfi-1)) > > (let () > (define index->name > (let* ((ptr (dynamic-func "if_indextoname" > (dynamic-link))) > (proc (pointer->procedure '* ptr > (list unsigned-int > '*)))) > (lambda (index) > (let* ((bv (make-bytevector 256)) > (ret (proc index > (bytevector->pointer bv)))) > (if (null-pointer? ret) > #f > (pointer->string ret)))))) > (call-with-output-file (assoc-ref %outputs "out") > (lambda (port) > (write (zip (map index->name (iota 10)) > (iota 10)) > port)))))) > > (let* ((mdrv (derivation-expression "iface" (%current-system) builder '())) > (s (open-connection)) > (drv (run-with-store s mdrv))) > (pk drv) > (build-derivations s (list drv))) > > That returns a series of #f (whereas outside of the chroot BUILDER > returns '("lo" "eth0" "wlan0").)
On IRC Mark noted that nix/libstore/build.cc sets up ‘lo’ in the chroot, so that one should appear. It turns out that it does indeed appear, but its index is incremented by one each time guix-daemon starts a child process. Thus, when doing a whole series of builds in a row, or if the machine has been up long enough, you may end up with an index greater than 255, leading to the assertion failure in ‘find_ifname_and_index’ (this explains why Hydra was hitting it and not my laptop, for instance.) If the explanation is correct, 93a3d8f fixes the problem. Thanks, Ludo’.