help-guix
[Top][All Lists]
Advanced

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

Re: Bootstrapping on a new platform


From: Paul Boddie
Subject: Re: Bootstrapping on a new platform
Date: Mon, 4 Dec 2017 19:24:25 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-486; KDE/4.8.4; i686; ; )

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



reply via email to

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