bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

On Mon, 23 May 2022 16:10:04 +0200
Maxime Devos <maximedevos@telenet.be> wrote:

> Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 15:40 [+0200]:
> > Hi,
> > 
> > I've now made some free space. So we have:
> > - 1GiB of RAM and 16GiB of swap:
> >   > # cat /proc/swaps 
> >   >
> > Filename                            Type
> > Size Used           Priority
> >   > /dev/mmcblk0p1                         
> > partition   16777212        16384           -2
> 
> Could you check if it OOMs (with "sudo dmesg")?
> There were some problems in the past (maybe present too?) on i?86 with
> too much memory usage,
I've looked rapidly and I didn't see any OOMs. I've now used dmesg -c
and I'll launch the following command:
> guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52 -M 1 -c 1

And I'll see if it fails in the same way.

I also use a custom kernel and while I'm confident that the code
modifications have no impact here, I'm unsure if there are compilation
options related to OOM messages or not.

And here I probably lack some knowledge but I was under the impression
that swap was handled transparently by the kernel (through page tables,
virtual memory, and so on), so applications should not notice the
difference apart from the huge performance drop.

Though one issue could be that maybe for some reason the process wants
to use more than 3GiB of memory and at least i686 processes are limited
to 4GiB if you use an x86_64 kernel and about 3GiB if you use an i686
kernel. So maybe it's somehow similar for armv7h?

I also use Guix on an i686 installation of Parabola on my x86 laptop,
and I had issues with that in the past but recently I didn't notice
issues so at least if they are still there they are less frequent.

Maybe the difference is that on this ARM computer, I installed Guix
1.3.0 recently, and I didn't manage to do a guix pull that work yet, so
there is more diff between the current state (1.3.0) and where it wants
to go (close to HEAD on the master branch).

As of why a bigger diff would increase the probability of it failing
I've no idea.

What I could do could be to try to reproduce on an i686 Parabola VM,
this way it would be easier for people to reproduce. Though it's not
possible yet to pacstrap Parabola installations from Guix (I've some
WIP code for that but I need to fix bugs in it before being able to
send it).

Denis.

pgpDl6BPomPLH.pgp
Description: OpenPGP digital signature