Bootstrapping on a new platform

Bootstrapping on a new platform

[Paul Boddie]

Hello,

I finally got round to trying to build Guix again, this time doing a native 
build rather than a cross-build. However, I'm attempting this on an 
unsupported platform (mipsel), and it isn't clear what I need to do to make 
the bootstrap binaries and thus attempt a source build.

What I've figured out so far is this:

tar zxf guix-0.13.0.tar.gz
cd guix-0.13.0
./bootstrap
./configure --with-courage
make
make install

This gets me the guix-daemon, but upon trying to do anything, I get the 
following:

guix build: error: could not find bootstrap binary 'tar' for system 'mipsel-
linux'

I understand that I need some bootstrap binaries, and the bootstrapping 
documentation indicates that these can indeed be generated as follows:

guix build --target=mipsel-linux-gnu bootstrap-tarballs

But this just gives the same error. And I am actually running on mipsel-linux-
gnu, so I suppose it might be different if I were try this on a supported 
system - i386-linux-gnu, for instance - and thus generate the binaries that 
way.

Maybe I have just missed the part of the manual that talks about these source 
builds, but it really doesn't seem obvious to me. Another thing, which I've 
seen mentioned on this list is reproducible builds. Might it be possible to 
have architecture-independent source archives that reproducibly build the 
binaries?

Sorry not to be able to figure this out for myself!

Paul

Re: Bootstrapping on a new platform

[Manolis Ragkousis]

Hello Paul,

On 12/03/17 01:17, Paul Boddie wrote:
> I finally got round to trying to build Guix again, this time doing a native 
> build rather than a cross-build. However, I'm attempting this on an 
> unsupported platform (mipsel), and it isn't clear what I need to do to make 
> the bootstrap binaries and thus attempt a source build.
> 
> What I've figured out so far is this:
> 
> tar zxf guix-0.13.0.tar.gz
> cd guix-0.13.0
> ./bootstrap
> ./configure --with-courage
> make
> make install
> 
> This gets me the guix-daemon, but upon trying to do anything, I get the 
> following:
> 
> guix build: error: could not find bootstrap binary 'tar' for system 'mipsel-
> linux'
> 

You need to cross-build those binaries from a system that is supported,
like x86_64-linux for example.
> I understand that I need some bootstrap binaries, and the bootstrapping 
> documentation indicates that these can indeed be generated as follows:
> 
> guix build --target=mipsel-linux-gnu bootstrap-tarballs
> 
> But this just gives the same error. And I am actually running on mipsel-linux-
> gnu, so I suppose it might be different if I were try this on a supported 
> system - i386-linux-gnu, for instance - and thus generate the binaries that 
> way.
> 
> Maybe I have just missed the part of the manual that talks about these source 
> builds, but it really doesn't seem obvious to me. Another thing, which I've 
> seen mentioned on this list is reproducible builds. Might it be possible to 
> have architecture-independent source archives that reproducibly build the 
> binaries?
> 

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]

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 :).

Manolis

[1] https://archive.fosdem.org/2017/schedule/event/guixhurd/

Re: Bootstrapping on a new platform

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]

On Sun, Dec 03, 2017 at 08:46:56AM +0200, Manolis Ragkousis wrote:
> Hello Paul,
> 
> On 12/03/17 01:17, Paul Boddie wrote:
> > I finally got round to trying to build Guix again, this time doing a native 
> > build rather than a cross-build. However, I'm attempting this on an 
> > unsupported platform (mipsel), and it isn't clear what I need to do to make 
> > the bootstrap binaries and thus attempt a source build.
> > 
> > What I've figured out so far is this:
> > 
> > tar zxf guix-0.13.0.tar.gz
> > cd guix-0.13.0
> > ./bootstrap
> > ./configure --with-courage
> > make
> > make install
> > 
> > This gets me the guix-daemon, but upon trying to do anything, I get the 
> > following:
> > 
> > guix build: error: could not find bootstrap binary 'tar' for system 'mipsel-
> > linux'
> > 
> 
> You need to cross-build those binaries from a system that is supported,
> like x86_64-linux for example.
> > I understand that I need some bootstrap binaries, and the bootstrapping 
> > documentation indicates that these can indeed be generated as follows:
> > 
> > guix build --target=mipsel-linux-gnu bootstrap-tarballs
> > 
> > But this just gives the same error. And I am actually running on mipsel-linux-
> > gnu, so I suppose it might be different if I were try this on a supported 
> > system - i386-linux-gnu, for instance - and thus generate the binaries that 
> > way.
> > 
> > Maybe I have just missed the part of the manual that talks about these source 
> > builds, but it really doesn't seem obvious to me. Another thing, which I've 
> > seen mentioned on this list is reproducible builds. Might it be possible to 
> > have architecture-independent source archives that reproducibly build the 
> > binaries?
> > 
> 
> 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]
> 
> 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 :).
> 
> Manolis
> 
> [1] https://archive.fosdem.org/2017/schedule/event/guixhurd/
> 

I also spent a lot of time getting the aarch64-linux port working, and
I'd be happy to help. Also you should post this to guix-devel also to
make sure there are more eyes on it.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bootstrapping on a new platform

[Paul Boddie]

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

Re: Bootstrapping on a new platform

[Ludovic Courtès]

Hi Paul

Paul Boddie <paul@boddie.org.uk> skribis:

> 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

0.14.0 was released yesterday, I’d suggest starting from that.

> # 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:

I’d suggest enabling substitutes if you don’t want to build everything
locally:

  https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

> 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'

That would suggest either that gcc-4.9.4.tar.bz2 was modified on
ftp.gnu.org (unlikely), or that there’s something fishy going on on the
network (captive portal, DNS hijacking, etc.)  Ideas?

> 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

Could you search in the strace output for the ‘clone’ call that failed
with EINVAL?  It’s probably the one from nix/libstore/build.cc.

> 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. 

What kernel version do you use?  guix-daemon requires namespace support,
but this is a relatively old feature.

Otherwise it might be some limitation of User Mode Linux; I’ve never
tried.

Thanks,
Ludo’.

Re: Bootstrapping on a new platform

[Paul Boddie]

On Friday 8. December 2017 11.28.38 Ludovic Courtès wrote:
> 
> Paul Boddie <paul@boddie.org.uk> skribis:
> > 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
> 
> 0.14.0 was released yesterday, I’d suggest starting from that.

I was actually drafting a mail about that yesterday, but that is another story 
with different complications (building Guile-Git, scheme-bytestructures).

> > # 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:
> I’d suggest enabling substitutes if you don’t want to build everything
> locally:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

I wouldn't mind building things locally, though. Previously, I wanted to avoid 
building cross-compilers, but this time I'm trying to do the whole thing.

> > 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'
> 
> That would suggest either that gcc-4.9.4.tar.bz2 was modified on
> ftp.gnu.org (unlikely), or that there’s something fishy going on on the
> network (captive portal, DNS hijacking, etc.)  Ideas?

I do wonder about this kind of thing, but I'm using fibre-based broadband. 
Could it be mirroring issues? I tend to get checksum issues when updating 
recent Debian releases that are resolved when retrying and that I've regarded 
as being related to files being updated when apt tries to read them all, but I 
suppose there could be other things happening. (I also used to get this on a 
previous cable-based broadband provider, though.)

Actually, running sha256sum yields this:

sha256sum /gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2 
326efcf243fd917d5e57b930cc8b51c79260176099fd4f5cbc38b1473bd246a3  
/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2

Is this the right way of generating the hash?

> > 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
> 
> Could you search in the strace output for the ‘clone’ call that failed
> with EINVAL?  It’s probably the one from nix/libstore/build.cc.

There isn't one that I can find. All I get is this:

write(2, "accepted connection from pid 157"..., 46accepted connection from pid 
1570, user paulb
) = 46
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 1572
close(4)                                = 0
accept(3, 0xbfb09d84, [110])            = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1572, si_uid=0, 
si_status=0, si_utime=61, si_stime=6} ---
waitpid(-1, NULL, WNOHANG)              = 1572
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.
> 
> What kernel version do you use?  guix-daemon requires namespace support,
> but this is a relatively old feature.

This is an older kernel: 3.2.62. I chose this a while ago when setting up 
various instances, and this was something that I knew worked with the Debian 
versions I wanted to run.

> Otherwise it might be some limitation of User Mode Linux; I’ve never
> tried.

I tried UML with a 4.9.67 kernel (and CONFIG_NAMESPACES=y) but still got the 
error. There's still only one clone system call:

write(2, "accepted connection from pid 721"..., 45accepted connection from pid 
721, user paulb
) = 45
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 723
close(4)                                = 0
accept(3, 0xbf8bc244, [110])            = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=723, si_uid=0, 
si_status=0, si_utime=4, si_stime=252} ---
waitpid(-1, NULL, WNOHANG)              = 723
waitpid(-1, NULL, WNOHANG)              = -1 ECHILD (No child processes)
sigreturn() (mask [RT_2])               = -1 EINTR (Interrupted system call)

I'm tracing the daemon here. Should I also be tracing something else?

Thanks for the help!

Paul

Re: Bootstrapping on a new platform

[Paul Boddie]

On Friday 8. December 2017 14.40.14 Paul Boddie wrote:
> On Friday 8. December 2017 11.28.38 Ludovic Courtès wrote:
> > 
> > Could you search in the strace output for the ‘clone’ call that failed
> > with EINVAL?  It’s probably the one from nix/libstore/build.cc.

[...]

> I'm tracing the daemon here. Should I also be tracing something else?

Sorry, I found that I should be running strace using the -o, -f and -ff 
options:

strace -o /tmp/guix -f -ff /usr/local/bin/guix-daemon \
       --build-users-group=guixbuild

This gave me the following in the parent process log (/tmp/guix.793):

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x404c5f28) = 797
close(4)                                = 0
accept(3, 0xbfff7224, [110])            = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=797, si_uid=0, 
si_status=0, si_utime=51, si_stime=524} ---
waitpid(-1, NULL, WNOHANG)              = 797

This resembling what I showed before. Meanwhile in the child process log 
(/tmp/guix.797) the clone call with EINVAL is this one:

clone(child_stack=0xbffedfa4, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)

Again, this is using the 4.9.67 kernel.

Paul

Re: Bootstrapping on a new platform

[Ludovic Courtès]

Hi Paul,

Paul Boddie <paul@boddie.org.uk> skribis:

> This resembling what I showed before. Meanwhile in the child process log 
> (/tmp/guix.797) the clone call with EINVAL is this one:
>
> clone(child_stack=0xbffedfa4, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
> CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)
>
> Again, this is using the 4.9.67 kernel.

This suggests that namespaces are not fully supported with this kernel.
The clone(2) page has this:

   EINVAL CLONE_NEWIPC  was specified in flags, but the kernel was not configured with the CONFIG_SYSVIPC and
          CONFIG_IPC_NS options.

   EINVAL CLONE_NEWNET was specified in flags, but the kernel  was  not  configured  with  the  CONFIG_NET_NS
          option.

   EINVAL CLONE_NEWPID  was  specified  in  flags,  but  the kernel was not configured with the CONFIG_PID_NS
          option.

   EINVAL CLONE_NEWUTS was specified in flags, but the kernel was not configured with the CONFIG_UTS option.

Could it be one of these?

HTH,
Ludo’.

Re: Bootstrapping on a new platform

[Paul Boddie]

On Monday 11. December 2017 12.03.56 Ludovic Courtès wrote:
> 
> Paul Boddie <paul@boddie.org.uk> skribis:
> > This resembling what I showed before. Meanwhile in the child process log
> > (/tmp/guix.797) the clone call with EINVAL is this one:
> > 
> > clone(child_stack=0xbffedfa4,
> > flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
> > CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)
> > 
> > Again, this is using the 4.9.67 kernel.
> 
> This suggests that namespaces are not fully supported with this kernel.
> The clone(2) page has this:
> 
>    EINVAL CLONE_NEWIPC  was specified in flags, but the kernel was not
> configured with the CONFIG_SYSVIPC and CONFIG_IPC_NS options.
> 
>    EINVAL CLONE_NEWNET was specified in flags, but the kernel  was  not 
> configured  with  the  CONFIG_NET_NS option.
> 
>    EINVAL CLONE_NEWPID  was  specified  in  flags,  but  the kernel was not
> configured with the CONFIG_PID_NS option.
> 
>    EINVAL CLONE_NEWUTS was specified in flags, but the kernel was not
> configured with the CONFIG_UTS option.
> 
> Could it be one of these?

I ran "make menuconfig ARCH=um" and saw that "User namespace" and "PID 
Namespaces" were not enabled. So I enabled them, rebuilt the kernel, and then 
ran the User Mode Linux instance again.

This time, it would appear that running the daemon and then running a build 
command gets the daemon to do some work. There have been some problems with 
hashes, as reported before, but the problem with clone seems to have been 
solved.

Sorry for the noise, but I guess this is what happens when someone tries to do 
things the hard way. Thanks for identifying the cause of the problem!

Paul

Re: Bootstrapping on a new platform

[Ludovic Courtès]

Paul Boddie <paul@boddie.org.uk> skribis:

> On Monday 11. December 2017 12.03.56 Ludovic Courtès wrote:
>> 
>> Paul Boddie <paul@boddie.org.uk> skribis:
>> > This resembling what I showed before. Meanwhile in the child process log
>> > (/tmp/guix.797) the clone call with EINVAL is this one:
>> > 
>> > clone(child_stack=0xbffedfa4,
>> > flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
>> > CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)
>> > 
>> > Again, this is using the 4.9.67 kernel.
>> 
>> This suggests that namespaces are not fully supported with this kernel.
>> The clone(2) page has this:
>> 
>>    EINVAL CLONE_NEWIPC  was specified in flags, but the kernel was not
>> configured with the CONFIG_SYSVIPC and CONFIG_IPC_NS options.
>> 
>>    EINVAL CLONE_NEWNET was specified in flags, but the kernel  was  not 
>> configured  with  the  CONFIG_NET_NS option.
>> 
>>    EINVAL CLONE_NEWPID  was  specified  in  flags,  but  the kernel was not
>> configured with the CONFIG_PID_NS option.
>> 
>>    EINVAL CLONE_NEWUTS was specified in flags, but the kernel was not
>> configured with the CONFIG_UTS option.
>> 
>> Could it be one of these?
>
> I ran "make menuconfig ARCH=um" and saw that "User namespace" and "PID 
> Namespaces" were not enabled. So I enabled them, rebuilt the kernel, and then 
> ran the User Mode Linux instance again.
>
> This time, it would appear that running the daemon and then running a build 
> command gets the daemon to do some work. There have been some problems with 
> hashes, as reported before, but the problem with clone seems to have been 
> solved.
>
> Sorry for the noise, but I guess this is what happens when someone tries to do 
> things the hard way. Thanks for identifying the cause of the problem!

Great that you found out!

Ludo’.

Re: Bootstrapping on a new platform

[Paul Boddie]

On Tuesday 12. December 2017 17.10.59 Ludovic Courtès wrote:
> Paul Boddie <paul@boddie.org.uk> skribis:
> > 
> > Sorry for the noise, but I guess this is what happens when someone tries
> > to do things the hard way. Thanks for identifying the cause of the
> > problem!
> 
> Great that you found out!

I'll keep you posted about the end result. I managed to encounter a problem 
with User Mode Linux that is known:

do_syscall_stub : ret = -12, offset = 1052680, data = 09b80008
do_syscall_stub: syscall 192 failed, return value = 0xfffffff4, expected 
return value = 0x1cff8000
    syscall parameters: 0x1cff8000 0x1000 0x7 0x11 0x3 0xd464
Failed to flush page for address 0x1cff8000

Apparently, this scary error, which causes the offending process to terminate, 
is the result of an insufficiently large value in /proc/sys/vm/max_map_count. 
Since I don't have huge amounts of memory by modern standards, I'm used to 
occasional problems with UML, and I guess that some of the build tasks are 
quite demanding.

Hopefully, I'll be able to complete the build of GCC 5.4, which is the thing 
that repeatably causes this. Then we'll see what happens.

Thanks once again!

Paul