GNU bug report logs - #50212
Tests fail while building Guix

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50212 in the body.
You can then email your comments to 50212 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: bug-guix <at> gnu.org
Subject: Tests fail while building Guix
Date: Thu, 26 Aug 2021 15:45:13 +0200

[Message part 1 (text/plain, inline)]

Hello,

after a time off, I just recently began pulling the latest commits and
have been trying to build Guix since maybe a week.  But several tests
fail.  Even a clean clone fails.

I've only a handful of logs.  It seams that the tests fail mostly for
this reason:

/home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory

But this executable is there though.

I've attached only a handful of logs.


Cheers
Simon

[challenge.log (application/octet-stream, attachment)]

[derivations.log (application/octet-stream, attachment)]

[gexp.log (application/octet-stream, attachment)]

[grafts.log (application/octet-stream, attachment)]

[graph.log (application/octet-stream, attachment)]

[packages.log (application/octet-stream, attachment)]

[profiles.log (application/octet-stream, attachment)]

[store.log (application/octet-stream, attachment)]

Message #8 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: 50212 <at> debbugs.gnu.org
Subject: Tests fail while building Guix
Date: Thu, 26 Aug 2021 20:07:26 +0200

[Message part 1 (text/plain, inline)]

Hello,

since my first submission of this bug report was rejected -- the
attachments where too big --, this report I will simply repost so that
it can be delivered through mailman while the original post remains only
accessible through the web interface.

Here the original post:

Simon Streit <simon <at> netpanic.org> writes:
> Hello,
>
> after a time off, I just recently began pulling the latest commits and
> have been trying to build Guix since maybe a week.  But several tests
> fail.  Even a clean clone fails.
>
> I've only a handful of logs.  It seams that the tests fail mostly for
> this reason:
>
> /home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory
>
> But this executable is there though.

The original logs have been compressed, which should make them now small
enough to let them through the mailer.

[challenge.log.gz (application/octet-stream, attachment)]

[derivations.log.gz (application/octet-stream, attachment)]

[gexp.log.gz (application/octet-stream, attachment)]

[grafts.log.gz (application/octet-stream, attachment)]

[graph.log.gz (application/octet-stream, attachment)]

[packages.log.gz (application/octet-stream, attachment)]

[profiles.log.gz (application/octet-stream, attachment)]

[store.log.gz (application/octet-stream, attachment)]

Message #11 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: 50212 <at> debbugs.gnu.org
Subject: Several tests fail, Bash fails often. Was: Tests fail while
 building Guix
Date: Fri, 27 Aug 2021 21:53:29 +0200

[Message part 1 (text/plain, inline)]

This is another follow up after having actually read the relevant info
section on how to do proper testing in Guix.

Checkout is at 5422920b9eaaa0c6bf779588748595c66ca86ba3, and this time I
prepared a test-suite.log with all errors that happen.  Please find it
attached.  This time it isn't too big either.

Unfortunately ‘tests/processes.scm’ hangs too, or remains unresponsive
after several minutes.

I really wonder what is making all the tests fail.  I've tried building
the sources on different machines, or on clean user accounts.  They all
fail in the same way.  Has someone else been experiencing this yet?


Kind regards,
Simon

[test-suite.log (application/octet-stream, attachment)]

Message #14 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Simon Streit <simon <at> netpanic.org>, 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sat, 28 Aug 2021 17:00:50 +0200

[Message part 1 (text/plain, inline)]

Simon Streit schreef op vr 27-08-2021 om 21:53 [+0200]:
> This is another follow up after having actually read the relevant info
> section on how to do proper testing in Guix.
> 
> Checkout is at 5422920b9eaaa0c6bf779588748595c66ca86ba3, and this time I
> prepared a test-suite.log with all errors that happen.  Please find it
> attached.  This time it isn't too big either.

Some questions:

* What's the hash of gnu/packages/bootstrap/i686-linux/bash?

  (Run guix hash gnu/packages/bootstrap/i686-linux/bash)

  I have 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd.
  If you see something different, your copy is probably corrupt.

* What does ‘objdump -a gnu/packages/bootstrap/i686-linux/bash’ output?
  On my x86_64 system, it outputs ‘[...] file format elf32-i386’.

* What architecture are you on?

  You can test with:

  $ echo '((@ (guix utils) %current-system))' | guix repl

  On my x86_64-linux system, it outputs

  [...]
  $1 = "x86_64-linux"
  scheme@(guix-user)>.

If your system isn't i686-linux or x86_64-linux, something odd is going on.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Simon Streit <simon <at> netpanic.org>
Cc: 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Tests fail while building Guix
Date: Sat, 28 Aug 2021 17:33:31 +0200

On 2021-08-26 20:07, Simon Streit wrote:
> /home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: 
> 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory
> 
> But this executable is there though.

Does it run when invoked manually?

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Message #20 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Maxime Devos <maximedevos <at> telenet.be>, Simon Streit
 <simon <at> netpanic.org>, 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sat, 28 Aug 2021 14:13:24 -0400

Hi,

Maxime Devos <maximedevos <at> telenet.be> writes:
> * What's the hash of gnu/packages/bootstrap/i686-linux/bash?
>
>   (Run guix hash gnu/packages/bootstrap/i686-linux/bash)
>
>   I have 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd.
>   If you see something different, your copy is probably corrupt.

Also check the permissions of gnu/packages/bootstrap/i686-linux/bash.
It should be 0555, i.e. "-r-xr-xr-x", and ditto for 'mkdir' in the same
directory.  I vaguely recall someone running into a similar problem many
years ago because the executable bit was missing in their bootstrap
files, even though the files had the correct contents.  The executable
bit is effectively included in the hash computation when the file is
imported to the store, although "guix hash" disregards it when applied
to a single file.

       Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Message #23 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Tests fail while building Guix
Date: Sat, 28 Aug 2021 23:56:31 +0200

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> On 2021-08-26 20:07, Simon Streit wrote:
>> /home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash:
>> 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory
>> But this executable is there though.
>
> Does it run when invoked manually?

Good question!  Should have thought about this before early on.  No, it
doesn't.

Message #26 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 50212 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sun, 29 Aug 2021 00:14:50 +0200

Hey Mark,

Mark H Weaver <mhw <at> netris.org> writes:
> Also check the permissions of gnu/packages/bootstrap/i686-linux/bash.
> It should be 0555, i.e. "-r-xr-xr-x", and ditto for 'mkdir' in the same
> directory.  I vaguely recall someone running into a similar problem many
> years ago because the executable bit was missing in their bootstrap
> files, even though the files had the correct contents.  The executable
> bit is effectively included in the hash computation when the file is
> imported to the store, although "guix hash" disregards it when applied
> to a single file.

Contents of bootstrap are as follows:
--8<---------------cut here---------------start------------->8---
  /home/ss2/code/guix/gnu/packages/bootstrap/i686-linux:
  total used in directory 4.1M available 340.5 GiB
  drwxr-xr-x 3 ss2 users 4.0K Aug 28 23:55 .
  drwxr-xr-x 3 ss2 users 4.0K Apr 19 22:13 ..
  -r-xr-xr-x 1 ss2 users 1.3M Mar  7 23:53 bash
  -r-xr-xr-x 1 ss2 users 698K Mar  7 23:54 mkdir
  -r-xr-xr-x 1 ss2 users 1.3M Mar  7 23:57 tar
  -r-xr-xr-x 1 ss2 users 842K Mar  7 23:57 xz
--8<---------------cut here---------------end--------------->8---

Simon

Message #29 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sun, 29 Aug 2021 00:32:25 +0200

Hello Maxime,

Maxime Devos <maximedevos <at> telenet.be> writes:
> Some questions:
>
> * What's the hash of gnu/packages/bootstrap/i686-linux/bash?
>
>   (Run guix hash gnu/packages/bootstrap/i686-linux/bash)
>
>   I have 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd.
>   If you see something different, your copy is probably corrupt.

The hash is: 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd

> * What does ‘objdump -a gnu/packages/bootstrap/i686-linux/bash’ output?
>   On my x86_64 system, it outputs ‘[...] file format elf32-i386’.

Result is:
--8<---------------cut here---------------start------------->8---
./bash:     file format elf32-i386
--8<---------------cut here---------------end--------------->8---

> * What architecture are you on?

And: x86_64-linux system.

I just updated my system to a8dd285d5a0670abf124a721e6ba94da045b24ba and
am building 76114232d7c140fb9fee84510b72fcfe6ee27714, which failed again.

Early on I installed Guix into a VM, and built the sources in there
on a pretty much default config from the installer.  All tests passed.

Just to be sure I did another clean clone on my main machine, which
failed again.

So why would my system brake the bootstrap binary?  Has it got to do
with a particular package I have in my profile(s)?  I generally build
Guix with ‘guix environment --pure guix.’  I have a second Guix build
machine running.  The packages used there are quite similar, so these
two machines have very similar checkouts and config in general.  Hence,
when I build Guix there, the same error occurs.


Simon

Message #32 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 50212 <at> debbugs.gnu.org
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sun, 29 Aug 2021 15:06:04 +0200

Simon Streit <simon <at> netpanic.org> writes:
> So why would my system brake the bootstrap binary?  Has it got to do
> with a particular package I have in my profile(s)?  I generally build
> Guix with ‘guix environment --pure guix.’  I have a second Guix build
> machine running.  The packages used there are quite similar, so these
> two machines have very similar checkouts and config in general.  Hence,
> when I build Guix there, the same error occurs.

I figured out why this is happening.  I disabled
--8<---------------cut here---------------start------------->8---
(service qemu-binfmt-service-type
         (qemu-binfmt-configuration
          (platforms (lookup-qemu-platforms "arm" "aarch64" "i386"))))
--8<---------------cut here---------------end--------------->8---
and now all tests pass.

Why would this be a problem?  


Simon

Message #35 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: 50212 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Sun, 29 Aug 2021 17:28:43 -0400

Hello Simon,

Simon Streit <simon <at> netpanic.org> writes:

> Simon Streit <simon <at> netpanic.org> writes:
>> So why would my system brake the bootstrap binary?  Has it got to do
>> with a particular package I have in my profile(s)?  I generally build
>> Guix with ‘guix environment --pure guix.’  I have a second Guix build
>> machine running.  The packages used there are quite similar, so these
>> two machines have very similar checkouts and config in general.  Hence,
>> when I build Guix there, the same error occurs.
>
> I figured out why this is happening.  I disabled
>
> (service qemu-binfmt-service-type
>          (qemu-binfmt-configuration
>           (platforms (lookup-qemu-platforms "arm" "aarch64" "i386"))))
>
> and now all tests pass.
>
> Why would this be a problem?  

I'm guessing the i386 does something bogus?  Your x86_64 is already able
to run i386 code natively, AFAIK.

The binfmt service type registers binary formats of non-native
architectures with interpreters to run them [0]; this way, when an ARM
binary is encountered on a x86_64 system, the kernel Linux knows to
launch it via QEMU, for example.  Since commit
77c2f4e2068ebec3f384c826c5a99785125ff72c, this is in effect for any
container (it used to be possible to enable it with (guix-support? #t)
on only for the container spawned by guix-daemon.

For the record, I use:

--8<---------------cut here---------------start------------->8---
      (service qemu-binfmt-service-type
               (qemu-binfmt-configuration
                (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc64le"))))
--8<---------------cut here---------------end--------------->8---

On my main machine without any issue.

HTH,

[0]  https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html

Message #38 received at 50212 <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 50212 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Mon, 30 Aug 2021 20:17:02 +0200

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> I'm guessing the i386 does something bogus?  Your x86_64 is already able
> to run i386 code natively, AFAIK.

Alright, this was my interpretation from the manual and available
architectures that I just plugged it all together like that.  I wasn't
aware that x86_64 can run i386 natively.

> The binfmt service type registers binary formats of non-native
> architectures with interpreters to run them [0]; this way, when an ARM
> binary is encountered on a x86_64 system, the kernel Linux knows to
> launch it via QEMU, for example.  Since commit
> 77c2f4e2068ebec3f384c826c5a99785125ff72c, this is in effect for any
> container (it used to be possible to enable it with (guix-support? #t)
> on only for the container spawned by guix-daemon.

I reenabled the service without it mentioning i386.  Building Guix
passes as expected.  Thank you.


Kind regards,
Simon

Message #43 received at 50212-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: 50212-done <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#50212: Several tests fail, Bash fails often. Was: Tests
 fail while building Guix
Date: Mon, 30 Aug 2021 16:24:54 -0400

Hello Simon,

Simon Streit <simon <at> netpanic.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>> I'm guessing the i386 does something bogus?  Your x86_64 is already able
>> to run i386 code natively, AFAIK.
>
> Alright, this was my interpretation from the manual and available
> architectures that I just plugged it all together like that.  I wasn't
> aware that x86_64 can run i386 natively.
>
>> The binfmt service type registers binary formats of non-native
>> architectures with interpreters to run them [0]; this way, when an ARM
>> binary is encountered on a x86_64 system, the kernel Linux knows to
>> launch it via QEMU, for example.  Since commit
>> 77c2f4e2068ebec3f384c826c5a99785125ff72c, this is in effect for any
>> container (it used to be possible to enable it with (guix-support? #t)
>> on only for the container spawned by guix-daemon.
>
> I reenabled the service without it mentioning i386.  Building Guix
> passes as expected.  Thank you.

No worries.  Thank you for the update.

Closing.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.