Re: Boostrap tar cannot exec xz

[Ludovic Courtès]

address@hidden (Carlos Sánchez 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-bootstrap-binaries-0/bin/tar cvfa 
> ~/foo.tar.xz ~/foo
> execve("/gnu/store/2g5cgcv8fsmaps528jn6np241mkyyidm-bootstrap-binaries-0/bin/tar",
>  ["/gnu/store/2g5cgcv8fsmaps528jn6n"..., "cvfa", "/home/csanchez/foo.tar.xz", 
> "/home/csanchez/foo"], [/* 25 vars */]) = 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 vars */]) = -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=SIGCHLD, si_code=CLD_EXITED, si_pid=1615, si_uid=1000, 
> si_status=2, si_utime=0, si_stime=0} ---
> /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 <hash>-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’t have this problem, is that right?

If so, you have two options: using Tar 1.27 in ‘static-binaries’, 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’s not doable because we don’t know the hash in advance.
>
> 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’.