[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Boostrap tar cannot exec xz

From: Ludovic Courtès
Subject: Re: Boostrap tar cannot exec xz
Date: Sat, 01 Oct 2016 14:11:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)


address@hidden (Carlos Sánchez de La Lama) skribis:

>> In ‘raw-build’ in bootstrap.scm, we run:
>>   xz -dc thing.tar.xz | tar xv
> If I have understood correctly the code, raw-build is only used for
> %bootstrap-guile. However, the problem arises when building make (I do
> not have access to that machine righg now, so I am unsure of the exact
> package). i guess one option would be to create bootstrap versions of
> all packages on which tar depends (most probably already exist) and use
> xz | tar on them, until the requirements for a new non-bootstrap tar
> build can be met.

The question is how ‘tar’ in the ‘bootstrap-binaries’ we use on other
arches differs from the one you just built.

--8<---------------cut here---------------start------------->8---
$ guix build bootstrap-binaries --fallback
address@hidden ~/src/guix$ 
tar (GNU tar) 1.27
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
$ strings 
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar |grep 
$ touch foo.tar.xz
$ strace -e execve -f 
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar xf 
 ["/gnu/store/zh914iy23h97fwskh12vl"..., "xf", "foo.tar.xz"], [/* 63 vars */]) 
= 0
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: This 
does not look like a tar archive
Process 28766 attached
[pid 28766] execve("/home/ludo/.guix-profile/bin/xz", ["xz", "-d"], [/* 63 vars 
*/]) = 0
xz: (stdin): File format not recognized
[pid 28766] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=28766, si_status=1, 
si_utime=0, si_stime=0} ---
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Child 
returned status 1
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Error 
is not recoverable: exiting now
+++ exited with 2 +++
--8<---------------cut here---------------end--------------->8---

So apparently, tar 1.27 did not execute xz via /bin/sh, but current tar
does not either:

--8<---------------cut here---------------start------------->8---
$ strace -e execve -f tar xf ~/src/guix/foo.tar.gz 
execve("/run/current-system/profile/bin/tar", ["tar", "xf", 
"/home/ludo/src/guix/foo.tar.gz"], [/* 63 vars */]) = 0
Process 29347 attached
[pid 29347] execve("/home/ludo/soft/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) 
= -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.opam/system/bin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/bin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/sbin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/setuid-programs/gzip", ["gzip", "-d"], [/* 63 vars 
*/]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/current-system/profile/bin/gzip", ["gzip", "-d"], [/* 
63 vars */]) = 0
[pid 29347] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29347, si_status=0, 
si_utime=0, si_stime=0} ---
+++ exited with 0 +++
$ tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
Permeso GPLv3+: GNU GPL versio 3 aŭ posta <>.
Tio ĉi estas libera programaro: vi estas libera por ŝanĝi kaj redisdoni ĝin.
Ekzistas NENIU GARANTIO, laŭ plej amplekse permesate de la leĝoj.

Verkita de John Gilmore kaj Jay Fenlason.
--8<---------------cut here---------------end--------------->8---

Could you check exactly what’s going on and send more details?

> Another option that just csme 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]