[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