[bug#48314,v3] Install guix system on Raspberry Pi

> > guile-fibers are now fixed, but the cross compile build fails now on shepherd-0.9 due to guile-fibers not being available.
>
>
> Fixed as suggested by Maxime in commit
> 6e174c4edd4786d93c1e424c45052f70b2bb3fb0.
>
> Let us know what the next issue is. :-)
>
> Ludo’.

Thanks Maxime for the advice and for Ludo' for applying the change!

I've rebased the patches from Stefan and there are only two packages that don't cross-compile - nss-certs and ntp.

I attempted to do guix pull on Raspberry Pi 3, but it failed due to running of memory - I'll attempt to test it with a swap file/partition.

Or is it possible to do guix pull using a substitute so that the computation wouldn't be done locally? This offloading would be really great for these embedded platforms.


----
Petr

Hi,

phodina <phodina@protonmail.com> skribis:

> I've rebased the patches from Stefan and there are only two packages that don't cross-compile - nss-certs and ntp.
>
> I attempted to do guix pull on Raspberry Pi 3, but it failed due to running of memory - I'll attempt to test it with a swap file/partition.
>
> Or is it possible to do guix pull using a substitute so that the computation wouldn't be done locally? This offloading would be really great for these embedded platforms.

Normally you should be able to get substitutes, making ‘guix pull’
actually usable on these platforms.  But I’m not sure what the status is
on armhf-linux.  This platform needs love!

> From deab687c2b0540a944b48c68fa00cac4bac99b80 Mon Sep 17 00:00:00 2001
> From: Petr Hodina <phodina@protonmail.com>
> Date: Sat, 16 Apr 2022 10:22:14 +0200
> Subject: [PATCH 1/2] gnu: nss-certs: Support cross-compilation.
>
> * gnu/packages/certs.scm (nss-certs)[arguments]: Fix unresolved
>   variable - output.

I addressed this one differently to avoid rebuilding the 600+ packages
that depends on nss-certs.

> From 98ad94f6282d8ff3a244181ecc32946ea281aa03 Mon Sep 17 00:00:00 2001
> From: Petr Hodina <phodina@protonmail.com>
> Date: Sat, 16 Apr 2022 10:24:46 +0200
> Subject: [PATCH 2/2] gnu: ntp: Support cross-compilation.
>
> * gnu/packages/ntp.scm (ntp)[arguments]: Add configuration flag.

I added a comment explaining why this flag is needed and committed.

Should we close this issue now?

Thanks!

Ludo’.

> Hi,
>
> phodina phodina@protonmail.com skribis:
>
> > I've rebased the patches from Stefan and there are only two packages that don't cross-compile - nss-certs and ntp.
> >
> > I attempted to do guix pull on Raspberry Pi 3, but it failed due to running of memory - I'll attempt to test it with a swap file/partition.
> >
> > Or is it possible to do guix pull using a substitute so that the computation wouldn't be done locally? This offloading would be really great for these embedded platforms.
>
>
> Normally you should be able to get substitutes, making ‘guix pull’
> actually usable on these platforms. But I’m not sure what the status is
> on armhf-linux. This platform needs love!
>
> > From deab687c2b0540a944b48c68fa00cac4bac99b80 Mon Sep 17 00:00:00 2001
> > From: Petr Hodina phodina@protonmail.com
> > Date: Sat, 16 Apr 2022 10:22:14 +0200
> > Subject: [PATCH 1/2] gnu: nss-certs: Support cross-compilation.
> >
> > * gnu/packages/certs.scm (nss-certs)[arguments]: Fix unresolved
> > variable - output.
>
>
> I addressed this one differently to avoid rebuilding the 600+ packages
> that depends on nss-certs.
>
> > From 98ad94f6282d8ff3a244181ecc32946ea281aa03 Mon Sep 17 00:00:00 2001
> > From: Petr Hodina phodina@protonmail.com
> > Date: Sat, 16 Apr 2022 10:24:46 +0200
> > Subject: [PATCH 2/2] gnu: ntp: Support cross-compilation.
> >
> > * gnu/packages/ntp.scm (ntp)[arguments]: Add configuration flag.
>
>
> I added a comment explaining why this flag is needed and committed.
>
> Should we close this issue now?
>
> Thanks!
>
> Ludo’.

Thanks Ludo'!


Vagrant has valid points about the patches.

Stefan do you want to address them or shall I?

I can confirm the Raspberry Pi 3 can run Guix, but when I attempt to do simple `guix pull` it fails due to running out of memory (has just 1 GiB) therefore there is probably no point to run on less powerful boards.

Not sure if the computation can be offloaded by using substitutes.

It runs fine on Raspberry Pi 4 where there is 4GiB of memory (at least in my case :) - the variant with just one 1GiB would have probably same result as RPi3.

----
Petr

Hi Petr!

> Vagrant has valid points about the patches.
> 
> Stefan do you want to address them or shall I?

I have already patches to address the review comments from Vagrant, actually for months; also including improvements (e.g. checking that defconfig changes are successfully applied, which is not guaranteed).

Beside a lack of time, it is as you said: Building with 1 GB RAM is very problematic. Swap space is a requirement. Building takes days, using make with sub-targets helps a bit. In recent Linux kernels the virtual memory handling is badly broken; the build process gets killed, although there is empty swap space. Only version 5.4 is still fine. Without other hardware offloading or cross-building is not an option. Substitutes of guix, Linux, which needs special config settings, U-Boot and I think GRUB, are not – can’t be – available. Last time I tried at least qemu – an input of GRUB – had build issues on aarch64 and was missing a substitute. For Linux I meanwhile need to remove the deblob-check, as it even exhausts my swap space.

I’m hesitant to submit my untestet patches. I hope to find some time on the weekend – and that I don’t make mistakes, as my turn-around-time is close to a week. ;-)

By the way: I have the feeling that a garbage-collector may be a real bottle-neck, if most of a process’ memory is swapped out. I was surprised to not find papers about this. And once I was looking for options to limit the Guile heap, but didn’t find anything helpful.

> It runs fine on Raspberry Pi 4 where there is 4GiB of memory

This is good to know, thanks!

Would you mind, if I send untested patches, which you could pick up? Is there a possibility to offload to ci.guix.gnu.org? 


Bye

Stefan