error when running guix pull on i686-linux

OpenSubmitted by Mayeul Cantan.
Details
2 participants
  • Ludovic Courtès
  • Mayeul Cantan
Owner
unassigned
Severity
important
M
M
Mayeul Cantan wrote on 17 May 15:16 +0200
Download
(address . bug-guix@gnu.org)
f939f5b6a2b43a814ee6e5b05f9ca798@mayeul.net
Download
Hello there,
I am having some trouble building the latest generation (f2e99d9) on my old samsung n130 (i686).
Here is the console output:
root@charon ~# guix pullUpdating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...Building from this channel:guix https://git.savannah.gnu.org/git/guix.gitf2e99d9substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%building /gnu/store/3yjm93pizc6pnggdvyl17ynajv51448j-module-import.drv...building /gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv...4% [##### ]builder for `/gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv' failed with exit code 1build of /gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv failedView build log at '/var/log/guix/drvs/gc/643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2'.cannot build derivation `/gnu/store/9sn1078n6nkdskpsa8wibbb19fgjl2a7-compute-guix-derivation.drv': 1 dependencies couldn't be builtguix pull: error: build of `/gnu/store/9sn1078n6nkdskpsa8wibbb19fgjl2a7-compute-guix-derivation.drv' failed
Attached are two log files from two successive attempts at running `guix pull`. I'm often having isues pulling the latest derivations on that computer, and currently sitting at f0da92cb42f99cddadd9cea373758355cb7c6351 (though I've also had issues before that specific one).
I've been interacting with mbakke on the matrix channel regarding this since yesterday.
We tried bisecting the issue, and found an unlikely culprit in the name of 694e10af639da64cdf6f1c44cadf9a64f8a04fa6
However, I had interupted guix pull when it seemed to progress further, assuming the commit was good. And when trying to build the commit right before, I encountered another, somewhat similar error (also attached: wy793 something).
After checking that 9d0b9c7c6c0b0d45653dea80b499314ea415d3c7 (just after the one I was on) worked all right, I tried a second bissect, that found 10c413685f13af12fa2bb34796db82e1f52b47af as a possible cause. After reverting just 10c41 failed, I also reverted 694e10 on top of that. I thought it had worked as it kept building, but it failed after a while (slightly different log: gi046...). During that build phase, a lot of these "unbound variable \x0" kept being printed to stdout, but I have a limited scrollback and forgot to tee it to a file beforehand. I could still obtain it if it was necessary.
I am not sure what to try next? I could try a script that sequencially builds every commit and prints the ones that succeed and the one that do not, but I wouldn't mind if you had better ideas, especially as a successful build can take a few hours to complete.
Thanks for your work, and sorry for this bug report that's a bit unclear and confused,
Mayeul
Attachment: file
Attachment: 643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2
Attachment: wy793d3r1q4qglfvfklsf8c6virby4-guix-system.drv.bz2
Attachment: gi046wfj8qdasv9n78ish87aphffwj-guix-extra.drv.bz2
L
L
Ludovic Courtès wrote on 29 May 18:02 +0200
Download
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
87o8q620gm.fsf@gnu.org
Download
Hi,
Mayeul Cantan <oss+guix@mayeul.net> skribis:
Toggle quote (10 lines)> After checking that 9d0b9c7c6c0b0d45653dea80b499314ea415d3c7 (just> after the one I was on) worked all right, I tried a second bissect,> that found 10c413685f13af12fa2bb34796db82e1f52b47af as a possible> cause. After reverting just 10c41 failed, I also reverted 694e10 on> top of that. I thought it had worked as it kept building, but it> failed after a while (slightly different log: gi046...). During that> build phase, a lot of these "unbound variable \x0" kept being printed> to stdout, but I have a limited scrollback and forgot to tee it to a> file beforehand. I could still obtain it if it was necessary.
The module-imported-compiled build log you provided shows this:
Toggle snippet (40 lines)[ 1/84] Loading './gcrypt/hash.scm'...[ 2/84] Loading './git.scm'...[ 3/84] Loading './gnu/packages/bootstrap.scm'...Backtrace: 19 (primitive-load-path "gnu/packages" #<procedure 840a8a0?>)In ice-9/eval.scm: 721:20 18 (primitive-eval _)In ice-9/psyntax.scm: 1262:36 17 (expand-top-sequence _ _ _ #f _ _ _) 1209:24 16 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?) 285:10 15 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)In ice-9/eval.scm: 293:34 14 (_ #<module (#{ g73}#) 81c5870>)In ice-9/boot-9.scm: 2874:4 13 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?) 2887:24 12 (_) 222:29 11 (map1 _) 222:17 10 (map1 (((guix ui)) ((guix utils)) ((guix discovery)) # ?)) 2800:17 9 (resolve-interface (guix ui) #:select _ #:hide _ # _ # _ ?)In ice-9/threads.scm: 390:8 8 (_ _)In ice-9/boot-9.scm: 2726:13 7 (_)In ice-9/threads.scm: 390:8 6 (_ _)In ice-9/boot-9.scm: 2994:20 5 (_) 2312:4 4 (save-module-excursion _) 3014:26 3 (_)In unknown file: 2 (primitive-load-path "guix/ui" #<procedure 8769de0 at i?>)In ice-9/eval.scm: 223:20 1 (proc #<module (#{ g268}#) 8871140>)In unknown file: 0 (%resolve-variable (7 . #) #<module (#{ g268}#) 8871140>)
ERROR: In procedure %resolve-variable:Unbound variable: #{\x0;\x0;\x0;\x0;\x0; […]
This hints at a possible memory corruption issue in Guile, especiallysince it seems to be non-deterministic.
That said, I successfully run:
$ guix pull -s i686-linux -p /tmp/test […] $ /tmp/test/bin/guix describe Generacio 1 May 29 2020 18:00:54 (nuna) guix 9ff667e repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9ff667ea05d0807b4e6512c92914ae517b9ec755
Most derivations were built locally. It’s on an x86_64 laptop, though.
Is it still crashy for you?
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 29 May 18:03 +0200
Download
control message for bug #41362
(address . control@debbugs.gnu.org)
87mu5q20gb.fsf@gnu.org
Download
severity 41362 importantquit
L
L
Ludovic Courtès wrote on 22 Jul 22:28 +0200
Download
Re: bug#41362: error when running guix pull on i686-linux
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
874kpzi9b2.fsf@gnu.org
Download
Hi Mayeul,
Does this bug still show up for you?
https://issues.guix.gnu.org/41362
TIA,Ludo’.
M
M
Mayeul Cantan wrote on 23 Jul 14:25 +0200
Download
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41362@debbugs.gnu.org)
98ab03d7-c172-03bb-481e-0021f3af30fe@cantan.eu
Download
Toggle quote (5 lines)> Does this bug still show up for you?> > https://issues.guix.gnu.org/41362>
Hi Ludo,
Thanks to your comment regarding a possible memory corruption issue, I ran my memory module trough memtest86+, which identified several problematic addresses. So this was likely a hardware issue.
I tried blacklisting them with the memmap kernel command-line option, but that didn't fix the issue. Looking at the addresses, I reduced my memory to 600 MiBs (mem=600M, which seems to solve the issue, though it makes `guix pull` extremely slow.
I haven't touched that system in a while, so my recollection is a bit fuzzy. I am going to try again, though. (I would have loved to experiment on another computer on top of another distro, but wasn't ready to give guix root access back then).
I think this really was a HW issue, but I will keep you posted.
Thank you for your answers,
Mayeul
--
Mayeul Cantan
CPE Lyon Electronics EngineerPhD student at the Lyon Institute of Nanotechnology+33 6 43 50 36 25
L
L
Ludovic Courtès wrote on 24 Jul 15:06 +0200
Download
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
87a6zp9i55.fsf@gnu.org
Download
Hello,
Mayeul Cantan <oss+guix@mayeul.net> skribis:
Toggle quote (16 lines)> Thanks to your comment regarding a possible memory corruption issue, I> ran my memory module trough memtest86+, which identified several> problematic addresses. So this was likely a hardware issue.>> I tried blacklisting them with the memmap kernel command-line option,> but that didn't fix the issue. Looking at the addresses, I reduced my> memory to 600 MiBs (mem=600M, which seems to solve the issue, though> it makes `guix pull` extremely slow.>> I haven't touched that system in a while, so my recollection is a bit> fuzzy. I am going to try again, though. (I would have loved to> experiment on another computer on top of another distro, but wasn't> ready to give guix root access back then).>> I think this really was a HW issue, but I will keep you posted.
It does look like a hardware issue from what you describe.
Thanks for the update,Ludo’.
?
Your may also send email to 41362@debbugs.gnu.org to comment.