From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: MIPS64/N64 support Date: Wed, 09 Oct 2013 12:39:37 +0200 Message-ID: <87zjqivic6.fsf@gnu.org> References: <87vc2o4qwc.fsf@gnu.org> <87d2opy6qa.fsf@gnu.org> <87r4d577ab.fsf@karetnikov.org> <87zjrswzin.fsf@gnu.org> <87hadygxe8.fsf@karetnikov.org> <87mwnq470w.fsf@gnu.org> <87y5791h9f.fsf@karetnikov.org> <87eh907psx.fsf@gnu.org> <87li37z967.fsf@karetnikov.org> <8761ub143g.fsf@gnu.org> <87k3iqa71l.fsf@karetnikov.org> <87k3iqhrh5.fsf@gnu.org> <877ge3c8lf.fsf@karetnikov.org> <874n96qed3.fsf@gnu.org> <878uyfiwr1.fsf@karetnikov.org> <87siwniwka.fsf@gnu.org> <8738onkyi9.fsf@karetnikov.org> <87bo3asfx6.fsf@karetnikov.org> <87bo309auv.fsf@netris.org> <87k3hox43s.fsf@gnu.org> <87zjqj74d7.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTrG4-00073W-UQ for guix-devel@gnu.org; Wed, 09 Oct 2013 06:44:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTrFw-0004Oo-Vx for guix-devel@gnu.org; Wed, 09 Oct 2013 06:44:48 -0400 Received: from hera.aquilenet.fr ([141.255.128.1]:33053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTrFw-0004Og-Ke for guix-devel@gnu.org; Wed, 09 Oct 2013 06:44:40 -0400 In-Reply-To: <87zjqj74d7.fsf@netris.org> (Mark H. Weaver's message of "Tue, 08 Oct 2013 19:03:00 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, Thanks for the thorough analysis. Mark H Weaver skribis: > My suspicion is that my kernel (linux-libre-2.6.39.1) and Guix's glibc > are not playing nicely together. However, Guix's glibc was configured > to support kernels as early as 2.6.30, and the same 'pwd' executable > that fails within 'guix-daemon' seems to work outside of it, even when > run within a chroot. Could it have something to do with bind mounts? The method =E2=80=98DerivationGoal::initChild()=E2=80=99 in libstore/build.= cc is what sets up the chroot environment. The /tmp/nix-build-* directory is itself bind-mounted in the chroot. So: > * The initial stat(".") syscall reports inode 7274551, which corresponds > to "/tmp/nix-build-make-boot0-3.82.drv-0/make-3.82", as expected. >=20 > * stat("/") reports inode 1073173, which looks WRONG. >=20 > * stat("..") reports inode 7274550, which corresponds to > "/tmp/nix-build-make-boot0-3.82.drv-0", as expected. >=20 > * reading the contents of ".." reports inode numbers that all look > correct, including "make-3.82" with inode 7274551, the same as ".". > Thus 'pwd' concludes that its result will end with "/make-3.82". >=20 > * stat("../..") reports inode 1073174, which looks WRONG. >=20 > * reading the contents of "../.." reports inode numbers that all look > WRONG: >=20 > "nix-build-make-boot0-3.82.drv-0" with inode 1073325 > ".." with inode 1073173 > "." with inode 1073174 >=20 > None of these match the inode of "..", so 'pwd' fails. Could it be that stat("/") reports the inode of the underlying root? Can you try this in a REPL (assuming the bootstrap Guile works): (use-modules (guix store) (guix monads) (guix utils) (gnu packages bootstrap) (guix packages)) (define (test) (derivation-expression "test" (%current-system) '(and (equal? (pk 'root (stat:ino (stat "/"))) (pk 'dotdotdotdot (stat:ino (stat "../..")))) (equal? (pk 'dotdot (stat:ino (stat ".."))) (pk 'tmp (stat:ino (stat "/tmp")))) (equal? (pk 'dot (stat:ino (stat "."))) (pk 'tmpdir (stat:ino (stat "/tmp/nix-build-t= est.drv-0")))) (mkdir %output)) '())) =20=20 =20=20 (define s (open-connection)) (define drv (run-with-store s (test) #:guile-for-build (package-derivation s %bootstrap-guil= e))) (build-derivations s drv) If that test fails, that most likely indicates a bug in Linux-Libre. BTW, were you able to run (some of) =E2=80=98make check=E2=80=99? Thanks, Ludo=E2=80=99.