[PATCH] Install guix system on Raspberry Pi

Hi!

This patch series adds support for the Raspberry Pi. It allows to use ‘sudo -E guix system init … /mnt’ with the root partition mounted at /mnt and the boot partition mounted at /mnt/boot/efi, as you would expect it for a PC with UEFI. Installing for netboot is possible as well.

It is currently not possible to build an image with this patch series, because of the intercepting handling for efi system image creation.

Some of these patches are generic and not related to the Raspberry Pi. I hope they will be a useful contribution for everyone.

Here is a quick overview of the single patches:

01: Disable the tests on aarch64 for qemu-minimal, because it is non-deterministic but needed to build grub.

02: Rework the grub-efi-netboot-bootloader and add a grub-efi-netboot-removable-bootloader which then are pre-installed. This allows a simplification of the efi-bootloader-chain, as these pre-installed bootloaders just need to be copied and can therefore easily be collected in a bootloader-profile.

03: A new build-side module to modify a defconfig. It is used to customize U-Boot and Linux packages.

04: Customized and pre-installed U-Boot packages for the Raspberry Pi.

05: Fixed the EXTRAVERSION variable used to build Linux, so that the extra-version argument will be visible with uname.

06: New function to modify a Linux package by using another defconfig and/or adding or removing configurations.

07: Raspberry Pi specific defconfig objects.

08: Some helpers to construct config.txt files for the Raspberry Pi firmware.

09: A function to create a package with device-tree files from a Linux package for the Raspberry Pi.

10: A bootloader for the Raspberry Pi. Additionally two examples of operating-system definitions to boot from local storage or over network, the latter is making necessary configuration changes to Linux.

The firmware topic is excluded. In the same way that guix assumes that some UEFI firmware is already present on a PC, this patch series assumes that a firmware to start U-Boot is already present.

The grub bootloaders are usable on PCs as well. In contrast to the normal grub-efi, all grub files are copied to the EFI system partition, instead of the root partition. This is a side effect of the netboot capability. Maybe this is helpful for some spacial cases. I realized for example that the normal grub-efi locates the partition containing the grub.cfg by a device name like (hd0,gpt1), this may be problematic when adding disks to a system. The new grub bootloaders determine the partition by UUID.

The new possibility to customize Linux with (modify-linux) will be useful for anyone in need to do small configuration changes. There is also the possibility to pass an own defconfig file to this function. It can either be the name of a defconfig file from the Linux sources, or it can be a file-like object, like produced by (local-file) or possibly downloaded with the new (make-defconfig) function.

Bye

Stefan

Hi!

There were errors in the patches 05 and 06 in the EXTRAVERSION handling and in the modify-linux function.

Here an updated patch series. They apply to commit f661e6883ec345258634940ce5d52957e1bb90c3.

Bye

Stefan

Hi Stefan,

Thanks!

Pushed 05-gnu-linux-correct-name-of.patch to guix master as commit b04cba9ee533945f90ffd72637f064c60188f945.

(I've also started testing the other patches of this patchset, but it will take a while)

Hi Stefan,

Since bug 43534 is closed, does that mean I can drop patch 01-gnu-qemu-disable-tests-on.patch ?

Hi Stefan,

In 04-gnu-bootloader-add-u-boot.patch, I think that having #:name is too magical

(it still only replaces part of the package name, and then still only after

substitution). But if made non-magical, then it has too little benefit.

Likewise for #:description.

If it's alright with you, can we just drop #:name xxx and #:description xxx

altogether and instead do:

(define-public u-boot-rpi-3-efi

(package

(inherit

(make-preinstalled-u-boot-package

"rpi_3_32b"

"arm-linux-gnueabihf"

#:name "rpi-3-efi"

#:configs %u-boot-rpi-efi-configs

#:description %u-boot-rpi-efi-description-32-bit))

(name "u-boot-rpi-3-efi")

(description %u-boot-rpi-efi-description-32-bit)))

And similar for all the other u-boot definitions, and for

the usage of make-u-boot-package inside make-preinstalled-u-boot-package ?

Or are there upsides to doing it like you did it?

I'm aware that the same can be said for "board" ... which is used already.

However, that parameter is also used for something else, so it needs to be there.

NAME isn't used for anything else but for doing what a regular package inherit

could do anyway. Is there a downside when using package inherit?

Hi Mark,

Hi Leo,

could you look at 06-gnu-linux-new-function-to.patch of this patchset?

It provides the user a means of (slightly) editing kernel configs using a

high-level interface, called "modify-linux".

What do you think?

@Stefan: On the other hand, I'm not sure of the general utility of make-defconfig.

I've never needed something like it in decades. Is it worth exporting as public

from (gnu packages linux) ? Sounds like a too weird special case to have general

utility.

Hi Danny!

Yes.

On the other side I have a bad experience with qemu substitutes for aarch64 and building qemu on a Raspberry takes a night and then still fails during the test. I hope the substitute situation improves, otherwise this patch should still be considered.

Bye

Stefan

Hi Danny!

That’s OK.

Bye

Stefan

Hi!

There is currently no simple way change the Linux configuration. Also by modifying the final .config as of today (which kind of contains all CONFIG_…-variables), as far as I know dependencies will not be resolved and conflicting configurations can easily happen.

A defconfig however gets striped down to a minimum of required CONFIG_…-variables and all “missing” ones get either default values or get determined through dependecies. So adding /removing/changing some few configurations to a defconfig is less error-prone. Further defconfig files are easier to maintain in git. There is a reason that only defconfig files are maintained in the Linux sources.

Please note that the patch allows to select a defconfig file from the Linux sources (if the parameter is a string), and also to provide an own defconfig file (if it is a file-like object).

Well, there is the need already in Guix to have e.g. the predefined linux-libre-arm64-generic kernel, wich just uses a certain defconfig file from the Linux sources. But this possibility is not exported.

There are many defconfig files for all sorts of boards, especially for arm32. Why shouldn’t we allow to use any of these? Why should users be restrict to “selected” configurations? Why should Guix’ kernel configuration be preferred over the plain x86_64_defconfig?

And take a look at the last patch: In order to make that kernel boot on a Raspberry from an NFS root, some few configurations are missing, which can easily be added with the “modify-linux” function. By the way, maybe “customize-linux” would be a better name.

And there is another patch from me to make the NFS root test pass. As the Linux kernel build by Guix is not able to boot over NFS root in qemu, I used the same function there to add the missing configurations.

Oh, and finally, I need the same underlying kconfig.scm and a similar defconfig modification for U-Boot as well, which allowed me to simplify the existing U-Boot packages.

Bye

Stefan

Hi Danny!

Are there any news on this topic¹?

Bye

Stefan

¹ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48314

Hi!

I did a rebase of the patch series to avoid bit-rotting. One patch got obsolete meanwhile.

This series applies on GIT commit 1a80b8909a521b91d30649a011b0257d0fadc18c.

Bye

Stefan

tags 47744 + patch

tags 48314 + patch

block 47744 by 48314

retitle 48314 [PATCH] Install guix system on Raspberry Pi

retitle 47744 [PATCH] nfs-root test is failing

quit

Hi Ludovic!

Just for your information: The nfs-root test is kind of fixed, it was once blocking some other issue that you linked.

Bye

Stefan

On 2021-10-31, Stefan wrote:

And still applies on master as of

193d7b5b450d2004c26720e488a9cce930542e9e :)

keyword parameters 'name' and 'description'.

...

(u-boot-rpi-0-w, u-boot-rpi, u-boot-rpi-2, u-boot-rpi-3,

u-boot-rpi-4, u-boot-rpi-64, u-boot-rpi-0-w-efi, u-boot-rpi-efi,

u-boot-rpi-2-efi, u-boot-rpi-3-efi, u-boot-rpi-4-efi, u-boot-rpi-efi-64): New

packages.

The u-boot-rpi-0-w and u-boot-rpi variants are ARMv6 boards, and Guix's

armhf baseline is ARMv7, so those won't work with guix system. Are there

other use-cases for providing u-boot builds for these boards?

Upstream provides defconfigs for these variants:

armv6 variants (unsupported on guix's armhf, maybe other use-cases?):

rpi_0_w

rpi

armhf-capable variants:

rpi_2

rpi_3_32b

rpi_4_32b

aarch64 variants:

rpi_3

rpi_3_b_plus

rpi_4

rpi_arm64 (supports rpi 3 and 4 variants?)

+(define-public u-boot-rpi-3

+ (make-preinstalled-u-boot-package

+ "rpi_3_32b"

+ "arm-linux-gnueabihf"

+ #:name "rpi-3"

+ #:description %u-boot-rpi-description-32-bit))

I would name this "u-boot-rpi-3-32b"

+(define-public u-boot-rpi-4

+ (make-preinstalled-u-boot-package

+ "rpi_4_32b"

+ "arm-linux-gnueabihf"

+ #:name "rpi-4"

+ #:description %u-boot-rpi-description-32-bit))

And this "u-boot-rpi-4-32b".

+(define-public u-boot-rpi-64

+ (make-preinstalled-u-boot-package

+ "rpi_arm64"

+ "aarch64-linux-gnu"

+ #:name "rpi-64"

+ #:description %u-boot-rpi-description-64-bit))

And this "u-boot-rpi-arm64".

In other words, keep names consistent with the upstream defconfig they

are based on.

I presume you didn't add the aarch64 rpi_3 and rpi_4 variants because

they are supported by rpi_arm64?

I think without addressing the rest of the patch series, adding to guix

master the following packages could make the remaining diff smaller:

u-boot-rpi-2 (rpi_2_defconfig)

u-boot-rpi-3-32b (rpi_3_32b_defconfig)

u-boot-rpi-4-32b (rpi_4_32b_defconfig)

u-boot-rpi-arm64 (rpi_arm64_defconfig)

We wouldn't have a relevent installation configuration, but at least it

would allow building them and manually copying u-boot.bin to the

firmware partition...

live well,

vagrant

On 2021-10-31, Stefan wrote:

...

keyword parameters 'name' and 'description'.

(make-preinstalled-u-boot-package): New function to make minimal packages.

+(define*-public (make-preinstalled-u-boot-package board

+ triplet

+ #:key

+ defconfig

+ configs

+ name

+ description

+ (u-boot-file "u-boot.bin"))

+ "Returns a package with a single U-BOOT-FILE for BOARD cross-compiled for

+TRIPLET with the optional DEFCONFIG file and optional configuration changes

+from CONFIGS. Either NAME, if used, or otherwise BOARD will be part of the

+package name. DESCRIPTION will be appended to the package description."

u-boot-file appears to be hard-coded; there may be other boards which

use a different u-boot artifact. Also, why return a single file, rather

than just building a package and then allowing other functions to pick

the appropriate file out of the resulting package?

I wondered "why does it have to be cross-compiled" but then realized

that came from the existing make-u-boot-package function. I've mostly

been building u-boot natively these days. :)

live well,

vagrant

On 2021-11-13, Vagrant Cascadian wrote:

...

...

Patch that builds, but haven't tested on an actual board (do have rpi2

and rpi3b+ could test sometime):

On 2021-10-31, Stefan wrote:

This is surely a matter of opinion, but CONFIG_BOOTDELAY=0 is kind of

nasty; it makes it nearly impossible to debug from a u-boot prompt if

needed. The default is probably "2" ... long enough to actually

interrupt it, but short enough that it shouldn't cause huge delays in

the boot process...

I know grub-efi will add it's own delay, so in a working environment,

this just seems like an additional two seconds, but u-boot's EFI

implementation is changing often enough that I wouldn't be surprised if

you need to occasionally debug something.

live well,

vagrant

Hi Stefan,

I've attempted to cross compile the system on x86_64 machine and I must report here are still several issue.

- Firstly it has to be attempted off the branch core-updates as there is the latest packaged meson build system which allows cross compilation.

guix system: error: gnu/packages/glib.scm:172:2: glib@2.62.6: build system `meson' does not support cross builds

Note that a minor issue happens when applying your patches on top of core-updates is patch-04 failing due to collision in the header with your email address.

- Secondly there are some packages that need to be patched. See the attached file.

- Thirdly there is some issue in the optional test cases in the package lsof which fail if executed on btrfs (unfortunately that's my case so I disabled them, just the optional part).

If I apply all the changes I can build the system.

- However, that brings me to the last issue. There is a package efivar which does not build. The issue there is described here [1].

Then again I haven't actually ran the system on Raspberry Pi itself. I'll attempt to setup Debian and build it natively as you suggested.

Kind regards

Petr

PS: Sorry Stefan for the late answer

[1]: https://github.com/rhboot/efivar/issues/186

Hi,

I've rebased the patches to latest master and fixed some conflicts.

However, I'm unable to build the system on my Pinebook (aarch64 for native build).

./pre-inst-env guix system build gnu/system/examples/raspberry-pi-64.tmpl

substitute: updating substitutes from 'https://ci.guix.gnu.org'...substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%

substitute: updating substitutes from 'https://bordeaux.guix.gnu.osubstitute:updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%

The following derivation will be built:

/gnu/store/p50i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv

building /gnu/store/p50i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv...

ice-9/read.scm:126:4: In procedure read-expr*:

/gnu/store/9gxgha6r0ab5g44mnb3rgyjkrhc709rq-linux-libre-arm64-generic-5.16.19-builder:1:3290: Unknown # object: "#<"

builder for `/gnu/store/p50i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv' failed with exit code 1

build of /gnu/store/p50i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv failed

View build log at '/var/log/guix/drvs/p5/0i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv.gz'.guix system: error: build of `/gnu/store/p50i4lk8ajcgrgz8m11vqifvh4ggin2w-linux-libre-arm64-generic-5.16.19.drv' failed

Unfortunately the build log is not helpful uncovering the cause (at least to me).

I've also attempted to cross-compile the system (from x86_64) but there is at least one package that can't be build - guile-fibers-1.1.0. I've attached the build log as well.

Kind regards,

Petr

The issue about guile-fibers has already been reported by Mathieu in https://issues.guix.gnu.org/54793.

phodina via Guix-patches via schreef op do 14-04-2022 om 07:38 [+0000]:

To get rid of the #< error, replace this by

#~(modify-phases #$phases [...])

(and replace the , by #$ etc).

Greetings,

Maxime.

Thanks for the suggestion Maxime. Here's patch with fixes where I attempt to rewrite the section of the code using Gexps.

Still it ends in error as there is some mistake in the Gexps I made.

$ ./pre-inst-env guix system build gnu/system/examples/raspberry-pi-64.tmpl

;;; note: source file /home/cpethod/guix/gnu/packages/linux.scm

;;; newer than compiled /home/pethod/guix/gnu/packages/linux.go

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%

substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%

The following derivation will be built:

/gnu/store/zvy703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv

building /gnu/store/zvy703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv...

ice-9/psyntax.scm:2794:12: In procedure syntax-violation:

Syntax error:

/gnu/store/2xjp40qfmrdjg28zqsd919cjg00n9wrv-linux-libre-arm64-generic-5.16.19-builder:1:3387: source expression failed to match any pattern in form (let* ((srcarch #{$#}# (system->linux-srcarch (or (%current-target-system) (%current-system)))) (configs (string-append "arch/" srcarch "/configs/")) (guix_defconfig (string-append configs "guix_defconfig"))) #{$#}# (cond ((not defconfig) $~ (begin (apply (assoc-ref #{$#phases}# (quote configure)) arguments) (invoke "make" "savedefconfig") (rename-file "defconfig" guix_defconfig))) ((string? defconfig) $~ (rename-file (string-append configs #{$#defconfig}#) guix_defconfig)) (else (quote (copy-file (assoc-ref inputs "guix_defconfig") guix_defconfig)))) (modify-defconfig guix_defconfig (quote #{$#configs}#)) #{$#@}# (if extra-version $~ ((setenv "EXTRAVERSION" #{$#}# (string-append "-" extra-version))) (quote ())) (invoke "make" "guix_defconfig"))

builder for `/gnu/store/zvy703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv' failed with exit code 1

build of /gnu/store/zvy703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv failed

View build log at '/var/log/guix/drvs/zv/y703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv.gz'.

guix system: error: build of `/gnu/store/zvy703ldgicckqgnggsnz0a21394hb9f-linux-libre-arm64-generic-5.16.19.drv' failed

----

Petr

phodina schreef op do 14-04-2022 om 09:25 [+0000]:

it's #$, not $#

likewise

in this case #~

#$

#~ and #$

#$@

#~

#$

Greetings,

Maxime.

Thanks Maxime,

sorry for silly mistake.

Here are the updated patches. The last changes are part of the 4th patch in the patch set.

After build I installed it to the SD card using following command:

sudo -E ./pre-inst-env guix system init gnu/system/examples/raspberry-pi-64.tmpl /mnt

However, I experience an issue when login into the system. I can get there using my SSH key, but it seems the passwd set-uid binary is missing from the profile:

$ ssh pi@192.168.1.181

You are required to change your password immediately (administrator enforced).

WARNING: Your password has expired.

passwd: no such file or directory

I understand that the password is not set and the account is accessed through SSH so it asks after login to change it. How come it's possible to change it? I tried to add shadow into the packages, but the error said, it's already part of the system, so my guess is that it's just missing in the PATH variable. Could it be due to the fact it's present in /run/setuid-programs?

----

Petr

Here's more details about the login issue.

I've chrooted into the SDcard and setup the password for the pi user manually.

Then booted the board and login:

~$ ssh pi@192.168.1.181

Last login: Thu Apr 14 14:52:56 2022 from 192.168.1.224

Could not chdir to home directory /home/pi: Permission denied

-bash: /home/pi/.bash_profile: Permission denied

-bash-5.1$ id -u

1002

-bash-5.1$ id -gn

users

-bash-5.1$ sudo -E /gnu/store/ja92d7xpmyh94gm6n83bajx9dy4h6pbl-bash-5.1.8/bin/bash

root@raspberrypi-guix /# ls -al /home/pi

total 40

drwx------ 4 1000 users 4096 Nov 24 08:16 ./

drwxr-xr-x 4 root root 4096 Jan 1 1970 ../

-rw-r--r-- 1 1000 users 85 Jan 1 1970 .bash_profile

-rw-r--r-- 1 1000 users 834 Jan 1 1970 .bashrc

drwxr-xr-x 3 1000 users 4096 Jan 1 1970 .config/

-rw-r--r-- 1 1000 users 235 Jan 1 1970 .gdbinit

-rw-r--r-- 1 1000 users 789 Jan 1 1970 .guile

drwxr-xr-x 2 root root 4096 Nov 24 08:16 .ssh/

-rw-r--r-- 1 1000 users 47 Jan 1 1970 .Xdefaults

-rw-r--r-- 1 1000 users 62 Jan 1 1970 .zprofile

As you can see the execute bit is missing. Therefore running

chmod +x /home/pi/

fixed the problem. But I'm unsure why the home dir was created without the those flags.

Is it a side effect of using the following declaration?

(home-directory "/home/pi")

----

Petr

phodina schreef op do 14-04-2022 om 13:03 [+0000]:

You are logging in as 1002. /home/pi is owned by ‘1000’.  Is this

difference intentional?

Maybe you have added two users, but with the home directory?

(guesswork).

The user has the read-write-execute bits, the group and other don't.

I'm not on Guix System at the moment, so I cannot tell what the usual

behaviour is, but why wouldn't the home directory be non-group-

executable and non-other executable? 

Unless you want to share the contents of your home to other users on

the system, or if you have a web server that looks for

http://.../~pi/index.html in /home/pi/web/index.html or the like,

restricting readability, writability and executability to the actual

‘owner’ of the directory seems good security practice to me.

Usually, AFAICT, all that's needed is for $HOME to be user-readable,

writable and executable.

(/me quickly does "chmod go-rwx $HOME")

Greetings,

Maxime.

phodina schreef op do 14-04-2022 om 12:23 [+0000]:

I don't know what's going in here, though the ‘passwd not in $PATH’

seems a plausible hypothesis to me.

Greetings,

Maxime.

phodina via Guix-patches via schreef op do 14-04-2022 om 07:38 [+0000]:

This one should now be fixed by

1f82602153 gnu: guile-fibers@1.1: Support cross-compilation.

Greetings,

Maxime.

Yes,

guile-fibers are now fixed, but the cross compile build fails now on shepherd-0.9 due to guile-fibers not being available.

Also the NTP requires this configure flag.

On 2022-04-14, phodina@protonmail.com wrote:

Comments from November are still relevent:

https://issues.guix.gnu.org/48314#12

(e.g. drop drop u-boot-rpi-0-w*, u-boot-rpi, u-boot-rpi-efi, maybe

consider droping u-boot-rpi-2* and the 32-bit variants for rpi3 and

rpi4, as armhf is not well maintained at the moment).

Basically, ARMv6 is not supportable by guix, ARMv7 is poorly supported

in the armhf architecture, and ARMv8 is capable of running aarch64

(a.k.a. arm64):

https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

Only proposing aarch64 variants would pretty much leave you with

rpi-arm64. The EFI variants and 32-bit variants supported on armhf could

be easily added later once the other patches land.

See comment:

https://issues.guix.gnu.org/48314#15

e.g. Please do not set BOOTDELAY=0. It makes it nearly impossible to

debug. For people who want to live on the edge, they could build custom

variants and set it to 0.

Please keep package names consistent with defconfig

name. (e.g. u-boot-rpi-arm64). It's confusing enough without extra newly

invented names! :)

Ditto, or drop this variant; same for the 32-bit rpi-4 variants.

...

I like how this simplifies the package definitions where you need to

adjust the defconfig!

This particular workaround for u-boot-pinebook may no longer be needed,

thanks for the reminder to check.

Maybe this is different in upstream u-boot, but in the past setting it

to an empty value could result in the default value, which is why:

... was used previously.

Similar to my comments on u-boot variants, some of these are for models

that are not supportable on guix (rpi, rpi-0), so probably best to leave

out entirely, and the 32-bit variants for armhf are debatable at this

point.

live well,

vagrant

phodina schreef op do 14-04-2022 om 15:53 [+0000]:

Possibly the problem is just that guile-fibers is only in 'inputs' and

not 'native-inputs' -- due to how compilation and the module system

works in Guile, they need to be in both.

Greetings,

Maxime.

Hi,

phodina <phodina@protonmail.com> skribis:

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:

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!

I addressed this one differently to avoid rebuilding the 600+ packages

that depends on nss-certs.

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!

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.

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

On 2022-04-14, Vagrant Cascadian wrote:

Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and

2021.04 rpi-arm64 fails to boot on rpi3b+ ... but does work with the

rpi_3 and rpi_3_b_plus defconfigs... so I guess that makes a case for

having multiple variants, even if rpi_arm64 theoretically supports all

the arm64 boards... hrm.

That said, now that I've been able to test it; I feel confident at least

adding a simple u-boot-rpi-3 and/or u-boot-rpi-3-b-plus package (without

most of the proposed changes). Even though I haven't been able to test

u-boot-rpi-arm64, might be worth adding just to get it out of the way.

I could also test booting the rpi2 variants, though as mentioned

earlier, I'm skeptical about adding more support until things improve

for armhf on guix.

live well,

vagrant

Hi Vagrant!

IWithin my patch series there is one patch to modify a defconfig file. I enhanced that patch meanwhile to check, that lines in the modified defconfig show up in the final .config file. Last weekend I found out that several settings differ. I also updated the raspberry specific defconfigs, but the mismatches still remain.

My guess is, that the kernel has problems booting. Did GRUB show up?

Please wait a bit longer, I addressed all your comments to U-Boot already.

Bye

Stefan

On 2022-04-28, Stefan wrote:

Look forward to seeing an updated patch series!

I didn't test with grub, just the syslinux-style menus, but it didn't

even get as far as u-boot on the serial console with

rpi_arm64_defconfig. With either rpi_3_defconfig or

rpi_3_b_plus_defconfig, it worked just fine.

I had to set gpu_freq=250 in config.txt, which is a bit of a known

issue:

https://github.com/raspberrypi/firmware/issues/553

I really don't see the harm in it, and actually see considerable benefit

to making a smaller diff for review as it is a huge patch series, but

I'm not planning on actually using guix on any rpi hardware anytime

soon, so... ok.

live well,

vagrant

Hi Stefan,

do you need help with the patches?

Also should we provide some patches to the upstream kernel in Guix? [1]

[1] https://github.com/lategoodbye/rpi-zero/issues/43

----

Petr

Hi Vagrant!

Uups. I will remove them.

OK

Yes.

Well, in the past I tried to get one patch into master before sending the next for review. Doing so I got the comment that it would be hard to test the changes, as they are not complete and don’t build a system. :-)

For the same board name there will be two packages, the “normal” and an EFI variant. Having name-suffix and additional-description fields eases appending. I will change the parameters accordingly. Having these parameters also avoids to copy the U-Boot description, like done for the boneblack. A while back you fixed that description three times. :-)

Bye

Stefan

Hi Vagrant!

If you build U-Boot, there is also u-boot-nodtb.bin. Therefore the u-boot-file is a function argument to the public make-preinstalled-u-boot-package to allow a selection.

The reason is in the patch set 1: There is (already in master) a bootloader-profile which is able to collect a chain of bootloaders. The version in master allows a collection of files from packages, but requires a special installer. I figured out that the usage of the bootloader-profile gets much easier if the packages to chain only contain preselected files. From a user perspective the content of a complete bootloader-package is kind of a blackbox. When writing an operating-system configuration it is easy to figure out the right U-Boot package name, but no one expects to be required to install U-Boot in his profile to figure out that the u-boot.bin is below the libexec directory and that he is even required to care about moving the file around in directory hierarchies.

However, you are right that the make-preinstalled-u-boot-package could take another U-Boot package as argument, being that other function to pick the appropriate file. Then it might be useful for other boards, too. The only trouble to solve then is a proper package name. Currently using make-preinstalled-u-boot-package the result of make-u-boot-package is only an intermediate package prefixed with “-complete”. Then a preinstalled package needs a suffix like “-bin”. I think this makes sense, I will change it.

Yes, that’s right, it is a copy from the other function. It will be gone with the re-work.

Me too, exclusively. :-)

Bye

Stefan

Hi Vagrant!

During all the months of work to get Guix System booting over network with U-Boot and GRUB, there was no need for me to play around on the U-Boot prompt. I was even affected by a bug¹ preventing U-Boot to detect my keyboard at all. The actual problem with that bug was not that the U-Boot prompt was unusable, but that GRUB relies on the keyboard functionality of U-Boot, so I couldn’t debug boot problems e.g. due to kernel argument problems in GRUB.

Well, in this constellation U-Boot just needs to find and load the efi/boot/bootaa64.efi file. It doesn’t need to load device-tree files or care for overlays. It doesn’t need to load other stuff like SPL or other images. Its only purpose is to impose an EFI interface and to load GRUB. So the benefit of the U-Boot prompt is quite limited.

Also other distributions like openSUSE use U-Boot as EFI firmware, so I think the basic EFI functionality is tested quite well. My preference is to not bother pure users with a delayed boot time. However, I changed it to CONFIG_BOOTDELAY=1.

Bye

Stefan

¹ https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux

Hi!

Sorry for tho long period of silence.

Actually not with the patches, but with building and testing.

I was affected by the lack of substitutes for aarch64. Building with only 1 GB RAM and swap space is a pain.

For building Guix I figured out that building only sub-targets like make-core-go, make-packages-go, etc. helps. But this way I missed to do a “make all” and was wondering a lot and for long time about errors because silently a wrong /gnu/stor/…-guix-module-union/ got used.

I have a set of patches to fix or disable tests, just because of too less RAM, too less computing-power and an NFS root file-system.

Currently one test of glib is failing. So I can’t proof that my patches lead to a working system on current Guix.

I’m far from a point to care for patches to the kernel. I’d be glad, if the linux-libre kernel is able to run a minimal Guix System. :-)

Bye

Stefan

On 2022-07-17, Stefan wrote:

...

So if it does not find that one file, what do you do?

Sure, it has improved greatly.

Well, from my perspective, this is obviously significantly less bad that

0 seconds...

In general, it is my understanding that Guix prefers to go with upstream

defaults, unless there is a strong argument otherwise. I do not

personally see this as warranting a difference from upstream defaults to

gain 1 or 2 seconds of boot time.

live well,

vagrant

Hi Vagrant!

Valid point. Actually I would have copied back a working U-Boot version from the NFS server side. ;-)

Would you mind removing that line if committing?

Bye

Stefan

Hi!

A new patch series based on 7558417360d2ae011ec23197c75ef8e411558810. I tried to apply all review comments.

Bye

Stefan

Thanks Stefan for the updated patches!

I've applied them and build the system. However,

I'm unable to test the system as there is an error when invoking `guix system init` command:

$ sudo -E ./pre-inst-env guix system init --target=aarch64-linux-gnu gnu/system/examples/raspberry-pi-64.tmpl /mnt

/gnu/store/hhb5l2f5287xmfzz4jgvi15kb9bcqi33-system

/gnu/store/fiq006ykhc0dkninzz5gxl2nh3vzc37p-grub.cfg

initializing operating system under '/mnt'...

copying to '/mnt'...

populating '/mnt'...

guix system: error: symlink: Operation not permitted: "/boot/efi/gnu/store"

$ sudo fdisk /dev/mmcblk0

Welcome to fdisk (util-linux 2.37.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.

It's recommended to umount all file systems, and swapoff all swap

partitions on this disk.

Command (m for help): p

Disk /dev/mmcblk0: 29.12 GiB, 31267487744 bytes, 61069312 sectors

Disk model: 1081CS0

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type

/dev/sda1 2048 526335 524288 256M 83 Linux

/dev/sda2 526336 61069311 60542976 28.9G 83 Linux

$ mount

/dev/mmcblk0p2 on /mnt type ext4 (rw,relatime)

/dev/mmcblk0p1 on /mnt/boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

I have these 2 remarks:

1) Why does it point to "/boot/efi/gnu/store" and not "/mnt"/boot/efi/gnu/store"?

2) Symlink from ext4 "Guix" partition will not work on another vfat "EFI" partition.

Do you know how to fix this issue?

----

Petr

Hi Petr!

Yes. Like on other EFI systems, you have to mount /dev/mmdblk0p1 on /mnt/boot/efi.

There is the usual bootloader installation fallback, to use the bootloader-target argument for installation on /, if it is not existing below /mnt. And this is happening in your case.

I don’t understand why this common fallback got invented. I think it’s actually dangerous. It could destroy your booted system, if you simply forgot to mount the EFI system partition. I would prefer a clear error message.

But well, the code is following existing standards.

Because /mnt/boot/efi was not existing in your case and because of that fallback to ignore /mnt and use / instead.

That’s true. This symlink will not be created for your use case. The symlink will be created for booting over network, when the /mnt/boot/efi is an NFS share which allows symlinks. The use-case decision is based on symlink support at the bootloader-target.

Actually the installation on a microSD card is just a by-product of installation for netboot. :-)

Even on a normal x86_64 EFI system you could install the grub-efi-netboot-(removable-)bootloader instead of the grub-efi-(removable-)bootloader. The difference is, that all GRUB files will reside on the EFI system partition instead of the root partition. This could be helpful for encryption problems.

Bye

Stefan

Hi Stefan!

Thanks. I've mounted the boot partition to /mnt/boot instead of /mnt/boot/efi.

I tend to agree with you as the default behaviour can damage the host system without a warning which is dangerous.

So now I get some weird guix error during copying files:

sudo -E ./pre-inst-env guix system init --target=aarch64-linux-gnu gnu/system/examples/raspberry-pi-64.tmpl /mnt -v 3

gnu/system/examples/raspberry-pi-64.tmpl:32:24: warning: the 'target' field is deprecated, please use 'targets' instead

gnu/system/examples/raspberry-pi-64.tmpl:27:2: warning: List elements of the field 'swap-devices' should now use the <swap-space> record, as the old method is deprecated. See "(guix) operating-system Reference" for more details.

/gnu/store/hhb5l2f5287xmfzz4jgvi15kb9bcqi33-system

/gnu/store/fiq006ykhc0dkninzz5gxl2nh3vzc37p-grub.cfg

initializing operating system under '/mnt'...

copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message

copying to '/mnt'...

I've added the verbosity level 3 to print everything but I didn't get more info about what fails :-(

----

Petr

Hi Petr!

The function make-grub-efi-netboot-installer in gnu/bootloader/grub.scm first uses copy-recursively to copy the collection of bootloader files to /mnt/boot/efi and creates afterwards the symlinks to /gnu/store and /boot/grub/grub.cfg or – as in your case – creates a /mnt/boot/efi/efi/boot/grub.cfg to point GRUB to the root partition to access /boot/grub/grub.cfg and /gnu/store.

Yesterday your guix system init struggled to create these symlinks. That means it was already done with the copy-recursively call.

I’m pretty sure that this copy-recursively is using readdir internally. The functionallity afterwards is surely not.

Yesterday you also got the message ‘populating '/mnt'…’ before the symlink struggle. Therefore I assume that your current error has nothing to do with the bootloader installation.

Maybe there are leftovers from yesterday in /mnt, which prevent guix to copy files sucessfully onto /dev/mmcblk0p2?

Reformatting the ext4 filesystem might help.

Bye

Stefan

Hi Stefan,

the issue seems to be connected to my guix instance on the host. I got another weird messages and what finally help was to clean the profile cache in my home dir.

I then reformatted the SD card just to be sure.

# parted /dev/mmcblk0

GNU Parted 3.5

Using /dev/mmcblk0

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) p

Model: NORELSYS 1081CS0 (scsi)

Disk /dev/mmcblk0: 31.3GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 269MB 268MB primary fat32 lba

2 269MB 31.3GB 31.0GB primary ext4

And then I also copied the firmware files [1] neccessary to boot:

$ ls /mnt/boot/efi

bcm2708-rpi-b.dtb bcm2710-rpi-2-b.dtb bcm2711-rpi-4-b.dtb efi/ fixup_db.dat start4.elf

bcm2708-rpi-b-plus.dtb bcm2710-rpi-3-b.dtb bcm2711-rpi-cm4.dtb fixup4cd.dat fixup_x.dat start4x.elf

bcm2708-rpi-b-rev1.dtb bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-cm4s.dtb fixup4.dat LICENCE.broadcom start_cd.elf

bcm2708-rpi-cm.dtb bcm2710-rpi-cm3.dtb bootcode.bin fixup4db.dat manifest start_db.elf

bcm2708-rpi-zero.dtb bcm2710-rpi-zero-2.dtb bootloader.txt fixup4x.dat overlays/ start.elf

bcm2708-rpi-zero-w.dtb bcm2710-rpi-zero-2-w.dtb config.txt fixup_cd.dat start4cd.elf start_x.elf

bcm2709-rpi-2-b.dtb bcm2711-rpi-400.dtb dtb.txt fixup.dat start4db.elf u-boot.bin

The board powers up and I see the RGB screen when the raspberrypi boots. Then it switches to black screen and I don't see any output on the HDMI. Also there is no IP address assigned on the Ethernet even though the port itself is active.

I haven't run tcpdump or attached serial adapter yet so I don't know what's wrong and where the system hangs.

I'm testing this on Raspberry Pi 4.

[1] https://github.com/raspberrypi/firmware

----

Petr

Hi Petr!

Glad to hear you figured it out.

That should mean that the graphic-card is not set up properly.

But additionally U-Boot, GRUB or the kernel could be hanging. :-/

I prepared everything for a 3b monthes ago. Potentially this does not match the current firmware or kernel anymore or does not fit the 4.

Take a look at grub-efi-bootloader-chain-raspi-64 in gnu/packages/raspberry-pi.scm. Read the notes there.

Take a look at raspi-custom-txt and the others there as well. You probably have to use it to set some parameters.

I use these with an older kernel:

dtoverlay=disable-wifi

dtoverlay=vc4-fkms-v3d,cma-64

enable_uart=1

My best guess is a missing dtoverlay=vc4-fkms-v3d. I just noticed that there is meanwhile a vc4-fkms-v3d-pi4. Try that first. There are also flavours without the f(ake).

Attention with enable_uart, it is set in %raspi-u-boot-bootloader-txt to 1 already. There was once a U-Boot version working without enable_uart, but the recent one seems to require it again.

If this does not help, then maybe the kernel needs to be customized. I never heard of somone else running the linux-libre kernel on a Raspberry Pi. :-)

The kernel configuration in gnu/system/examples/raspberry-pi-64.tmpl has some comments regarding possible customizations.

Bye

Stefan

Hi Stefan!

Good news. I managed to run Guix libre kernel on the raspberry pi. Thanks for the help along the way!

pi@raspberrypi-guix ~$ uname -a

Linux raspberrypi-guix 5.18.16-gnu #1 SMP PREEMPT 1 aarch64 GNU/Linux

The issue was in the firmware, therefore I'll post the hashes of the files from the EFI partition:

pi@raspberrypi-guix ~$ sha256sum /boot/efi/*

010beacf073dbf7a4be24288a5c8b93001f0d852387dce50bf50de51a7412cd6 /boot/efi/bcm2711-rpi-400.dtb

489645357820f2e7e8f13841c901ba9571b779c07b3203f1627538d04ce45ad3 /boot/efi/bcm2711-rpi-4-b.dtb

c0f057eea9e357341265910000e56dab94b3200465b0556deb1eda3af117d3c9 /boot/efi/bcm2837-rpi-3-a-plus.dtb

df83b6dc6cda7e8eae62e8316b02a4c1659a6b0cf874c6caa075be9413a00b98 /boot/efi/bcm2837-rpi-3-b.dtb

c008e84ac57aa9c35aedabd1ed2cb4290088e33d85d1ef8ca56c5ef9b5f0d13c /boot/efi/bcm2837-rpi-3-b-plus.dtb

6a1cc758d38edcf9f9213a8fcbc75d4bf06fbd86806b4430c15742b6ab427de9 /boot/efi/bcm2837-rpi-cm3-io3.dtb

69309823da13dc96b89e3d82b44f820e4f84efa79d207adad2c8784559794f03 /boot/efi/bootcode.bin

1ac38b353f924c56c5d5a587971f3f81d09c433787b99f889368fd342c4336da /boot/efi/bootloader.txt

df0ac4af19615f13ff7ffa395ae553c70813ef9d2a82fab0e1175adf80ed1294 /boot/efi/cmdline.txt

9d4975d57f5eb54b08a430cb3d677e5dbf23ed48c73fe33a4e3efdfc35f8d41e /boot/efi/config.txt

bcc22553ef64d361270103e84c80ab5362bdb2ffba3c9eea13ee3de60f6cbaff /boot/efi/dtb.txt

22db24c621c326d907c7b8c5975b1730e6ce78dea680bec3958d907093031638 /boot/efi/fixup4cd.dat

7d28775bff4781bda065f37fbb64c88ed1b56d1f4af79d85f792032f55bb6de7 /boot/efi/fixup4.dat

b0d299dd46ddecd2c4eeeca61f42d114a0c464dcd6165861a662d118daa3afc0 /boot/efi/fixup4db.dat

495076ed0488703ba59bd0d43bc577ad1695470379263854197a752cd1989330 /boot/efi/fixup4x.dat

22db24c621c326d907c7b8c5975b1730e6ce78dea680bec3958d907093031638 /boot/efi/fixup_cd.dat

8e90c8a379f3f99ee59370c50e48853db82669dbd6515d4ce08a24307d3dc4c5 /boot/efi/fixup.dat

4f5d2433956f64cec640ae91dc47bdea3aa2c6c7cc579faafb779826bd7e554c /boot/efi/fixup_db.dat

82bbf5a3f86f73a41e9f8975deb75e50ab4d7581500a43ec7f0fcc42214948dd /boot/efi/fixup_x.dat

9756eca19be1a443fc6a6cd5f8ffb0759d8b5d68f24248829d39abdc59388490 /boot/efi/manifest

9e1474d3b3078bb80e87f65a5122fd4a8a828b563de5652b37d8b40019b3a51a /boot/efi/start4cd.elf

2dfb27b876ec00e54857e199e939def019b148010f03ce1947e4b48fa226e4f7 /boot/efi/start4db.elf

a607afd09523830bd524eafa2eb3f530d70cef643eb8eca14a80dcbd6830ec8f /boot/efi/start4.elf

7ffa3ce1f93f61737fee68f61747b876fd1b15203553ebc096d2b64d79fb7da2 /boot/efi/start4x.elf

b21aeceec40aff935f70dfe3adc4d96963e61d4696f909ad910f299da978d8bb /boot/efi/start_cd.elf

378e84616f28e63cb33c794e3430b7deeca5bb84067f79e71408f6aab587e0e7 /boot/efi/start_db.elf

e4a374d78f31d333b20ab128a614d3549f9dfe4103781c0938104fc0dd45d3fc /boot/efi/start.elf

dbdeb7c679566419035e70db8aff90954ca6ba45a579e990886ddc0b964b2621 /boot/efi/start_x.elf

f9c7d5534c787479601f1e70b4b108cd765445aecbc154296d0d35f423045ca4 /boot/efi/sysconf.txt

d47f45c6221ccaaf1ca0e66d01b90fca350a0b06b4c7a44a81b6f68a99f36607 /boot/efi/u-boot.bin

I'll test it also on RPi3 and I'll change the storage media to SSD on my RPi4 to provide more space and faster reliable storage.

- I just have question regarding the example if it wouldn't be better to prepare the whole image - partition the SD card and just copy it to the actual media?

- Should there be some manual how to prepare the firmware files or format the SD card in case we prepare just the root filesystem and bootloader?

IMHO having ISO image for Raspberry Pi 3,4 (aarch64) would be great as it would allow them to run Guix easily without need to build it on some other aarch64 machine or resort to crosscompile. What do you think?

Also there's small patch to fix deprecated calls in os-defintion files.

----

Petr

Hi Petr!

Woot! Great!

Good to know!

In the meantime I got everything compiled and installed for my Raspberry Pi 3b as well. But there is some issue with the U-Boot. If I replace U-Boot with an older version, it boots and the system is running fine. However, during boot the Linux-Libre-Gnus and early kernel messages are not visible, but after boot all seems to be fine.

Maybe the troubles stem from the firmware, as in your case – I use a different one –, or maybe the U-Boot only works on a Pi 4.

I’m using the Linux-Libre kernel with the %bcmrpi3-defconfig from the Raspberry Pi Linux sources (removing a long list of unsupported configurations)

stefan@guix ~$ uname -a

Linux guix 5.18.12-bcmrpi3-v8 #1 SMP PREEMPT 1 aarch64 GNU/Linux

Yes, certainly. As you may know I started with Guix on void with an NFS root file-system and patched Guix to get to this point, still on NFS. So I have no experience yet to build an image.

From what I saw in the code, I guess that more work needs to be done to generate an image. My personal focus is to first get the patches merged.

I think the comments in e.g. raspberry-pi-64.tmpl could be improved. A hint to the non-free firmware is certainly problematic. Not sure, if we should or even can mention the Raspberry Pi in the manual.

Yes, I totally agree. I also think that it could help to spread Guix. It would be great to see something like e.g. Pi-hole in the future to be based on Guix System.

But first things first, the merge is still pending.

Thanks, much appreciated!

Bye

Stefan

Hi Stefan!

I got it working also there. I do have RPi2 but I doubt it will run there as it's just not that powerful.

Yes, the focus should be on mainlining these changes first.

I know there is some open source bootloader which is already packaged in Guix `raspi-arm64-chainloader`. Maybe this would be the way in the future :-)

Good luck

----

Petr

Hi Petr!

Great!

Which Pi is it exactly? Did you use the same build as for your Pi 4? And the same firmware? Did you see the Linux-Libre gnus and early kernel messages after GRUB?

I never tried it. It may be possible.

Bye

Stefan

Hi Petr!

The firmware I’m using is the same, but all dtb files differ.

Did you use the same set of dtb files on our Pi 3? Especially I have a /boot/efi/bcm2710-rpi-3-b.dtb – which is loaded at boot due to the upstream_kernel=0 setting in dtb.txt –, which you seem to be missing.

I guess that your Pi 3 will not load any dtb file.

My current but not working U-Boot has a different hash.

Bye

Stefan

Hi Stefan!

I'll check and post the config here but I don't have Raspberry Pi currently with me.

----

Petr

-------- Original Message --------

On Sep 2, 2022, 1:55 AM, Stefan wrote:

Hi Petr!

Thanks, for the offer, but it isn’t necessary any more, I found the reason.

Actually I’m net-booting my Raspberry Pi 3b over network. But due to a known bug in the ROM code, I still have a microSD card inserted with only the bootcode.bin file.

If I boot the Pi with that card inserted, then GRUB has a problem:

error: variable `root' isn't set.

Entering rescue mode...

grub rescue>

If I remove the microSD card, then GRUB has no problem with its root variable, and Guix System is started.

Interestingly this does not happen, if I use the older U-Boot version 2020.10.

The current U-Boot version 2022.04 prints an error message – with and without the mircoSD card inserted:

libfdt fdt_check_header(): FDT_ERR_BADMAGIC

But I’m not sure, if this error message is related.

Bye

Stefan

Hi!

I did a rebase onto commit 2e8b4f9bfa00489fd3acff305837a79af236e183.

Vagrant, there was a comment left about removing "CONFIG_BOOTDELAY=1" for the u-boot, this is now done. I think all review comments have been applied.

There is a new u-boot-rockpro64-rk3399 which I adapted as well to use the #:configs keyword argument.

The function modify-defconfig in guix/build/kconfig.scm no longer interprets "CONFIG_XY=" like "# CONFIG_XY is not set".

Bye

Stefan

Hi,

Vagrant, Danny: could you take a look at these patches? They seem to

have fallen through the cracks.

TIA. :-)

Ludo’.

Stefan <stefan-guix@vodafonemail.de> skribis:

On 2022-09-22, Stefan wrote:

Thanks! It definitely looks like great progress.

Great!

I like how that works.

Nervous about how that actually works, but hopefully it plays out correctly.

This whole patch series is large and overwhelming and at least a bit

beyond my abilities to wrap my head around (which has certainly caused

me to wait a bit to review)... so I cannot possibly comment on weather

the series as a whole is "good", through no fault of the patch

author(s)! I will try and comment where I can, but really need help to

review it in any meaningful way.

Also from what I recall on earlier iterations of this patch series,

different reviewers seemed to have differing style recommendations

around weather to split patches into smaller commits or merge patches

into combined commits, which can surely be frustrating. I don't *want*

to be frustrating, but I lean towards splitting patches into as small a

commit as possible to wrap my head around the distinct ideas.

I also like to refactor out anything that can be applied directly to

master as soon as possible (e.g. the description-appending patches look

promising for that) with the hope to get the remaining patch series

smaller and smaller with each iteration. Some people may want to do an

all-or-nothing merge. I don't know what's "right" for the guix

community...

With all that out of the way... here goes my attempt to review!

Overall, this looks good, to me, though have one question...

...

Why is native-inputs removed from the 'install phase? Is it no longer

needed? Was it not actually needed before? I see no mention of this

change in the comment.

There is too much going on here for me to follow, but it is perhaps just

doing a lot of big changes... help? :)

I like how this simplifies the various u-boot-* package definitions!

This seems good to me.

It would be nice to first switch the existing u-boot-* packages to use

the new append-description feature one commit (I think this could even

be applied directly to master?), and then add the new functionality

(e.g. make-u-boot-bin-package, *u-boot-rpi-*, etc.) in another commit or

a couple commits. At least, that would make it a little easier for me to

read.

Looks ok to me, though to say I fully understand it would be a stretch. :)

Seems good. I think I even understand this one!

Seems good.

I'd split this into two commits, one adding

grub-efi-bootloader-chain-raspi-64, and one adding examples using it,

but that is really a judgement call.

live well,

vagrant

Hi Vagrant!

This is described in the doc-string of config-string->pair in the module (guix build kconfig), which contains a regular expression for the parsing.

Basically any “# CONFIG_X is not set” or “CONFIG_X” is treated as unset and produces a ("CONFIG_X" . #f). The latter is just for convenience, as the first one is hard to remember and easy to get wrong. Any “CONFIG=…” is treated as set and produces a ("CONFIG_X" . "…").

Anything else except comments with “#…” or empty lines will throw an error.

In a previous patch “CONFIG_X=“ was also treated as unset, which was confusing, as this is actually a valid makefile assignment.

The function pair->config-string produces a “# CONFIG_X is not set” for any #f value, or a proper assignment otherwise.

I’ll try to help.

The single patch files can be applied separately, they don’t break anything. Some reordering is also possible. In particular, 02-gnu-bootloader-rework-chaining.patch (the monster) can be applied later but before 09-gnu-raspberry-pi-add-a.patch.

Great! :-)

Exactly, it was even not needed before, an obsolete argument, which I removed. I figured this out by chance when selecting the needed arguments for the 'set-environment phase.

As noted, this patch can be delayed before 09-gnu-raspberry-pi-add-a.patch is to be applied.

Before this patch, the bootloader-installer of efi-bootloader-chain called grub-mknetdir (actually the installer of grub-efi-netboot-bootloader) and copied the content of a special collection folder of the bootloader-profile. That collection folder was very special and did not fit well to the bootloader-profile idea. Well, actually the grub-efi package with all its tools being part of the profile was the problem, making the collection folder necessary.

With this patch the packages of grub-efi-netboot-bootloader and grub-efi-netboot-removable-bootloader are already pre-installed – grub-mknetdir is already called during package creation. Their installer just copies the whole package/profile into the target directory. The efi-bootloader-chain only creates a profile with the bootloader (e.g. grub-efi-netboot-bootloader) and additional packages or files. The collection folder is not needed any more. Most complexity got moved from the bootloader installation time to the package build time.

Other patches generate more “pre-installed“ files like u-boot.bin, config.txt, device-tree files, etc., which now all fit much bettor to the bootloader-profile idea, to just be copied to a target directory.

This patch is also inspired by older comments. Maybe take a look at the comments below https://issues.guix.gnu.org/issue/41066#25 and especially at https://issues.guix.gnu.org/issue/41066#28-lineno18

I don’t think splitting this into smaller parts is possible without a breakage.

Great! :-)

Great! :-)

Splitting is possible.

The idea here is very similar to the use for u-boot: Take some Linux, pretend some defconfig being used, do simple modifications to it, and verify the result.

The defconfig can be provided via #:defconfig (any file-like-object or a file-name) or will otherwise be generated with “make savedefconfig”.

The function (make-defconfig) is a helper to use a defconfig file from some url.

The function system->linux-srcarch is needed to locate existing defconfig files in the Linux sources like arch/arm/configs/bcm2835_defconfig, so that you can just pass the filename “bcm2835_defconfig” to #:defconfig. This enables the use of defconfig files existing in the Linux sources. As Kbuild expects defconfig files at a certain location, this function is also needed to copy an own defconfig file there.

There was once a blog post about a custom Linux kernel stating “Suggestions and contributions toward working toward a satisfactory custom initrd and kernel are welcome!”, see https://guix.gnu.org/de/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/. This is my take including a verification for the kernel. :-)

Great! :-)

Great! :-)

True. Combining the example with the new function was my choice. If you don't mind, I'd keep it this way.

Thanks a lot for the review, Vagrant!

How to proceed from here?

I'd suggest to postpone 02-gnu-bootloader-rework-chaining.patch and 09-gnu-raspberry-pi-add-a.patch, until all others got merged.

To me it seems possible to commit these patches as they are in this order:

01-gnu-linux-fix-extra-version.patch

03-build-kconfig-add-new-module.patch

05-gnu-linux-new-function-to.patch

06-gnu-raspberry-pi-add-defconfig.patch

07-gnu-raspberry-pi-add-helpers.patch

08-gnu-raspberry-pi-new-function.patch

Then I could send a reduced patch-series with:

splitted 04-gnu-bootloader-add-u-boot.patch

02-gnu-bootloader-rework-chaining.patch

09-gnu-raspberry-pi-add-a.patch

What do you think?

Bye

Stefan

Hi Stefan,

I've recently encoutered an issue on Raspberry Pi 4 when attaching USB Hard drive.

I formatted it with fat32 and ext4. Ran `guix system init config.scm /init`.

I selected `(initrd-modules (list "xhci_pci" "pcie_brcmstb"))` in the config and rebooted.

Unfortunately I get error about missing file:

```

error: file /gnu/store/xxx-raw-initrd/initrd.cpio.gz not found

Press any key to continue ...

```

After that I get kernel panic.

Shoudn't the initrd be placed in the EFI partition? That way you get the modules in order to mount the rootfs.

Should I copy it and modify the Grub entry?

The goal here is to run completly from USB then there won't be any need for SD card.

----

Petr

Hi Petr!

No. As on a PC, the /boot/grub/grub.cfg lists the location of the initrd in the store, as it does for the kernel as well. Grub is able to read from most file-systems and load the initrd.

No.

Is this error from GRUB? Is that file actually existing?

Was there maybe some error message about missing kernel-modules?

Was the GRUB screen as usual with a background graphic? Because that is loaded from the store as well.

If not, then GRUB is not able to access the store. Check the content of /boot/efi/efi/boot/grub.cfg. It contains two lines: one to search for the right file-system containing the /boot/grub/grub.cfg, and another to load it.

The search line is usually referring to an fs-uuid determined during the bootloader installation with the help of the grub-probe command. However, there is the risk grub-probe does not find an fs-uuid. In that case as a fallback the search command will look for a /boot/grub/grub.cfg on any readable file-system. Maybe it found one on a wrong file-system?

From what you wrote, U-Boot is able to boot from USB and load GRUB. I’m just not absolutely sure, if GRUB is able to boot from USB on the RPi 4, but I would think so.

Bye

Stefan

Hi Petr!

It must be that your initrd is missing in the store.

The /boot/grub/grub.cfg is the only file referring to the initrd and GRUB is the only program reading it. So an error message referring to the initrd must be from GRUB and then GRUB was able to access your root-file-system, which should contain /boot and /gnu/store.

Bye

Stefan

?Hi Petr!

It must be that your initrd is missing in the store.

The /boot/grub/grub.cfg is the only file referring to the initrd and GRUB is the only program reading it. So an error message referring to the initrd must be from GRUB and then GRUB was able to access your root-file-system, which should contain /boot and /gnu/store.

Bye

Stefan

Hi Stefan!

Some comments/question for this proposed change.

Stefan <stefan-guix@vodafonemail.de> writes:

[...]

This first commit LGTM. I'll push it shortly.

[...]

That's *a lot* of text :-). For the future, some of the things there are

improvements rather than necessary changes it seems, so could have been

split into something different, smaller & easier to review. I've

standardized to use the imperative tense in the change log message (Added

-> Add for example).

[...]

In GRUB-EFI-CONFIGURATION-FILE above, why do we hard-code grub-efi

instead of retrieving it from config the same as for

GRUB-CONFIGURATION-FILE? It seems that'd be preferable, as otherwise

someone cannot override GRUB-EFI with their own variant, no?

I've unified the above docstring as one; otherwise it was mangled with

Scheme and it wouldn't have appeared as a whole in the online

documentation system of Guile.

I've improved the writing a bit (I think!), use gexps in some places,

and other smallish changes that amount to:

Hi again,

Stefan <stefan-guix@vodafonemail.de> writes:

[...]

Another question regarding that same piece of code: why isn't

grub-efi-configuration-file used in the definition of the

grub-efi-bootloader definition? It's still using

grub-configuration-file.

--

Thanks,

Maxim

Hi,

Stefan <stefan-guix@vodafonemail.de> writes:

[...]

[...]

^

What is this filter used for here? EDIT: saw later, it's used to filter

out comments.

[...]

So, it finds mismatched configurations that exist in both CONFIG and

DEFCONFIG, but it doesn't error when there are configs that exist in

DEFCONFIG but missing from CONFIG, right? Should it?

I've made the following mostly cosmetic changes:

And streamlined the commit messages as:

Explanations don't go in the GNU ChangeLog, they go ideally in comments

in the code or *before* the GNU ChangeLog, if some rationale helps

understanding the change, so you can keep things dry there.

I'll push this change shortly.

--

Thanks,

Maxim

Hi,

I've renamed it to customize-linux, and streamlined the commit message

like so:

Otherwise, I've made the following changes (exporting procedures

explicitly from the modules):

I'll push it shortly.

--

Thanks,

Maxim

Hi,

Stefan <stefan-guix@vodafonemail.de> writes:

Neat!

I've registered the new files in Makefile.am (and adjusted the commit

message), fixed their indentation and pushed!

This whole series is now in Guix. I'll try to test it with actual

devices in the coming days and see if anything needs adjusting.

Thanks to you and to everyone else who contributed to the review.

Maxim

On 2022-12-01, Maxim Cournoyer wrote:

This does cause a test suite failure with tests/guix-system.sh:

+ guix system -n disk-image gnu/system/examples/raspberry-pi-64-nfs-root.tmpl

accepted connection from pid 31196, user vagrant

guix system: warning: 'disk-image' is deprecated: use 'image' instead

guix system: error: canonicalize-path: No such file or directory: "/home/vagrant/.ssh/id_ecdsa.pub"

+ rm -f t-guix-system-30549 t-guix-system-error-30549 /tmp/t-guix-system-30549/config.scm /tmp/t-guix-system-30549/my-torrc

+ rmdir /tmp/t-guix-system-30549

FAIL tests/guix-system.sh (exit status: 1)

gnu/system/examples/raspberry-pi-64-nfs-root.tmpl

(define %my-public-key

(local-file (string-append (getenv "HOME") "/.ssh/id_ecdsa.pub")))

Seems like using local-file for should be removed or at least commented

out in the example. Or include the full text of an example key in the

.tmpl file instead of using local-file...

live well,

vagrant

Hello,

Vagrant Cascadian <vagrant@debian.org> writes:

Thanks for the heads-up! I've removed key usage from the templates in

08dc9f2ca2e96476aa51c906c8ba01ca5d033568. I also had to mark the

templates to be built for aarch64-linux in

93309efdce72ac5028944d5c1f7b081a7f62b84a.

--

Thanks,

Maxim