Tests fail while building Guix

DoneSubmitted by Simon Streit.
Details
5 participants
  • Maxim Cournoyer
  • Maxime Devos
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • Simon Streit
Owner
unassigned
Severity
normal
S
S
Simon Streit wrote on 26 Aug 15:45 +0200
(address . bug-guix@gnu.org)
yguh7fcz5ee.fsf@netpanic.org
Hello,
after a time off, I just recently began pulling the latest commits andhave been trying to build Guix since maybe a week. But several testsfail. Even a clean clone fails.
I've only a handful of logs. It seams that the tests fail mostly forthis 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.

CheersSimon
Attachment: challenge.log
Attachment: derivations.log
Attachment: gexp.log
Attachment: grafts.log
Attachment: graph.log
Attachment: packages.log
Attachment: profiles.log
Attachment: store.log
S
S
Simon Streit wrote on 26 Aug 20:07 +0200
(address . 50212@debbugs.gnu.org)
ygu4kbcyt9d.fsf@netpanic.org
Hello,
since my first submission of this bug report was rejected -- theattachments where too big --, this report I will simply repost so thatit can be delivered through mailman while the original post remains onlyaccessible through the web interface.
Here the original post:
Simon Streit <simon@netpanic.org> writes:
Toggle quote (13 lines)> 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 smallenough to let them through the mailer.
Attachment: challenge.log.gz
Attachment: derivations.log.gz
Attachment: gexp.log.gz
Attachment: grafts.log.gz
Attachment: graph.log.gz
Attachment: packages.log.gz
Attachment: profiles.log.gz
Attachment: store.log.gz
S
S
Simon Streit wrote on 27 Aug 21:53 +0200
(address . 50212@debbugs.gnu.org)
yguczpyhdfq.fsf@netpanic.org
This is another follow up after having actually read the relevant infosection on how to do proper testing in Guix.
Checkout is at 5422920b9eaaa0c6bf779588748595c66ca86ba3, and this time Iprepared a test-suite.log with all errors that happen. Please find itattached. This time it isn't too big either.
Unfortunately ‘tests/processes.scm’ hangs too, or remains unresponsiveafter several minutes.
I really wonder what is making all the tests fail. I've tried buildingthe sources on different machines, or on clean user accounts. They allfail in the same way. Has someone else been experiencing this yet?

Kind regards,Simon
Attachment: test-suite.log
M
M
Maxime Devos wrote on 28 Aug 17:00 +0200
5fed54e119c256140ccfc15baa239947c988caef.camel@telenet.be
Simon Streit schreef op vr 27-08-2021 om 21:53 [+0200]:
Toggle quote (7 lines)> 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.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYSpPoxccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7gtuAP4/mceLMmlMQnxN5B9Nt35kERcIMuMLPQGQxIbG/whjlAD7B5knRo+hHOY+rY37M1KhOq2NbYWvwfCtdF0GeHHxRQc==IRVL-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 28 Aug 17:33 +0200
Re: bug#50212: Tests fail while building Guix
(name . Simon Streit)(address . simon@netpanic.org)(address . 50212@debbugs.gnu.org)
797307d73597fa284c99efa4e7156c02@tobias.gr
On 2021-08-26 20:07, Simon Streit wrote:
Toggle quote (5 lines)> /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.
M
M
Mark H Weaver wrote on 28 Aug 20:13 +0200
Re: bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix
87bl5hjv34.fsf@netris.org
Hi,
Maxime Devos <maximedevos@telenet.be> writes:
Toggle quote (7 lines)> * 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 samedirectory. I vaguely recall someone running into a similar problem manyyears ago because the executable bit was missing in their bootstrapfiles, even though the files had the correct contents. The executablebit is effectively included in the hash computation when the file isimported to the store, although "guix hash" disregards it when appliedto a single file.
Mark
--Disinformation flourishes because many people care deeply about injusticebut very few check the facts. Ask me about https://stallmansupport.org.
S
S
Simon Streit wrote on 28 Aug 23:56 +0200
Re: bug#50212: Tests fail while building Guix
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 50212@debbugs.gnu.org)
ygubl5hqlm8.fsf@netpanic.org
Tobias Geerinckx-Rice <me@tobias.gr> writes:
Toggle quote (7 lines)> 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, itdoesn't.
S
S
Simon Streit wrote on 29 Aug 00:14 +0200
Re: bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix
(name . Mark H Weaver)(address . mhw@netris.org)
yguzgt1p679.fsf@netpanic.org
Hey Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (9 lines)> 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:
Toggle snippet (10 lines) /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
Simon
S
S
Simon Streit wrote on 29 Aug 00:32 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 50212@debbugs.gnu.org)
yguy28lp5dy.fsf@netpanic.org
Hello Maxime,
Maxime Devos <maximedevos@telenet.be> writes:
Toggle quote (9 lines)> 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
Toggle quote (3 lines)> * What does ‘objdump -a gnu/packages/bootstrap/i686-linux/bash’ output?> On my x86_64 system, it outputs ‘[...] file format elf32-i386’.
Result is:
Toggle snippet (3 lines)./bash: file format elf32-i386
Toggle quote (2 lines)> * What architecture are you on?
And: x86_64-linux system.
I just updated my system to a8dd285d5a0670abf124a721e6ba94da045b24ba andam building 76114232d7c140fb9fee84510b72fcfe6ee27714, which failed again.
Early on I installed Guix into a VM, and built the sources in thereon a pretty much default config from the installer. All tests passed.
Just to be sure I did another clean clone on my main machine, whichfailed again.
So why would my system brake the bootstrap binary? Has it got to dowith a particular package I have in my profile(s)? I generally buildGuix with ‘guix environment --pure guix.’ I have a second Guix buildmachine running. The packages used there are quite similar, so thesetwo machines have very similar checkouts and config in general. Hence,when I build Guix there, the same error occurs.

Simon
S
S
Simon Streit wrote on 29 Aug 15:06 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 50212@debbugs.gnu.org)
ygufsus1jur.fsf@netpanic.org
Simon Streit <simon@netpanic.org> writes:
Toggle quote (7 lines)> 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
Toggle snippet (4 lines)(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?

Simon
M
M
Maxim Cournoyer wrote on 29 Aug 23:28 +0200
(name . Simon Streit)(address . simon@netpanic.org)
87o89gszxw.fsf@gmail.com
Hello Simon,
Simon Streit <simon@netpanic.org> writes:
Toggle quote (18 lines)> Simon Streit <simon@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 ableto run i386 code natively, AFAIK.
The binfmt service type registers binary formats of non-nativearchitectures with interpreters to run them [0]; this way, when an ARMbinary is encountered on a x86_64 system, the kernel Linux knows tolaunch it via QEMU, for example. Since commit77c2f4e2068ebec3f384c826c5a99785125ff72c, this is in effect for anycontainer (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:
Toggle snippet (5 lines) (service qemu-binfmt-service-type (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc64le"))))
On my main machine without any issue.
HTH,
[0] https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
S
S
Simon Streit wrote on 30 Aug 20:17 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
ygusfyqztk1.fsf@netpanic.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
Toggle quote (3 lines)> 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 availablearchitectures that I just plugged it all together like that. I wasn'taware that x86_64 can run i386 natively.
Toggle quote (8 lines)> 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 Guixpasses as expected. Thank you.

Kind regards,Simon
M
M
Maxim Cournoyer wrote on 30 Aug 22:24 +0200
(name . Simon Streit)(address . simon@netpanic.org)
87v93mk7e1.fsf@gmail.com
Hello Simon,
Simon Streit <simon@netpanic.org> writes:
Toggle quote (19 lines)> Maxim Cournoyer <maxim.cournoyer@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
Closed
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 50212@debbugs.gnu.org