From: Paul Boddie <paul@boddie.org.uk>
To: help-guix@gnu.org
Subject: Re: Bootstrapping on a new platform
Date: Mon, 4 Dec 2017 19:24:25 +0100 [thread overview]
Message-ID: <201712041924.26463.paul@boddie.org.uk> (raw)
In-Reply-To: <b59b4711-a3ed-ad76-9f3e-81e0ffcc4d30@gmail.com>
On Sunday 3. December 2017 07.46.56 Manolis Ragkousis wrote:
>
> First I would suggest checking out my talk in FOSDEM 17 which I tried to
> explain how bootstrapping in Guix works, along with how I did it for
> Hurd. [1]
I'll have a look at that, thanks! Thanks also to Efraim for some other advice
and encouragement. I'll post this here first for continuity and to the
development list later if this is more complicated than I hope it is.
> The simplified steps are the following:
> 1) Cross-build those binaries from a supported system
> 2) Add the new binaries to Guix (check gnu/packages/bootstrap.scm)
> 3) Copy the Guix source which now has the new binaries to the system you
> are trying to port it to. I suggest working on the git version of Guix
> for this. It's good to have the updated version.
> 4) ./boostrap && ./configure --with-courage && make
> 5) work out issues and enjoy.
>
> Does this make sense? I have spent a lot of time on this so please ask
> and I can help you :).
These steps are what I thought might be needed. So, I did the following on my
i386-linux-gnu system:
tar zxf guix-0.13.0.tar.gz
cd guix-0.13.0
./bootstrap
./configure
# Add to gnu/packages/bootstrap.scm:
# ((string=? system "mipsel-linux") "/lib/ld.so.1")
make
sudo make install
This got me the daemon again. Having set up the build users and group, I then
started the daemon...
sudo /usr/local/bin/guix-daemon --build-users-group=guixbuild
...and ran the build command for the binaries:
guix build --target=mipsel-linux-gnu bootstrap-tarballs
I then got a couple of errors that halted the build process. Here's the start
of the first error:
output path `/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2'
should have sha256 hash
`14l06m7nvcvb0igkbip58x59w3nq6315k6jcz3wr9ch1rn9d44bc', instead has
`1z91vb2i4d61fbrz7hdrsxiw3ksdzf372bgdzwsn75b72ndbi6lg'
And the next line with the immediate consequence:
@ build-failed /gnu/store/i966bhvp4jc0g42dl9vp6wyy9rsgrq5n-
gcc-4.9.4.tar.bz2.drv - 1 output path
`/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2' should have
sha256 hash `14l06m7nvcvb0igkbip58x59w3nq6315k6jcz3wr9ch1rn9d44bc', instead
has `1z91vb2i4d61fbrz7hdrsxiw3ksdzf372bgdzwsn75b72ndbi6lg'
cannot build derivation `/gnu/store/wxpq66chx58c69hz5qhqi34259mg1h9v-
gcc-4.9.4.tar.xz.drv': 1 dependencies couldn't be built
And here's the ultimate consequence:
guix build: error: build failed: build of
`/gnu/store/b30f33jsg0dv6ipymbhgpbyg5v6bagnv-bootstrap-tarballs-0.drv' failed
Running the build command again seems to either resolve this problem or make
it go away somehow. However, I then get a persistent error:
guix build: error: build failed: cloning builder process: Invalid argument
Looking at the archives, I see that this happened before (reported by Efraim):
https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00144.html
I didn't see any obvious conclusion. So, I ran the daemon using strace and
looked at the clone system call that supposedly causes this problem:
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x404c5f28) = 25426
close(4) = 0
accept(3, 0xbf8d5854, [110]) = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=25426, si_uid=0,
si_status=0, si_utime=137, si_stime=8} ---
waitpid(-1, NULL, WNOHANG) = 25426
waitpid(-1, NULL, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() (mask []) = -1 EINTR (Interrupted system call)
For the record, I'm running all this in a User Mode Linux instance, mostly
because my main system doesn't support the prerequisites for building Guix.
Last year, I attempted to run things in a chroot to satisfy the prerequisites,
but this seemed to make the tools unhappy. Generally, I haven't had problems
running software with UML whereas chroot doesn't attempt to virtualise
everything and can therefore cause certain kinds of problems.
I'm not sure what I need to do at this point. Did I miss something obvious?
Paul
next prev parent reply other threads:[~2017-12-04 18:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-02 23:17 Bootstrapping on a new platform Paul Boddie
2017-12-03 6:46 ` Manolis Ragkousis
2017-12-03 9:54 ` Efraim Flashner
2017-12-04 18:24 ` Paul Boddie [this message]
2017-12-08 10:28 ` Ludovic Courtès
2017-12-08 13:40 ` Paul Boddie
2017-12-08 16:19 ` Paul Boddie
2017-12-11 11:03 ` Ludovic Courtès
2017-12-11 16:36 ` Paul Boddie
2017-12-12 16:10 ` Ludovic Courtès
2017-12-12 16:29 ` Paul Boddie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201712041924.26463.paul@boddie.org.uk \
--to=paul@boddie.org.uk \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).