[Nix-dev] Chroot builds and NSS modules

Eelco Dolstra e.dolstra at tudelft.nl
Tue Apr 8 19:35:49 CEST 2008


Hi,

Ludovic Courtès wrote:

>> Log:
>> * Ignore services in nsswitch.conf that cannot be found (like
>>   "mdns4_mininal" on Ubuntu).  This is a fix for NIXPKGS-79.  It
>>   doesn't *quite* fix the problem in all cases (there might be people
>>   actually using mDNS; they should just run the "nscd" daemon) but at
>>   least it should keep curl from failing in Nixpkgs downloads.
> 
> (I'm assuming this change relates to
> http://thread.gmane.org/gmane.linux.distributions.nixos/384 ).
> 
> That seems very hackish.
> 
> I think the problem (DNS lookup failures in the chroot) stems from the

No, it's not about build problems in the chroot but about this bug:

   http://bugs.strategoxt.org/browse/NIXPKGS-79

I.e. packages that link against the Nixpkgs Glibc cannot do DNS lookups on 
Ubuntu, because it has this line in /etc/nsswitch.conf:

   hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

This fails because "mdns4_minimal" can't be found and "NOTFOUND=return" causes 
Glibc to not continue to "dns".  This is actually a bug in Glibc: failure to 
load the service should cause an UNAVAIL error, not NOTFOUND (which means "the 
service says that the name doesn't exist").

So this is for people running Nix/Nixpkgs on Debian, it's not a problem on NixOS.

> fact that the chroot sees a `resolv.conf' that specifies NSS modules
> that aren't mapped in the chroot.  I can think of two solutions:
> 
>   1. The best solution IMO would be to selectively bind-mount all NSS
>      modules into the chroot and somehow make sure that they are in the
>      lib search path of `curl' and other applications.
> 
>   2. A simpler solution would be to provide the chroot with a
>      `resolv.conf' that does not refer to any external NSS module.
> 
> Now, I fail to see where the chroot gets its `/etc/resolv.conf' from.
> `DerivationGoal::startBuilder ()' in `libstore/build.cc' lists only
> `/dev', `/proc', and `/nix/store' as the paths that are mounted by
> default in the chroot.  So where's `/etc'?  Or is the above explanation
> incorrect?

No, you're right.  When I implemented the chroot option I didn't consider DNS 
resolution.  So fetchurl derivations currently just fail in a chroot.  But there 
is a simpler solution: we could just *not* execute fixed-output derivations like 
fetchurl in a chroot.  ("Fixed output derivations" are derivations that specify 
the outputHash attribute, i.e. the cryptographic hash required for the output.) 
  Since they have a guaranteed output anyway, we don't really care about their 
purity, unlike normal derivations.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/



More information about the nix-dev mailing list