From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Boostrap tar cannot exec xz Date: Mon, 03 Oct 2016 18:06:09 +0200 Message-ID: <87a8ela03y.fsf@gnu.org> References: <7tzimpmyss.fsf@gmail.com> <87eg41kv66.fsf@gnu.org> <7th98xnjq0.fsf@gmail.com> <87k2dsi80c.fsf@gnu.org> <7th98tew22.fsf@gmail.com> 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]:34406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br5kv-0001PI-MF for guix-devel@gnu.org; Mon, 03 Oct 2016 12:06:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1br5kt-00028L-He for guix-devel@gnu.org; Mon, 03 Oct 2016 12:06:16 -0400 In-Reply-To: <7th98tew22.fsf@gmail.com> ("Carlos =?utf-8?Q?S=C3=A1nchez?= de La Lama"'s message of "Mon, 03 Oct 2016 09:22:29 +0200") 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" To: Carlos =?utf-8?Q?S=C3=A1nchez?= de La Lama Cc: guix-devel@gnu.org csanchezdll@gmail.com (Carlos S=C3=A1nchez de La Lama) skribis: > Hi Ludo, > >> So apparently, tar 1.27 did not execute xz via /bin/sh, but current tar >> does not either: >> > > It does not when extracting, but seems to do when compressing (which is > what causes my bootstrapping problem). Your experiment yields similar > results here: [...] > However, when *compressing*, it needs /bin/sh. > > $ touch ~/foo > $ strace -f -e execve /gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstr= ap-binaries-0/bin/tar cvfa ~/foo.tar.xz ~/foo > execve("/gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstrap-binaries-0/= bin/tar", ["/gnu/store/2g5cgcv8fsmaps528jn6n"..., "cvfa", "/home/csanchez/f= oo.tar.xz", "/home/csanchez/foo"], [/* 25 vars */]) =3D 0 > /gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstrap-binaries-0/bin/tar:= Removing leading `/' from member names > /home/csanchez/foo > Process 1615 attached > [pid 1615] execve("/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.= 42/bin/sh", ["/gnu/store/eeeeeeeeeeeeeeeeeeeee"..., "-c", "xz"], [/* 25 var= s */]) =3D -1 ENOENT (No such file or directory) > tar (child): xz: Cannot exec: No such file or directory > tar (child): Error is not recoverable: exiting now > [pid 1615] +++ exited with 2 +++ > --- SIGCHLD {si_signo=3DSIGCHLD, si_code=3DCLD_EXITED, si_pid=3D1615, si_= uid=3D1000, si_status=3D2, si_utime=3D0, si_stime=3D0} --- > /gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstrap-binaries-0/bin/tar:= Child returned status 2 > /gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstrap-binaries-0/bin/tar:= Error is not recoverable: exiting now > +++ exited with 2 +++ > > This is what makes -make-4.2.tar.xz-builder to fail, stopping the > bootstrap. Ooh, and the Tar commit Danny mentions is a post-1.27 change, which is why our other bootstrap binaries don=E2=80=99t have this problem, is that r= ight? If so, you have two options: using Tar=C2=A01.27 in =E2=80=98static-binarie= s=E2=80=99, or using a Tar variant with a patch along the lines of what Danny suggests. Do whichever is easier. >>> Another option that just came to my mind is replacing all the nuked >>> store referenced in the static binaries with references to the unpacked >>> store path after extraction. As the nuked references can be easily >>> identified by the "eeeeee..." fake path, this should be doable. >> >> That=E2=80=99s not doable because we don=E2=80=99t know the hash in adva= nce. > > When creating the tarball, we don't know the hash it will have when > extracted, so the references are nuked. But when creating the package > from the tarball, in the bootstraping machine (my linux-powerpc in this > case), couldn't we "un-nuke" the references, making them point to the > store path we just created? Forget about it. :-) Ludo=E2=80=99.