[Top][All Lists]

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


From: George Clemmer
Subject: Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***
Date: Wed, 31 Oct 2018 19:44:09 -0400
User-agent: mu4e 1.0; emacs 26.1

Brian Woodcox <address@hidden> writes:

> I think I’ve had it sitting like that for hours.
> The reason I think it’s hung in VirtualBox is the fact that within
> about 45 seconds there is no longer any activity on the hard disk
> icon.
> I am currently installing in Qemu and will see how that goes.

Dunno about VirtualBox. But I just did 'guix pull' on a fresh 'guix
system vm-image' running on GuixSD in QEMU. It looks the same: 4 CPUs
howling and the hard drive doing hardly anything.  But I see this in

address@hidden ~$ ls /tmp

... and BOOTSTRP GUILEC steps are trickling out. So even thought it
feels like it, it's not hung.

>> On Oct 31, 2018, at 3:54 PM, George Clemmer <address@hidden> wrote:
>> Hi Brian & Leo
>> Brian, I believe that what you are experiencing as a "hang" is actually
>> the incredibly long time that it takes for guile to bootstrap itself.  I
>> started encountering this recently when commissioning new VMs and. At
>> first I thought they were "hung" but eventually I discovered that they
>> were doing this step, and it takes >30 min on address@hidden
>> In my case I do 'guix system vm-image' and then, on the vm, I build
>> guix, emacs-guix, and geiser from Git. I don't think this is much
>> different than installing the 0.15.0 image on VirtualBox.
>> I don't understand why Guile feels the need to bootstrap itself in this
>> situation. And this behavior seems to be "new" in recent Guix commits.
>> Have you tried just letting it chug away overnight?
>> FWIW, I am building vms with Guix v0.15.0-3097-gc16913d34.
>> HTH - George
>> Brian Woodcox <address@hidden> writes:
>>> This is what is displaced on the screen when the hang occurs:
>>> …
>>> make  check-TESTS
>>> make[3]: Entering directory ‘/tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3’
>>> Testing /tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3/meta/guile …
>>> with 
>>> GUILE_LOAD_PATH=/tmp/guix-guild-guile-2.2.3.drv-0/guile-2.2.3/test-suite
>>>> On Oct 31, 2018, at 12:35 PM, Mark H Weaver <address@hidden> wrote:
>>>> Brian Woodcox <address@hidden> writes:
>>>>> So I have been trying to install GuixSD 0.15.0 for a few days now.
>>>>> My first problem was not setting
>>>>> —substitutes-urls=“  So that fixed one
>>>>> problem.
>>>>> My other problem is try as I might, I cannot get either guile-2.2.3 or
>>>>> guile-2.2.4 to install.
>>>>> It always hangs when trying to do the tests after writing all the *.go
>>>>> files, (which by the way takes a long time).
>>>> What are the last messages visible at the point where it gets stuck?
>>>> It would be helpful to see the tail of the build log.
>>>> Since I've not seen other reports of this problem, my first guess is
>>>> that the problem is specific to builds done within VirtualBox, for some
>>>> reason.  It would be useful to know which test is getting stuck.  Since
>>>> VirtualBox requires a non-free compiler for part of its build, I don't
>>>> use it myself.  I use QEMU instead.
>>>> Also, normally you would not need to build Guile, but would simply
>>>> download a binary substitute for Guile.  However, our primary build farm
>>>> is currently offline due to a recent disk failure, and our newer build
>>>> farm ( unfortunately does not have a complete set of
>>>> substitutes for 0.15.0, but only for the most popular or most recently
>>>> built ones.
>>>> So, this is a temporary issue while we wait for the FSF sysadmins to
>>>> finish migrating to a new disk array, which will probably
>>>> be another few days.  I'm sorry for the inconvenience.
>>>>> So are there any work arounds to disable the tests for guile-2.2.x so
>>>>> I can get this operating system operational?
>>>> In theory it could be done, but disabling tests would be a change to the
>>>> Guile package, and therefore a change to the derivations of all packages
>>>> built on top of Guile, which in Guix is *everything* because Guile is
>>>> used to execute our build recipes.
>>>> As a result, if you did this, you would not be able to find *any* binary
>>>> substitutes from our official servers, because you'd be asking for
>>>> different derivations than the ones built by our build farm.

reply via email to

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