Another Raspberry Pi data point

Another Raspberry Pi data point

[Richard Huxton]

I saw Jonathan Marsden's post the other day, but wasn't subscribed then, 
so this will have to be another data point.

I also have a Raspberry Pi 4, and it's quite a capable little machine. I 
run Debian bullseye (still in testing) for the host O.S. and lxd to 
provide container services.

Guix seems to work well for applications on top of both debian and 
alpine containers as the "foreign" O.S. There are fewer pre-built 
substitutes for 64-bit arm than x86 of course, but that is to be 
expected. Likewise, build-time can be a bit long on a Raspberry Pi.

I had some success in using `guix system container` to test some simple 
service setups and see how it worked. Not as slick as lxd (of course) 
but you could see the potential.

I had no success with building a vm or disk image - a build would take 
hours and then fail trying to assemble the boot subsystem, seemingly 
having switched to x86 architecture. This was despite all my debugging 
attempts seeming to show that the guile scripts were aware this was a 
64-bit arm architecture for most of their run.

My eventual aim was to try and create lxc/lxd containers via guix, but 
step 1 of that was to get a VM working. I shall have another attempt in 
a few weeks. Part of my problem may just be that I am unfamiliar with 
arm boot setups.

So - as of the start of 2021, on top of a foreign distro Guix works fine 
on a Raspberry Pi. If you are reading by the end of 2021 I suspect it 
will work in any of the scenarios described in the docs.

-- 
   Richard Huxton

Re: Another Raspberry Pi data point

[Leo Famulari]

On Wed, Feb 10, 2021 at 09:06:06PM +0000, Richard Huxton wrote:
> I saw Jonathan Marsden's post the other day, but wasn't subscribed then, so
> this will have to be another data point.

Thanks for the report!

> Guix seems to work well for applications on top of both debian and alpine
> containers as the "foreign" O.S. There are fewer pre-built substitutes for
> 64-bit arm than x86 of course, but that is to be expected. Likewise,
> build-time can be a bit long on a Raspberry Pi.

Substitute availability should start to improve somewhat, as we've made
some changes in the build farm that will avoid some "spurious" build
failures with aarch64. In the long run, we are hoping to acquire more
aarch64 hardware to match the growing demand.

> I had no success with building a vm or disk image - a build would take hours
> and then fail trying to assemble the boot subsystem, seemingly having
> switched to x86 architecture. This was despite all my debugging attempts
> seeming to show that the guile scripts were aware this was a 64-bit arm
> architecture for most of their run.

Hm, that's a bug :/

> My eventual aim was to try and create lxc/lxd containers via guix, but step
> 1 of that was to get a VM working. I shall have another attempt in a few
> weeks. Part of my problem may just be that I am unfamiliar with arm boot
> setups.

It might help if you shared the config.scm you used for creating your vm
images.

> So - as of the start of 2021, on top of a foreign distro Guix works fine on
> a Raspberry Pi. If you are reading by the end of 2021 I suspect it will work
> in any of the scenarios described in the docs.

Let's make it happen!

Re: Another Raspberry Pi data point

[Jonathan Marsden]

On Wed, Feb 10, 2021, at 20:14, Leo Famulari wrote:
> On Wed, Feb 10, 2021 at 09:06:06PM +0000, Richard Huxton wrote:

>> I had no success with building a vm or disk image - a build would take hours
>> and then fail trying to assemble the boot subsystem, seemingly having
>> switched to x86 architecture. ...

> Hm, that's a bug :/

Just knowing that is useful info!  I wasn't sure if it was "supposed" to work.
I have not found a list of which aarch64 SBC boards Guix System is supposed
to work on.  I'd love to see such a list, if one exists.  Even better If it includes 
links to a sample working operating system definition file for each board!

>> My eventual aim was to try and create lxc/lxd containers via guix, but step
>> 1 of that was to get a VM working. I shall have another attempt in a few
>> weeks. Part of my problem may just be that I am unfamiliar with arm boot
>> setups.

> It might help if you shared the config.scm you used for creating your vm
> images.

My attempt (which had a similar-seeming issue) was included at the end of 
my earlier message to this list, to which Richard is responding. It is at
https://lists.gnu.org/archive/html/help-guix/2021-02/msg00031.html and
the scm file is at the end of the message.

>> So - as of the start of 2021, on top of a foreign distro Guix works fine on
>> a Raspberry Pi. If you are reading by the end of 2021 I suspect it will work
>> in any of the scenarios described in the docs.

> Let's make it happen!

Yes!  So how can we help get there from here?  In the meantime, I have seen 
a response on Reddit in r/guix which pointed me to some (late 2020) work at 
https://issues.guix.gnu.org/44543 by Stefan and by Danny Milosavljevic, which 
is specific to Raspberry Pi booting.  A known working complete example 
operating system definition file for a Raspberry Pi, and any workarounds it 
needs (such as manually copying in a binary bootloader "blob"?) would be 
*really* helpful.  Is anyone able to share one on the list (or in that "issue")?

Many thanks, I am encouraged to see others interested in getting Guix System 
working on the Raspberry Pi!

Jonathan
--
Jonathan Marsden <jmarsden@fastmail.fm>

Re: Another Raspberry Pi data point

[Leo Famulari]

On Wed, Feb 10, 2021 at 10:34:17PM -0600, Jonathan Marsden wrote:
> Just knowing that is useful info!  I wasn't sure if it was "supposed" to work.
> I have not found a list of which aarch64 SBC boards Guix System is supposed
> to work on.  I'd love to see such a list, if one exists.  Even better If it includes 
> links to a sample working operating system definition file for each board!

Well, it's supposed to work in the sense that we build kernels and
bootloaders for aarch64, so Guix should be able to created images for
that platform too. I'm not sure if the code is supposed to create images
that match the host architecture, though, or for non-x86_64 at all. We
may need to do a little more work in this area.

Re: Another Raspberry Pi data point

[Jonathan Marsden]

On Thu, Feb 11, 2021, at 15:21, Leo Famulari wrote:
> On Wed, Feb 10, 2021 at 10:34:17PM -0600, Jonathan Marsden wrote:
>> Just knowing that is useful info!  I wasn't sure if it was "supposed" to work.
>> I have not found a list of which aarch64 SBC boards Guix System is supposed
>> to work on.  I'd love to see such a list, if one exists.  Even better If it includes 
>> links to a sample working operating system definition file for each board!

> Well, it's supposed to work in the sense that we build kernels and
> bootloaders for aarch64, so Guix should be able to created images for
> that platform too. I'm not sure if the code is supposed to create images
> that match the host architecture, though, or for non-x86_64 at all. We
> may need to do a little more work in this area.

As I understand it, aarch64 SBCs each have their own different, not yet 
standardized, boot processes, so unlike common x86-64 "PC" machines, there 
is a need for boot definition work that is board-specific. Knowing which SBCs 
have been tested and are known to boot Guix System, preferably with a sample 
OS definition file, would be valuable.

There is a recent list of 150 Linux-oriented SBCs at 

  http://linuxgizmos.com/files/Jan-2021-LG-SBC-Catalog-Rev-A.xls

However it doesn't indicate how well or badly these boards "respect your 
freedom", nor whether they can boot Guix System.

At the FSF end of things, the RYF product list doesn't seem to include *any* SBCs 
at all, from what I can see at https://ryf.fsf.org/products .  Maybe no SBCs are 
sufficiently free to qualify?  It looks like the EOMA68 Libre Taa Computer Card
might qualify.  https://www.crowdsupply.com/eoma68/micro-desktop

Is anyone currently booting Guix System on a small single board computer that 
they can share info about, and ideally share a sample Guix system OS .scm file 
definition for?

Regarding the Raspberry Pi specifically, how can we help with the work being 
done at https://issues.guix.gnu.org/44543 ?  Do the folks working on that already 
have Guix System booting on a Raspberry Pi ?

Jonathan

Re: Another Raspberry Pi data point

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

On 2021-02-11, Jonathan Marsden wrote:
> On Thu, Feb 11, 2021, at 15:21, Leo Famulari wrote:
>> On Wed, Feb 10, 2021 at 10:34:17PM -0600, Jonathan Marsden wrote:
>> Well, it's supposed to work in the sense that we build kernels and
>> bootloaders for aarch64, so Guix should be able to created images for
>> that platform too. I'm not sure if the code is supposed to create images
>> that match the host architecture, though, or for non-x86_64 at all. We
>> may need to do a little more work in this area.
>
> As I understand it, aarch64 SBCs each have their own different, not yet 
> standardized, boot processes, so unlike common x86-64 "PC" machines, there 
> is a need for boot definition work that is board-specific. Knowing which SBCs 
> have been tested and are known to boot Guix System, preferably with a sample 
> OS definition file, would be valuable.
...
> Is anyone currently booting Guix System on a small single board computer that 
> they can share info about, and ideally share a sample Guix system OS .scm file 
> definition for?

There's an example system configuration for veyron-speedy in:

  gnu/system/examples/asus-c201.tmpl

I'm not sure how well it is working out-of-the-box; last I checked it
only worked with linux-libre@5.4.

There's also one for pinebook-pro in the wip-pinebook-pro branch.


> Regarding the Raspberry Pi specifically, how can we help with the work being 
> done at https://issues.guix.gnu.org/44543 ?  Do the folks working on that already 
> have Guix System booting on a Raspberry Pi ?

The raspberry pi boards are exceptionally peculiar in how they boot
compared to other boards, and the free firmware is very limited if it
works at all still...


I've run guix on aarch64: pine64+, rockpro64-rk3399, rock64-rk3328,
  pinebook, pinebook-pro-rk3399, overdrive-1000, puma-rk3399

... and on armhf: novena, wandboard solo (painful and long ago), veyron-speedy

I've probably forgotten some others; too many to keep track of. :/


Other than pinebook, pinebook-pro and veyron-speedy, I've almost
exclusively run them headless on serial console. Usually with usb
ethernet and/or wireless adapaters, as the built-in ones typically
require non-free firmware.


Some general things I tend to do is use the linux-libre-arm-generic or
linux-libre-arm64-generic kernels, and configure the initrd with an
empty modules list, as these kernels usually have builtins for most of
the needed drivers. It is tricky to manually craft the right initrd
modules to load by hand (many have soft module dependencies on various
subsystems that are not easily discoverable). If guix supported an
initrd that would included nearly all the kernel modules and run
modprobe that would be a huge improvement and make it more plausible to
use the regular "linux-libre" kernel, and as a nice side-effect, almost
be able to use the same system configuration on multiple different
boards (bootloader aside).


I've not used guix on any of them for real world tasks, other than to
try and get guix running on them. :)


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

EDK2 support Was: Another Raspberry Pi data point

[raingloom]

On Thu, 11 Feb 2021 19:24:36 -0600
"Jonathan Marsden" <jmarsden@fastmail.fm> wrote:

> As I understand it, aarch64 SBCs each have their own different, not
> yet standardized, boot processes, so unlike common x86-64 "PC"
> machines, there is a need for boot definition work that is
> board-specific.

There is actually a standard-ish way: UEFI.
I've had some luck using EDK2 on my RPi 3 B+, but only with a third
party binary. It could indeed boot generic aarch64 Debian.
My channel has an old experimental and broken description of it, but
the licensing of the modules necessary to build EDK2 for the Pi3
specifically is unclear to me. Certainly some nonfree assets there, but
I'm not sure if they are all absolutely necessary, or if they are
actually binaries or just nonfree source code.

Channel:
https://git.sr.ht/~raingloom/guix-packages

Look in the raingloom/packages/bootloaders.scm

Re: Another Raspberry Pi data point

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 779 bytes --]

On Thu, Feb 11, 2021 at 07:24:36PM -0600, Jonathan Marsden wrote:
> 
> Is anyone currently booting Guix System on a small single board computer that 
> they can share info about, and ideally share a sample Guix system OS .scm file 
> definition for?
> 

Here's a link to my pine64 config. Some config options I've factored out
into other files in the repository, but I've included a stripped-down
version attached to this email. It will build no-problems from an
aarch64 machine, but will need to have some services removed to
cross-compile from x86_64.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: pine64.scm --]
[-- Type: text/plain, Size: 3765 bytes --]

(define-module (pine64))
(use-modules (guix packages)
             (gnu)
             (gnu bootloader u-boot)
             (gnu system locale)
             (srfi srfi-1))
(use-service-modules
  linux
  networking
  ssh)
(use-package-modules
  certs
  connman
  linux)

(operating-system
  (host-name "pine64")
  (timezone "Asia/Jerusalem")
  (locale "en_US.UTF-8")
  (locale-definitions
    (list (locale-definition (source "en_US")
                             (name "en_US.UTF-8"))
          (locale-definition (source "he_IL")
                             (name "he_IL.UTF-8"))))

  (bootloader (bootloader-configuration
                (bootloader u-boot-pine64-plus-bootloader)
                (target "/dev/mmcblk0")))   ; SD card/eMMC (SD priority) storage

  (initrd-modules '())
  ;; The board fails to boot with stock linux-libre
  (kernel linux-libre-arm64-generic)

  (swap-devices (list "/swapfile"))

  (file-systems (cons* (file-system
                         (device (file-system-label "root"))
                         (mount-point "/")
                         (type "ext4"))
                       %base-file-systems))

  (users (cons (user-account
                (name "efraim")
                (comment "Efraim")
                (group "users")
                (supplementary-groups '("wheel"
                                        "netdev" "kvm"))
                (home-directory "/home/efraim"))
               %base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (cons* nss-certs         ;for HTTPS access
                   %base-packages))

  (services (cons* (service guix-publish-service-type
                            (guix-publish-configuration
                              (host "0.0.0.0")
                              (port 3000)))

                   (service openssh-service-type
                            (openssh-configuration
                              (x11-forwarding? #t)
                              (extra-content "StreamLocalBindUnlink yes")))

                   (service tor-service-type)
                   (tor-hidden-service "ssh"
                                       '((22 "127.0.0.1:22")))
                   (tor-hidden-service "guix-publish"
                                       '((3000 "127.0.0.1:3000")))

                   (service openntpd-service-type
                            (openntpd-configuration
                              (listen-on '("127.0.0.1" "::1"))
                              ;; Prevent moving to year 2116.
                              (constraints-from '("https://www.google.com/"))))

                   (service connman-service-type)
                   (service wpa-supplicant-service-type)

                   ;; Needs no-manual version, depends on pandoc.
                   (service earlyoom-service-type
                            (earlyoom-configuration
                              (earlyoom
                                (let ((base earlyoom))
                                  (package
                                    (inherit base)
                                    (native-inputs
                                      (alist-delete "pandoc"
                                                    (package-native-inputs base))))))))

                   ;; Not supported by linux-libre-arm64-generic
                   ;(service zram-device-service-type
                   ;         (zram-device-configuration
                   ;           (size (* 2 (expt 2 30)))
                   ;           (compression-algorithm 'zstd)
                   ;           (priority 100)))

                   %base-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Another Raspberry Pi data point

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Mon, Feb 15, 2021 at 12:02:45PM +0200, Efraim Flashner wrote:
> On Thu, Feb 11, 2021 at 07:24:36PM -0600, Jonathan Marsden wrote:
> > 
> > Is anyone currently booting Guix System on a small single board computer that 
> > they can share info about, and ideally share a sample Guix system OS .scm file 
> > definition for?
> > 
> 
> Here's a link to my pine64 config. Some config options I've factored out
> into other files in the repository, but I've included a stripped-down
> version attached to this email. It will build no-problems from an
> aarch64 machine, but will need to have some services removed to
> cross-compile from x86_64.
> 

Forgot the link
https://git.sr.ht/~efraim/guix-config/tree/master/pine64.scm

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]