Report forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 09 May 2021 15:33:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan <stefan-guix@vodafonemail.de>:
New bug report received and forwarded. Copy sent to guix-patches@gnu.org.
(Sun, 09 May 2021 15:33:02 GMT) (full text, mbox, link).
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)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 84ea849108..51e692a8c3 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -749,9 +749,9 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(define* (make-linux-libre version hash-string supported-systems
#:key
+ (extra-version #f)
;; A function that takes an arch and a variant.
;; See kernel-config for an example.
- (extra-version #f)
(configuration-file #f)
(defconfig "defconfig")
(extra-options %default-extra-linux-options)
@@ -770,9 +770,9 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(define* (make-linux-libre* version source supported-systems
#:key
+ (extra-version #f)
;; A function that takes an arch and a variant.
;; See kernel-config for an example.
- (extra-version #f)
(configuration-file #f)
(defconfig "defconfig")
(extra-options %default-extra-linux-options))
@@ -838,7 +838,8 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(format #t "`CROSS_COMPILE' set to `~a'~%"
(getenv "CROSS_COMPILE"))))
- (setenv "EXTRA_VERSION" ,extra-version)
+ (setenv "EXTRAVERSION" ,(and extra-version
+ (string-append "-" extra-version)))
(let ((build (assoc-ref %standard-phases 'build))
(config (assoc-ref (or native-inputs inputs) "kconfig")))
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.
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sat, 19 Jun 2021 21:10:30 +0200
Hi Danny!
> Since bug 43534 is closed, does that mean I can drop patch 01-gnu-qemu-disable-tests-on.patch ?
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sat, 19 Jun 2021 19:19:02 GMT) (full text, mbox, link).
Cc: Mark H Weaver <mhw@netris.org>, Leo Famulari <leo@famulari.name>,
48314@debbugs.gnu.org
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sat, 19 Jun 2021 22:21:48 +0200
Hi!
> @Stefan: On the other hand, I'm not sure of the general utility of make-defconfig.
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).
> Sounds like a too weird special case to have general utility.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Wed, 28 Jul 2021 18:59:02 GMT) (full text, mbox, link).
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
Added tag(s) patch.
Request was from Stefan <stefan-guix@vodafonemail.de>
to control@debbugs.gnu.org.
(Sat, 13 Nov 2021 13:58:02 GMT) (full text, mbox, link).
Added indication that bug 48314 blocks
Request was from Stefan <stefan-guix@vodafonemail.de>
to control@debbugs.gnu.org.
(Sat, 13 Nov 2021 13:58:02 GMT) (full text, mbox, link).
Changed bug title to '[PATCH] Install guix system on Raspberry Pi' from 'Patches to install guix system on Raspberry Pi'
Request was from Stefan <stefan-guix@vodafonemail.de>
to control@debbugs.gnu.org.
(Sat, 13 Nov 2021 13:58:02 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sat, 13 Nov 2021 18:07:01 GMT) (full text, mbox, link).
On 2021-10-31, Stefan wrote:
> I did a rebase of the patch series to avoid bit-rotting. One patch got obsolete meanwhile.
>
> This series applies on GIT commit 1a80b8909a521b91d30649a011b0257d0fadc18c.
And still applies on master as of
193d7b5b450d2004c26720e488a9cce930542e9e :)
Subject: [PATCH 3/8] * gnu/packages/bootloader.scm (make-u-boot-package): Add
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:
...
Subject: [PATCH 3/8] * gnu/packages/bootloader.scm (make-u-boot-package): Add
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:
> Subject: [PATCH 3/8] * gnu/packages/bootloader.scm (make-u-boot-package): Add
> 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.
...
> +(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 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)
Patch that builds, but haven't tested on an actual board (do have rpi2
and rpi3b+ could test sometime):
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 706ddf0207..f5a3fd51e0 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -994,6 +994,18 @@ (define-public u-boot-pinebook-pro-rk3399
`(("firmware" ,arm-trusted-firmware-rk3399)
,@(package-native-inputs base))))))
+(define-public u-boot-rpi-2
+ (make-u-boot-package "rpi_2" "arm-linux-gnueabihf"))
+
+(define-public u-boot-rpi-3-32b
+ (make-u-boot-package "rpi_3_32b" "arm-linux-gnueabihf"))
+
+(define-public u-boot-rpi-4-32b
+ (make-u-boot-package "rpi_4_32b" "arm-linux-gnueabihf"))
+
+(define-public u-boot-rpi-arm64
+ (make-u-boot-package "rpi_arm64" "aarch64-linux-gnu"))
+
(define-public vboot-utils
(package
(name "vboot-utils")
Which leads me to wonder, why have the name and description argument at
all, when you could just inherit and set the name, like done with the
boneblack?
(define-public u-boot-am335x-boneblack
(let ((base (make-u-boot-package "am335x_evm" "arm-linux-gnueabihf")))
(package
(inherit base)
(name "u-boot-am335x-boneblack")
(description "U-Boot is a bootloader used mostly for ARM
boards. It also initializes the boards (RAM etc).
...
And of course, thanks for working on this! :)
live well,
vagrant
On 2021-10-31, Stefan wrote:
> +(define-public %u-boot-rpi-efi-configs
> + '("CONFIG_OF_EMBED="
> + "CONFIG_OF_BOARD=y"
> + "CONFIG_BOOTDELAY=0"))
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
phodina via Guix-patches via schreef op do 14-04-2022 om 07:38 [+0000]:
> + `(modify-phases ,phases
> + (replace 'configure
To get rid of the #< error, replace this by
#~(modify-phases #$phases [...])
(and replace the , by #$ etc).
Greetings,
Maxime.
>
> > + `(modify-phases ,phases
> > + (replace 'configure
>
>
> 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
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
Cc: Stefan <stefan-guix@vodafonemail.de>,
"48314@debbugs.gnu.org" <48314@debbugs.gnu.org>
Subject: [PATCH v5] Install guix system on Raspberry Pi
Date: Thu, 14 Apr 2022 13:03:10 +0000
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 14 Apr 2022 13:58:02 GMT) (full text, mbox, link).
phodina schreef op do 14-04-2022 om 13:03 [+0000]:
> ~$ 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 ./
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).
> As you can see the execute bit is missing. Therefore running
The user has the read-write-execute bits, the group and other don't.
> chmod +x /home/pi/
>
> fixed the problem. But I'm unsure why the home dir was created
> without the those flags.
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]:
> 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 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]:
> 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.
This one should now be fixed by
1f82602153 gnu: guile-fibers@1.1: Support cross-compilation.
Greetings,
Maxime.
>
> > 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.
>
>
> 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.
diff --git a/gnu/packages/ntp.scm b/gnu/packages/ntp.scm
index 7a3c033b2e..cb90432730 100644
--- a/gnu/packages/ntp.scm
+++ b/gnu/packages/ntp.scm
@@ -153,7 +153,8 @@ (define-public ntp
`(("libcap" ,libcap))
'())))
(arguments
- `(#:phases
+ `(#:configure-flags (list "--with-yielding-select=yes")
+ #:phases
(modify-phases %standard-phases
(add-after 'unpack 'disable-network-test
(lambda _
----
Petr
On 2022-04-14, phodina@protonmail.com wrote:
> (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.
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.
> +(define-public %u-boot-rpi-efi-configs
> + '("CONFIG_OF_EMBED="
> + "CONFIG_OF_BOARD=y"
> + "CONFIG_BOOTDELAY=0"))
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.
> +(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))
Please keep package names consistent with defconfig
name. (e.g. u-boot-rpi-arm64). It's confusing enough without extra newly
invented names! :)
> +(define-public u-boot-rpi-3-efi
> + (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))
Ditto, or drop this variant; same for the 32-bit rpi-4 variants.
> Subject: [PATCH v3 2/8] build: kconfig: Add new module to modify a defconfig
> file.
...
> (define-public u-boot-pinebook
> - (let ((base (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu")))
> - (package
> - (inherit base)
> - (arguments
> - (substitute-keyword-arguments (package-arguments base)
> - ((#:phases phases)
> - `(modify-phases ,phases
> - (add-after 'unpack 'patch-pinebook-config
> - ;; Fix regression with LCD video output introduced in 2020.01
> - ;; https://patchwork.ozlabs.org/patch/1225130/
> - (lambda _
> - (substitute* "configs/pinebook_defconfig"
> - (("CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y") "CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y\nCONFIG_VIDEO_BPP32=y"))
> - #t)))))))))
> + (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu"
> + ;; Fix regression with LCD video output introduced in 2020.01
> + ;; https://patchwork.ozlabs.org/patch/1225130/
> + #:configs '("CONFIG_VIDEO_BPP32=y")))
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.
> (define-public u-boot-novena
> - (let ((base (make-u-boot-package "novena" "arm-linux-gnueabihf")))
> + (let ((base (make-u-boot-package "novena" "arm-linux-gnueabihf"
> + ;; Patch configuration to disable loading u-boot.img from FAT
> + ;; partition, allowing it to be installed at a device offset.
> + #:configs '("CONFIG_SPL_FS_FAT="))))
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:
> - (substitute* "configs/novena_defconfig"
> - (("CONFIG_SPL_FS_FAT=y") "# CONFIG_SPL_FS_FAT is not set"))
> - #t)))))))))
... was used previously.
> Subject: [PATCH v3 5/8] gnu: raspberry-pi: Add defconfig objects to build
> customized Linux kernels.
>
> gnu/packages/raspberry-pi.scm (make-raspi-defconig): New function to make
> downloaded defconfig objects from the Linux repository of the Raspberry Pi
> Foundation.
> (%bcm2709-defconfig, %bcm2710-defconfig, %bcm2711-defconfig,
> %bcm2835-defconfig, %bcmrpi-defconfig, %bcm2711-defconfig-64,
> %bcmrpi3-defconfig): New variables containing defconfig objects to build
> Linux kernels customized for Raspberry Pi single board computers.
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]:
> Yes,
>
> guile-fibers are now fixed, but the cross compile build fails now on
> shepherd-0.9 due to guile-fibers not being available.
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.
Cc: Stefan <stefan-guix@vodafonemail.de>,
Vagrant Cascadian <vagrant@debian.org>,
"dannym@scratchpost.org" <dannym@scratchpost.org>,
Maxime Devos <maximedevos@telenet.be>,
"48314@debbugs.gnu.org" <48314@debbugs.gnu.org>
Subject: Re: [bug#48314] [PATCH v3] Install guix system on Raspberry Pi
Date: Fri, 15 Apr 2022 19:17:23 +0200
Hi,
phodina <phodina@protonmail.com> skribis:
> 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’.
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sat, 16 Apr 2022 08:55:02 GMT) (full text, mbox, link).
> > 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
Cc: Stefan <stefan-guix@vodafonemail.de>,
Vagrant Cascadian <vagrant@debian.org>,
"dannym@scratchpost.org" <dannym@scratchpost.org>,
Maxime Devos <maximedevos@telenet.be>,
"48314@debbugs.gnu.org" <48314@debbugs.gnu.org>
Subject: Re: [bug#48314] [PATCH v3] Install guix system on Raspberry Pi
Date: Mon, 18 Apr 2022 23:00:50 +0200
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’.
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 21 Apr 2022 10:53:02 GMT) (full text, mbox, link).
Cc: Stefan <stefan-guix@vodafonemail.de>,
Vagrant Cascadian <vagrant@debian.org>,
"dannym@scratchpost.org" <dannym@scratchpost.org>,
Maxime Devos <maximedevos@telenet.be>,
"48314@debbugs.gnu.org" <48314@debbugs.gnu.org>
Subject: Re: [bug#48314] [PATCH v3] Install guix system on Raspberry Pi
Date: Thu, 21 Apr 2022 10:52:26 +0000
> 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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 21 Apr 2022 19:33:02 GMT) (full text, mbox, link).
Subject: Re: [bug#48314] [PATCH v3] Install guix system on Raspberry Pi
Date: Thu, 21 Apr 2022 21:32:34 +0200
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 28 Apr 2022 02:58:02 GMT) (full text, mbox, link).
On 2022-04-14, Vagrant Cascadian wrote:
> On 2022-04-14, phodina@protonmail.com wrote:
> (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.
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
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Thu, 28 Apr 2022 08:05:25 +0200
Hi Vagrant!
> Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and
> 2021.04 rpi-arm64 fails to boot on rpi3b+ ...
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?
> 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)
Please wait a bit longer, I addressed all your comments to U-Boot already.
Bye
Stefan
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 28 Apr 2022 15:27:01 GMT) (full text, mbox, link).
On 2022-04-28, Stefan wrote:
>> Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and
>> 2021.04 rpi-arm64 fails to boot on rpi3b+ ...
>
> 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.
Look forward to seeing an updated patch series!
> My guess is, that the kernel has problems booting. Did GRUB show up?
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 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)
>
> Please wait a bit longer, I addressed all your comments to U-Boot already.
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
Cc: Stefan <stefan-guix@vodafonemail.de>,
Danny Milosavljevic <dannym@scratchpost.org>, 48314@debbugs.gnu.org
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sun, 17 Jul 2022 18:47:47 +0200
Hi Vagrant!
> 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.
Uups. I will remove them.
> In other words, keep names consistent with the upstream defconfig they are based on.
OK
> I presume you didn't add the aarch64 rpi_3 and rpi_4 variants because they are supported by rpi_arm64?
Yes.
> 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…
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. :-)
> Which leads me to wonder, why have the name and description argument at all, when you could just inherit and set the name, like done with the boneblack?
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 17 Jul 2022 16:49:02 GMT) (full text, mbox, link).
Cc: Danny Milosavljevic <dannym@scratchpost.org>, 48314@debbugs.gnu.org
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sun, 17 Jul 2022 18:47:52 +0200
Hi Vagrant!
> u-boot-file appears to be hard-coded; there may be other boards which use a different u-boot artifact.
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.
> 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?
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.
> I wondered "why does it have to be cross-compiled" but then realized that came from the existing make-u-boot-package function.
Yes, that’s right, it is a copy from the other function. It will be gone with the re-work.
> I've mostly been building u-boot natively these days. :)
Me too, exclusively. :-)
Bye
Stefan
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 17 Jul 2022 16:49:02 GMT) (full text, mbox, link).
Cc: Danny Milosavljevic <dannym@scratchpost.org>, 48314@debbugs.gnu.org
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sun, 17 Jul 2022 18:47:58 +0200
Hi Vagrant!
>> +(define-public %u-boot-rpi-efi-configs
>> + '("CONFIG_OF_EMBED="
>> + "CONFIG_OF_BOARD=y"
>> + "CONFIG_BOOTDELAY=0"))
>
> 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.
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>
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 17 Jul 2022 16:49:03 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Sun, 17 Jul 2022 18:48:05 +0200
Hi!
Sorry for tho long period of silence.
> do you need help with the patches?
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.
> Also should we provide some patches to the upstream kernel in Guix? [1]
>
> [1] https://github.com/lategoodbye/rpi-zero/issues/43
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 17 Jul 2022 17:22:01 GMT) (full text, mbox, link).
On 2022-07-17, Stefan wrote:
>>> +(define-public %u-boot-rpi-efi-configs
>>> + '("CONFIG_OF_EMBED="
>>> + "CONFIG_OF_BOARD=y"
>>> + "CONFIG_BOOTDELAY=0"))
>>
>> 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.
>
> 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.
...
> 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.
So if it does not find that one file, what do you do?
> Also other distributions like openSUSE use U-Boot as EFI firmware, so
> I think the basic EFI functionality is tested quite well.
Sure, it has improved greatly.
> My preference is to not bother pure users with a delayed boot
> time. However, I changed it to CONFIG_BOOTDELAY=1.
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
Cc: Danny Milosavljevic <dannym@scratchpost.org>, 48314@debbugs.gnu.org
Subject: Re: [bug#48314] Patches to install guix system on Raspberry Pi
Date: Sun, 17 Jul 2022 20:04:19 +0200
Hi Vagrant!
> So if it does not find that one file, what do you do?
Valid point. Actually I would have copied back a working U-Boot version from the NFS server side. ;-)
> it is my understanding that Guix prefers to go with upstream defaults
Would you mind removing that line if committing?
Bye
Stefan
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Mon, 18 Jul 2022 10:40:02 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Mon, 18 Jul 2022 19:23:42 +0000
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Tue, 19 Jul 2022 06:56:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Tue, 19 Jul 2022 08:55:08 +0200
Hi Petr!
> Do you know how to fix this issue?
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.
> 1) Why does it point to "/boot/efi/gnu/store" and not "/mnt"/boot/efi/gnu/store"?
Because /mnt/boot/efi was not existing in your case and because of that fallback to ignore /mnt and use / instead.
> 2) Symlink from ext4 "Guix" partition will not work on another vfat "EFI" partition.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Tue, 19 Jul 2022 07:36:02 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Tue, 19 Jul 2022 07:35:18 +0000
Hi Stefan!
>
> > Do you know how to fix this issue?
>
>
> 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.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Wed, 20 Jul 2022 06:15:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Wed, 20 Jul 2022 08:13:46 +0200
Hi Petr!
> So now I get some weird guix error during copying files:
> initializing operating system under '/mnt'...
> copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message
> copying to '/mnt'...
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Wed, 20 Jul 2022 07:17:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Wed, 20 Jul 2022 07:16:34 +0000
Hi Stefan,
> > So now I get some weird guix error during copying files:
>
> > initializing operating system under '/mnt'...
> > copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message
> > copying to '/mnt'...
>
>
> 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.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Wed, 20 Jul 2022 19:43:02 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Wed, 20 Jul 2022 21:42:10 +0200
Hi Petr!
> the issue seems to be connected to my guix instance on the host.
Glad to hear you figured it out.
> Then it switches to black screen
That should mean that the graphic-card is not set up properly.
But additionally U-Boot, GRUB or the kernel could be hanging. :-/
> I'm testing this on Raspberry Pi 4.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Fri, 12 Aug 2022 14:28:01 GMT) (full text, mbox, link).
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
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Sat, 13 Aug 2022 12:48:52 +0200
Hi Petr!
> Good news. I managed to run Guix libre kernel on the raspberry pi.
Woot! Great!
> The issue was in the firmware
Good to know!
> I'll test it also on RPi3
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
> I just have question regarding the example if it wouldn't be better to prepare the whole image
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.
> 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?
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.
> 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?
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.
> Also there's small patch to fix deprecated calls in os-defintion files.
Thanks, much appreciated!
Bye
Stefan
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 14 Aug 2022 10:00:02 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Sun, 14 Aug 2022 09:59:04 +0000
Hi Stefan!
> > I'll test it also on RPi3
I got it working also there. I do have RPi2 but I doubt it will run there as it's just not that powerful.
> > I just have question regarding the example if it wouldn't be better to prepare the whole image
>
>
> 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.
>
Yes, the focus should be on mainlining these changes first.
> > 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?
>
>
> 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.
>
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 14 Aug 2022 11:36:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Sun, 14 Aug 2022 13:35:13 +0200
Hi Petr!
> I got it working also there.
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 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 :-)
I never tried it. It may be possible.
Bye
Stefan
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 01 Sep 2022 23:56:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Fri, 2 Sep 2022 01:55:28 +0200
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Fri, 02 Sep 2022 05:51:02 GMT) (full text, mbox, link).
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!
>
> 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
Subject: Re: [PATCH v3] Install guix system on Raspberry Pi
Date: Sun, 4 Sep 2022 20:41:48 +0200
Hi Petr!
> I'll check and post the config here but I don't have Raspberry Pi currently with me.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 22 Sep 2022 16:20:01 GMT) (full text, mbox, link).
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
Cc: Vagrant Cascadian <vagrant@debian.org>,
Danny Milosavljevic <dannym@scratchpost.org>, phodina <phodina@protonmail.com>,
48314@debbugs.gnu.org
Subject: Re: [PATCH v5] Install guix system on Raspberry Pi
Date: Wed, 05 Oct 2022 15:02:53 +0200
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:
> 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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sat, 08 Oct 2022 16:23:02 GMT) (full text, mbox, link).
On 2022-09-22, Stefan wrote:
> I did a rebase onto commit 2e8b4f9bfa00489fd3acff305837a79af236e183.
Thanks! It definitely looks like great progress.
> 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.
Great!
> There is a new u-boot-rockpro64-rk3399 which I adapted as well to use
> the #:configs keyword argument.
I like how that works.
> The function modify-defconfig in guix/build/kconfig.scm no longer
> interprets "CONFIG_XY=" like "# CONFIG_XY is not set".
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!
> gnu: linux: Fix the extra-version parameter in make-linux-libre*.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/linux.scm (make-linux-libre*) ['set-environment]: Make
> the Makefile accept EXTRAVERSION from the environment. Fix the usage of
> an empty extra-version string. Split this new phase out of and adding
> if before …
> ['configure]: … to make the phases more hackable.
Overall, this looks good, to me, though have one question...
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 306c18e398..1a35e857c3 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
...
> @@ -824,8 +825,8 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
> (lambda _
> (substitute* (find-files "." "^Makefile(\\.include)?$")
> (("/bin/pwd") "pwd"))))
> - (replace 'configure
> - (lambda* (#:key inputs target #:allow-other-keys)
> + (add-before 'configure 'set-environment
> + (lambda* (#:key target #:allow-other-keys)
> ;; Avoid introducing timestamps.
> (setenv "KCONFIG_NOTIMESTAMP" "1")
> (setenv "KBUILD_BUILD_TIMESTAMP"
> @@ -847,13 +848,16 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
> (setenv "CROSS_COMPILE" (string-append target "-"))
> (format #t "`CROSS_COMPILE' set to `~a'~%"
> (getenv "CROSS_COMPILE"))))
> -
> + ;; Allow EXTRAVERSION to be set via the environment.
> + (substitute* "Makefile"
> + (("^ *EXTRAVERSION[[:blank:]]*=") "EXTRAVERSION ?="))
> (setenv "EXTRAVERSION"
> #$(and extra-version
> - (string-append "-" extra-version)))
> -
> + (not (string-null? extra-version))
> + (string-append "-" extra-version)))))
> + (replace 'configure
> + (lambda* (#:key inputs #:allow-other-keys)
> (let ((config (assoc-ref inputs "kconfig")))
> -
> ;; Use a custom kernel configuration file or a default
> ;; configuration file.
> (if config
> @@ -871,7 +875,7 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
>
> (invoke "make" "oldconfig"))))
> (replace 'install
> - (lambda* (#:key inputs native-inputs #:allow-other-keys)
> + (lambda* (#:key inputs #:allow-other-keys)
> (let ((moddir (string-append #$output "/lib/modules"))
> (dtbdir (string-append #$output "/lib/dtbs")))
> ;; Install kernel image, kernel configuration and link map.
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.
> gnu: bootloader: Rework chaining, add grub-efi-netboot-removable-bootloader.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * doc/guix.texi (Bootloader Configuration): Describe the new
> ‘grub-efi-netboot-removable-bootloader’. Mention used sub-directories and
> that the UEFI Boot Manager is not modified. Advice to disable write-access
> over TFTP.
> * gnu/bootloader.scm (efi-bootloader-profile): Allow a list of packages and
> collect everything directly in the profile, avoiding a separate collection
> directory. Renamed the profile from "bootloader-profile" to
> "efi-bootloader-profile".
> [bootloader-collection]: Renamed to …
> [efi-bootloader-profile-hook]: … this and removed unused modules and the
> creation of the now unneeded collection directory.
> (efi-bootloader-chain): Added packages and disk-image-installer arguments.
> Removed handling of the collection directory, now only calling the given
> installer procedure.
> * gnu/bootloader/grub.scm (make-grub-efi-netboot-installer): New helper.
> (make-grub-configuration): New helper based on (grub-configuration-file).
> Adding grub argument, fixed indentation, removend code to get grub.
> (grub-configuration-file): Now using (make-grub-configuration).
> (grub-efi-configuration-file): New function using (make-grub-configuration).
> Instead of getting the grub-efi package from the bootloader-configuration
> this function refers to the grub-efi package directly.
> (grub-cfg): New variable to replace "/boot/grub/grub.cfg".
> (install-grub-efi-netboot): Removed, the functionality got moved.
> (make-grub-efi-netboot-installer): New helper function to return a customized
> installer for a certain efi-sub-directory. The installer basically copies
> a pre-installed efi-bootloader-profile, and adds needed symlinks for booting
> over network, or – on an ESP – an intermediate grub-cfg to load the final
> grub-cfg file.
> (grub-bootloader): Now using the grub-cfg variable.
> (grub-efi-bootloader): Now using the grub-cfg variable. Removed inheritance,
> giving complete set of fields.
> (make-grub-efi-netboot-bootloader): New helper function.
> (grub-efi-netboot-bootloader): Now using the helper.
> (grub-efi-netboot-removable-bootloader): New bootloader using the helper.
> It uses the efi-sub-directory "efi/boot" for removable media.
> * gnu/packages/bootloaders.scm (make-grub-efi-netboot): New function to return
> a grub-efi package pre-installed via grub-mknetdir, customized for an
> efi-sub-directory and able to boot via network and local storage.
>
> The rework allows to use an (efi-bootloader-chain) like this, which is able
> to boot over network or local storage, depending on the symlink-support at
> the bootloader-target:
>
> (operating-system
> (bootloader
> (bootloader-configuration
> (bootloader
> (efi-bootloader-chain
> grub-efi-netboot-removable-bootloader
> #:packages (list my-firmware-package
> my-u-boot-package)
> #:files (list (plain-file "config.txt"
> "kernel=u-boot.bin"))
> #:hooks my-special-bootloader-profile-manipulator))
> (target "/booti/efi")
> …))
> …)
> )
> ---
> doc/guix.texi | 58 ++++++++---
> gnu/bootloader.scm | 104 ++++++++++----------
> gnu/bootloader/grub.scm | 215 ++++++++++++++++++++++++++----------------
> gnu/packages/bootloaders.scm | 90 ++++++++++++++++++
> 4 files changed, 318 insertions(+), 149 deletions(-)
There is too much going on here for me to follow, but it is perhaps just
doing a lot of big changes... help? :)
> build: kconfig: Add new module to modify defconfig files.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * guix/build/kconfig.scm (config-string->pair, (pair->config-string,
> defconfig->alist, modify-defconfig, verify-config): New file with
> functions for handling of defconfig and .config files.
> * gnu/packages/bootloaders.scm (make-u-boot-package,
> make-u-boot-sunxi64-package): Adding new keyword arguments to pass and/
> or modify a defconfig file.
> (u-boot-{am335x-boneblack,pinebook,u-boot-novena,rockpro64-rk3399}):
> Simplify packages by using the new keyword arguments of the former
> functions.
> * Makefile.am: Adding guix/build/kconfig.scm to MODULES.
> ---
> Makefile.am | 1
> gnu/packages/bootloaders.scm | 111 +++++++++++--------------
> guix/build/kconfig.scm | 185 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 234 insertions(+), 63 deletions(-)
> create mode 100644 guix/build/kconfig.scm
I like how this simplifies the various u-boot-* package definitions!
> gnu: bootloader: Add U-Boot packages for Raspberry Pi models.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/bootloader.scm (make-u-boot-package): Add keyword
> parameters 'name-suffix' and 'append-description'.
This seems good to me.
> (make-u-boot-bin-package): New function to make minimal packages.
> (%u-boot-rpi-efi-configs): New helper list with config strings.
> (%u-boot-rpi-description-32-bit, %u-boot-rpi-description-64-bit,
> %u-boot-rpi-efi-description, %u-boot-rpi-efi-description-32-bit):
> New helper strings.
> (u-boot-rpi-2{,-efi,-bin,-efi-bin},
> u-boot-rpi-3-32b{,-efi,-bin,-efi-bin},
> u-boot-rpi-4-32b{,-efi,-bin,-efi-bin},
> u-boot-rpi-arm64{,-efi,-bin,-efi-bin}): New packages.
> (u-boot-tools): Reuse the description of u-boot.
> (u-boot-{am335x-boneblack,am335x-evm,nintendo-nes-classic-edition,
> novena}): Make use of new keyword parameters of make-u-boot-package.
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.
> gnu: linux: New function to modify the configuration of a Linux kernel.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/linux.scm (system->linux-srcarch): New function to return the
> relevent folder name below arch/ in the Linux source code.
> (modify-linux): New function to make a customized Linux package inherited
> from another Linux package, which will be build with an own defconfig or
> configuration changes.
> (make-defconfig): Function to get a defconfig from an uri.
> ---
> gnu/packages/linux.scm | 123 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
Looks ok to me, though to say I fully understand it would be a stretch. :)
> gnu: raspberry-pi: Add defconfig objects to build customized Linux kernels.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> gnu/packages/raspberry-pi.scm (make-raspi-defconig): New function to make
> downloaded defconfig objects from the Linux repository of the Raspberry Pi
> Foundation.
> (%bcm2709-defconfig, %bcm2711-defconfig, %bcm2711-defconfig-64,
> %bcmrpi3-defconfig): New variables containing defconfig objects to build
> Linux kernels customized for Raspberry Pi single board computers.
> ---
> gnu/packages/raspberry-pi.scm | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
Seems good. I think I even understand this one!
> gnu: raspberry-pi: Add helpers for config.txt file generation.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/raspberry-pi.scm (raspi-config-file, raspi-custom-txt):
> New functions.
> (%raspi-config-txt, %raspi-bcm27-dtb-txt, %raspi-bcm28-dtb-txt
> %raspi-u-boot-bootloader-txt): New variables.
> ---
> gnu/packages/raspberry-pi.scm | 53 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
Seems good.
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/raspberry-pi.scm (make-raspi-bcm28-dtbs): New function to make
> a package with device-tree files for Raspberry Pi models from the kernel given
> as argument.
> ---
> gnu/packages/raspberry-pi.scm | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/gnu/packages/raspberry-pi.scm b/gnu/packages/raspberry-pi.scm
> index 12a919d5c6..92f5d22677 100644
> --- a/gnu/packages/raspberry-pi.scm
> +++ b/gnu/packages/raspberry-pi.scm
> @@ -30,6 +30,7 @@
> #:use-module (gnu packages file)
> #:use-module (gnu packages gcc)
> #:use-module (gnu packages linux)
> + #:use-module (guix build-system copy)
> #:use-module (guix build-system gnu)
> #:use-module (guix download)
> #:use-module (guix git-download)
> @@ -291,6 +292,26 @@ CONTENT can be a list of strings, which are concatenated with a newline
> character. Alternatively CONTENT can be a string with the full file content."
> (raspi-config-file "custom.txt" content))
>
> +(define-public (make-raspi-bcm28-dtbs linux)
> + "Make a package with the device-tree files for Raspberry Pi models from the
> +kernel LINUX."
> + (package
> + (inherit linux)
> + (name "raspi-bcm28-dtbs")
> + (source #f)
> + (build-system copy-build-system)
> + (arguments
> + `(#:phases (modify-phases %standard-phases (delete 'unpack))
> + #:install-plan
> + (list (list (string-append (assoc-ref %build-inputs "linux")
> + "/lib/dtbs/broadcom/")
> + "." #:include-regexp '("/bcm....-rpi.*\\.dtb")))))
> + (inputs `(("linux" ,linux)))
> + (synopsis "Device-tree files for a Raspberry Pi")
> + (description
> + (simple-format #f "The device-tree files for Raspberry Pi models from ~a."
> + (package-name linux)))))
> +
> (define (make-raspi-defconfig arch defconfig sha256-as-base32)
> "Make for the architecture ARCH a file-like object from the DEFCONFIG file
> with the hash SHA256-AS-BASE32. This object can be used as the #:defconfig
> gnu: raspberry-pi: Add a bootloader-chain for the Raspberry Pi and os examples.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/raspberry-pi.scm (grub-efi-bootloader-chain-raspi-64): New
> bootloader variable, capable to boot a Raspberry Pi over network or from a
> local storage.
> * gnu/system/examples/raspberry-pi-64.tmpl: New operating-system example.
> * gnu/system/examples/raspberry-pi-64-nfs-root.tmpl: New operating-system
> example for booting over network.
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
Cc: Danny Milosavljevic <dannym@scratchpost.org>,
Ludovic Courtès <ludo@gnu.org>,
phodina <phodina@protonmail.com>, 48314@debbugs.gnu.org
Subject: Re: [PATCH v5] Install guix system on Raspberry Pi
Date: Sun, 9 Oct 2022 15:41:08 +0200
Hi Vagrant!
>> The function modify-defconfig in guix/build/kconfig.scm no longer
>> interprets "CONFIG_XY=" like "# CONFIG_XY is not set".
>
> Nervous about how that actually works, but hopefully it plays out correctly.
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.
> 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.
I’ll try to help.
> 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…
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.
> With all that out of the way... here goes my attempt to review!
>
>
>> gnu: linux: Fix the extra-version parameter in make-linux-libre*.
> Overall, this looks good, to me, though have one question…
Great! :-)
> 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.
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.
>> gnu: bootloader: Rework chaining, add grub-efi-netboot-removable-bootloader.
> There is too much going on here for me to follow, but it is perhaps just
> doing a lot of big changes… help? :)
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.
>> build: kconfig: Add new module to modify defconfig files.
> I like how this simplifies the various u-boot-* package definitions!
Great! :-)
>> gnu: bootloader: Add U-Boot packages for Raspberry Pi models.
> This seems good to me.
Great! :-)
> 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.
Splitting is possible.
>> gnu: linux: New function to modify the configuration of a Linux kernel.
> Looks ok to me, though to say I fully understand it would be a stretch. :)
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. :-)
>> gnu: raspberry-pi: Add defconfig objects to build customized Linux kernels.
> Seems good. I think I even understand this one!
Great! :-)
>> gnu: raspberry-pi: Add helpers for config.txt file generation.
> Seems good.
Great! :-)
>> gnu: raspberry-pi: Add a bootloader-chain for the Raspberry Pi and os examples.
> 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.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 30 Oct 2022 12:40:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v5] Install guix system on Raspberry Pi
Date: Sun, 30 Oct 2022 12:39:13 +0000
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 30 Oct 2022 17:09:02 GMT) (full text, mbox, link).
Subject: Re: [PATCH v5] Install guix system on Raspberry Pi
Date: Sun, 30 Oct 2022 18:08:01 +0100
Hi Petr!
> Shoudn't the initrd be placed in the EFI partition?
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.
> Should I copy it and modify the Grub entry?
No.
> Unfortunately I get error about missing file:
>
> ```
> error: file /gnu/store/xxx-raw-initrd/initrd.cpio.gz not found
> Press any key to continue ...
> ```
Is this error from GRUB? Is that file actually existing?
> 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.
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?
> The goal here is to run completly from USB then there won't be any need for SD card.
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 30 Oct 2022 17:33:01 GMT) (full text, mbox, link).
Subject: Re: [PATCH v5] Install guix system on Raspberry Pi
Date: Sun, 30 Oct 2022 18:31:43 +0100
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
> Am 30.10.2022 um 18:08 schrieb Stefan <stefan-guix@vodafonemail.de>:
>
> Hi Petr!
>
>> Shoudn't the initrd be placed in the EFI partition?
>
> 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.
>
>> Should I copy it and modify the Grub entry?
>
> No.
>
>> Unfortunately I get error about missing file:
>>
>> ```
>> error: file /gnu/store/xxx-raw-initrd/initrd.cpio.gz not found
>> Press any key to continue ...
>> ```
>
> Is this error from GRUB? Is that file actually existing?
>
>> 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.
>
> 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?
>
>> The goal here is to run completly from USB then there won't be any need for SD card.
>
>
> 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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 30 Oct 2022 17:34:02 GMT) (full text, mbox, link).
Subject: [PATCH v5] Install guix system on Raspberry Pi
Date: Sun, 30 Oct 2022 18:32:59 +0100
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sun, 30 Oct 2022 17:35:02 GMT) (full text, mbox, link).
Subject: Re: bug#48314: [PATCH] Install guix system on Raspberry Pi
Date: Thu, 01 Dec 2022 09:25:29 -0500
Hi Stefan!
Some comments/question for this proposed change.
Stefan <stefan-guix@vodafonemail.de> writes:
[...]
> gnu: linux: Fix the extra-version parameter in make-linux-libre*.
This first commit LGTM. I'll push it shortly.
[...]
> gnu: bootloader: Rework chaining, add grub-efi-netboot-removable-bootloader.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * doc/guix.texi (Bootloader Configuration): Describe the new
> ‘grub-efi-netboot-removable-bootloader’. Mention used sub-directories and
> that the UEFI Boot Manager is not modified. Advice to disable write-access
> over TFTP.
> * gnu/bootloader.scm (efi-bootloader-profile): Allow a list of packages and
> collect everything directly in the profile, avoiding a separate collection
> directory. Renamed the profile from "bootloader-profile" to
> "efi-bootloader-profile".
> [bootloader-collection]: Renamed to …
> [efi-bootloader-profile-hook]: … this and removed unused modules and the
> creation of the now unneeded collection directory.
> (efi-bootloader-chain): Added packages and disk-image-installer arguments.
> Removed handling of the collection directory, now only calling the given
> installer procedure.
> * gnu/bootloader/grub.scm (make-grub-efi-netboot-installer): New helper.
> (make-grub-configuration): New helper based on (grub-configuration-file).
> Adding grub argument, fixed indentation, removend code to get grub.
> (grub-configuration-file): Now using (make-grub-configuration).
> (grub-efi-configuration-file): New function using (make-grub-configuration).
> Instead of getting the grub-efi package from the bootloader-configuration
> this function refers to the grub-efi package directly.
> (grub-cfg): New variable to replace "/boot/grub/grub.cfg".
> (install-grub-efi-netboot): Removed, the functionality got moved.
> (make-grub-efi-netboot-installer): New helper function to return a customized
> installer for a certain efi-sub-directory. The installer basically copies
> a pre-installed efi-bootloader-profile, and adds needed symlinks for booting
> over network, or – on an ESP – an intermediate grub-cfg to load the final
> grub-cfg file.
> (grub-bootloader): Now using the grub-cfg variable.
> (grub-efi-bootloader): Now using the grub-cfg variable. Removed inheritance,
> giving complete set of fields.
> (make-grub-efi-netboot-bootloader): New helper function.
> (grub-efi-netboot-bootloader): Now using the helper.
> (grub-efi-netboot-removable-bootloader): New bootloader using the helper.
> It uses the efi-sub-directory "efi/boot" for removable media.
> * gnu/packages/bootloaders.scm (make-grub-efi-netboot): New function to return
> a grub-efi package pre-installed via grub-mknetdir, customized for an
> efi-sub-directory and able to boot via network and local storage.
>
> The rework allows to use an (efi-bootloader-chain) like this, which is able
> to boot over network or local storage, depending on the symlink-support at
> the bootloader-target:
>
> (operating-system
> (bootloader
> (bootloader-configuration
> (bootloader
> (efi-bootloader-chain
> grub-efi-netboot-removable-bootloader
> #:packages (list my-firmware-package
> my-u-boot-package)
> #:files (list (plain-file "config.txt"
> "kernel=u-boot.bin"))
> #:hooks my-special-bootloader-profile-manipulator))
> (target "/booti/efi")
> …))
> …)
> )
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).
[...]
> +(define (grub-configuration-file config . args)
> + (let* ((bootloader (bootloader-configuration-bootloader config))
> + (grub (bootloader-package bootloader)))
> + (apply make-grub-configuration grub config args)))
> +
> +(define (grub-efi-configuration-file . args)
> + (apply make-grub-configuration grub-efi args))
> +
> +(define grub-cfg "/boot/grub/grub.cfg")
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?
>
>
> ;;;
> @@ -674,42 +681,31 @@ fi~%"))))
> ((target-arm?) "--target=arm-efi"))
> "--efi-directory" target-esp)))))
>
> -(define (install-grub-efi-netboot subdir)
> - "Define a grub-efi-netboot bootloader installer for installation in SUBDIR,
> -which is usually efi/Guix or efi/boot."
> - (let* ((system (string-split (nix-system->gnu-triplet
> - (or (%current-target-system)
> - (%current-system)))
> - #\-))
> - (arch (first system))
> - (boot-efi-link (match system
> - ;; These are the supportend systems and the names
> - ;; defined by the UEFI standard for removable media.
> - (("i686" _ ...) "/bootia32.efi")
> - (("x86_64" _ ...) "/bootx64.efi")
> - (("arm" _ ...) "/bootarm.efi")
> - (("aarch64" _ ...) "/bootaa64.efi")
> - (("riscv" _ ...) "/bootriscv32.efi")
> - (("riscv64" _ ...) "/bootriscv64.efi")
> - ;; Other systems are not supported, although defined.
> - ;; (("riscv128" _ ...) "/bootriscv128.efi")
> - ;; (("ia64" _ ...) "/bootia64.efi")
> - ((_ ...) #f)))
> - (core-efi (string-append
> - ;; This is the arch dependent file name of GRUB, e.g.
> - ;; i368-efi/core.efi or arm64-efi/core.efi.
> - (match arch
> - ("i686" "i386")
> - ("aarch64" "arm64")
> - ("riscv" "riscv32")
> - (_ arch))
> - "-efi/core.efi")))
> - (with-imported-modules
> - '((guix build union))
> - #~(lambda (bootloader target mount-point)
> - "Install the BOOTLOADER, which must be the package grub, as e.g.
> -bootx64.efi or bootaa64.efi into SUBDIR, which is usually efi/Guix or efi/boot,
> -below the directory TARGET for the system whose root is mounted at MOUNT-POINT.
> +(define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
> + "Make a bootloader-installer for a grub-efi-netboot bootloader, which expects
> +its files in SUBDIR and its configuration file in GRUB-CFG.
> +
> +As a grub-efi-netboot package is already preinstalled by 'grub-mknetdir', the
> +installer basically copies all files from the bootloader-package (or profile)
> +into the bootloader-target directory.
> +
> +Additionally for network booting over TFTP, two relative symlinks to the store
> +and to the GRUB-CFG file are necessary. Due to this a TFTP root directory must
> +not be located on a FAT file-system.
> +
> +If the bootloader-target does not support symlinks, then it is assumed to be a
> +kind of EFI System Partition (ESP). In this case an intermediate configuration
> +file is created with the help of GRUB-EFI to load the GRUB-CFG.
> +
> +The installer is usable for any efi-bootloader-chain, which prepares the
> +bootloader-profile in a way ready for copying.
> +
> +The installer does not manipulate the system's 'UEFI Boot Manager'."
> + (with-imported-modules '((guix build union))
> + #~(lambda (bootloader target mount-point)
> + "Copy the BOOTLOADER, which must be a preinstalled grub-efi-netboot
> +package with a SUBDIR like efi/boot or efi/Guix, below the directory
> +TARGET for the system whose root is mounted at MOUNT-POINT.
>
> MOUNT-POINT is the last argument in 'guix system init /etc/config.scm mnt/point'
> or '/' for other 'guix system' commands.
> @@ -719,17 +715,18 @@ bootloader-configuration in:
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:
--8<---------------cut here---------------start------------->8---
4 files changed, 80 insertions(+), 76 deletions(-)
doc/guix.texi | 17 +++++++++--------
gnu/bootloader.scm | 11 +++++------
gnu/bootloader/grub.scm | 77 ++++++++++++++++++++++++++++++++++++++++-------------------------------------
gnu/packages/bootloaders.scm | 51 ++++++++++++++++++++++++++-------------------------
modified doc/guix.texi
@@ -38083,17 +38083,18 @@ NFS servers, you also need a properly configured DHCP server to make the booting
over netboot possible. For all this we can currently only recommend you to look
for instructions about @acronym{PXE, Preboot eXecution Environment}.
-If a local EFI System Partition (ESP) or a similar partition with a FAT file
-system is mounted in @code{targets}, then symlinks cannot be created. In this
-case everything will be prepared for booting from local storage, simialar as if
-using @code{grub-efi-bootloader}, with the difference that all GRUB binaries
-reside on @code{targets}, too, like needed for booting over network.
+If a local EFI System Partition (ESP) or a similar partition with a FAT
+file system is mounted in @code{targets}, then symlinks cannot be
+created. In this case everything will be prepared for booting from
+local storage, matching the behavior of @code{grub-efi-bootloader}, with
+the difference that all GRUB binaries are copied to @code{targets},
+necessary for booting over the network.
@vindex grub-efi-netboot-removable-bootloader
@code{grub-efi-netboot-removable-bootloader} is identical to
-@code{grub-efi-netboot-bootloader} with the exception that the sub-directory
-@file{efi/boot} will be used instead of @file{efi/Guix} to comply to the UEFI
-specification for removable media.
+@code{grub-efi-netboot-bootloader} with the exception that the
+sub-directory @file{efi/boot} will be used instead of @file{efi/Guix} to
+comply with the UEFI specification for removable media.
@quotation Note
This @emph{will} overwrite the GRUB file from any other operating systems that
modified gnu/bootloader.scm
@@ -361,8 +361,7 @@ (define name-ends-with-/? (cut string-suffix? "/" <>))
(define (name-is-store-entry? name)
"Return #t if NAME is a direct store entry and nothing inside."
(not (string-index (strip-store-file-name name) #\/)))
- (let* ((output #$output)
- (files '#$files)
+ (let* ((files '#$files)
(directories (filter name-ends-with-/? files))
(names-from-directories
(append-map (lambda (directory)
@@ -370,11 +369,11 @@ (define (name-is-store-entry? name)
directories))
(names (append names-from-directories
(remove name-ends-with-/? files))))
- (mkdir-p output)
+ (mkdir-p #$output)
(if (every file-exists? names)
(begin
(for-each (lambda (name)
- (symlink-to name output
+ (symlink-to name #$output
(if (name-is-store-entry? name)
strip-store-file-name
basename)))
@@ -410,7 +409,7 @@ (define* (efi-bootloader-chain final-bootloader
The package of the FINAL-BOOTLOADER and all PACKAGES and FILES will be placed
in an efi-bootloader-profile, which will be passed to the INSTALLER.
-FILES may contain file like objects produced by procedures like plain-file,
+FILES may contain file-like objects produced by procedures like plain-file,
local-file, etc., or package contents produced with file-append.
If a directory name in FILES ends with '/', then the directory content instead
@@ -424,7 +423,7 @@ (define* (efi-bootloader-chain final-bootloader
FINAL-BOOTLOADER will be called.
If the DISK-IMAGE-INSTALLER is used, then this gexp procedure will be called
-to install the efi-bootloader-profile into a disk-image. Otherwise the
+to install the efi-bootloader-profile into a disk image. Otherwise the
disk-image-installer of the FINAL-BOOTLOADER will be called."
(bootloader
(inherit final-bootloader)
modified gnu/bootloader/grub.scm
@@ -685,7 +685,7 @@ (define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
"Make a bootloader-installer for a grub-efi-netboot bootloader, which expects
its files in SUBDIR and its configuration file in GRUB-CFG.
-As a grub-efi-netboot package is already preinstalled by 'grub-mknetdir', the
+As a grub-efi-netboot package is already pre-installed by 'grub-mknetdir', the
installer basically copies all files from the bootloader-package (or profile)
into the bootloader-target directory.
@@ -700,12 +700,12 @@ (define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
The installer is usable for any efi-bootloader-chain, which prepares the
bootloader-profile in a way ready for copying.
-The installer does not manipulate the system's 'UEFI Boot Manager'."
- (with-imported-modules '((guix build union))
- #~(lambda (bootloader target mount-point)
- "Copy the BOOTLOADER, which must be a preinstalled grub-efi-netboot
-package with a SUBDIR like efi/boot or efi/Guix, below the directory
-TARGET for the system whose root is mounted at MOUNT-POINT.
+The installer does not manipulate the system's 'UEFI Boot Manager'.
+
+The returned installer accepts the BOOTLOADER, TARGET and MOUNT-POINT
+arguments. Its job is to copy the BOOTLOADER, which must be a pre-installed
+grub-efi-netboot package with a SUBDIR like efi/boot or efi/Guix, below the
+directory TARGET for the system whose root is mounted at MOUNT-POINT.
MOUNT-POINT is the last argument in 'guix system init /etc/config.scm mnt/point'
or '/' for other 'guix system' commands.
@@ -720,13 +720,14 @@ (define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
…)
TARGET is required to be an absolute directory name, usually mounted via NFS,
-and finally needs to be provided by a TFTP server as the TFTP root directory.
+and finally needs to be provided by a TFTP server as
+the TFTP root directory.
Usually the installer will be used to prepare network booting over TFTP. Then
GRUB will load tftp://server/SUBDIR/grub.cfg and this file will instruct it to
load more files from the store like tftp://server/gnu/store/…-linux…/Image.
-To make this possible two symlinks will be created. The first symlink points
+To make this possible two symlinks are created. The first symlink points
relatively form MOUNT-POINT/TARGET/SUBDIR/grub.cfg to
MOUNT-POINT/boot/grub/grub.cfg, and the second symlink points relatively from
MOUNT-POINT/TARGET/%store-prefix to MOUNT-POINT/%store-prefix.
@@ -740,16 +741,18 @@ (define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
accesses outside its TFTP root directory. This all may need to be considered
for security aspects. It is advised to disable any TFTP write access!
-The installer can also be used to prepare booting from local storages, if the
+The installer can also be used to prepare booting from local storage, if the
underlying file-system, like FAT on an EFI System Partition (ESP), does not
support symlinks. In this case the MOUNT-POINT/TARGET/SUBDIR/grub.cfg will be
created with the help of GRUB-EFI to load the /boot/grub/grub.cfg file. A
symlink to the store is not needed in this case."
+ (with-imported-modules '((guix build union))
+ #~(lambda (bootloader target mount-point)
;; In context of a disk image creation TARGET will be #f and an
;; installer is expected to do necessary installations on MOUNT-POINT,
- ;; which will become the root file system.
- ;; If TARGET is #f, this installer has nothing to do, as it only cares
- ;; about the EFI System Partition (ESP).
+ ;; which will become the root file system. If TARGET is #f, this
+ ;; installer has nothing to do, as it only cares about the EFI System
+ ;; Partition (ESP).
(when target
(use-modules ((guix build union) #:select (symlink-relative))
(ice-9 popen)
@@ -779,35 +782,35 @@ (define* (make-grub-efi-netboot-installer grub-efi grub-cfg subdir)
(mkdir-p (dirname grub-cfg-link))
(false-if-exception (delete-file grub-cfg-link))
(if (unspecified?
- (false-if-exception (symlink-relative grub-cfg grub-cfg-link)))
- ;; Symlinks are supported.
- (begin
- ;; Prepare the symlink to the store.
- (mkdir-p (dirname store-link))
- (false-if-exception (delete-file store-link))
- (symlink-relative store store-link))
- ;; Creating symlinks does not seem to be supported.
- ;; Probably an ESP is used.
- ;; Instead we can script to search and load the actual grub.cfg.
- (let* ((probe #$(file-append grub-efi "/sbin/grub-probe"))
- (port
- (open-pipe* OPEN_READ probe "--target=fs_uuid" grub-cfg))
- (search-root
- (match (read-line port)
- ((? eof-object?)
+ (false-if-exception (symlink-relative grub-cfg grub-cfg-link)))
+ ;; Symlinks are supported.
+ (begin
+ ;; Prepare the symlink to the store.
+ (mkdir-p (dirname store-link))
+ (false-if-exception (delete-file store-link))
+ (symlink-relative store store-link))
+ ;; Creating symlinks does not seem to be supported. Probably
+ ;; an ESP is used. Add a script to search and load the actual
+ ;; grub.cfg.
+ (let* ((probe #$(file-append grub-efi "/sbin/grub-probe"))
+ (port (open-pipe* OPEN_READ probe "--target=fs_uuid"
+ grub-cfg))
+ (search-root
+ (match (read-line port)
+ ((? eof-object?)
;; There is no UUID available. As a fallback search
;; everywhere for the grub.cfg.
(string-append "search --file --set " #$grub-cfg))
- (fs-uuid
+ (fs-uuid
;; The UUID to load the grub.cfg from is known.
(string-append "search --fs-uuid --set " fs-uuid))))
- (load-grub-cfg (string-append "configfile " #$grub-cfg)))
- (close-pipe port)
- (with-output-to-file grub-cfg-link
- (lambda ()
- (display (string-join (list search-root
- load-grub-cfg)
- "\n")))))))))))
+ (load-grub-cfg (string-append "configfile " #$grub-cfg)))
+ (close-pipe port)
+ (with-output-to-file grub-cfg-link
+ (lambda ()
+ (display (string-join (list search-root
+ load-grub-cfg)
+ "\n")))))))))))
modified gnu/packages/bootloaders.scm
@@ -427,8 +427,8 @@ (define-public (make-grub-efi-netboot name subdir)
(build-system trivial-build-system)
(arguments
(let* ((system (string-split (nix-system->gnu-triplet
- (or (%current-target-system)
- (%current-system)))
+ (or (%current-target-system)
+ (%current-system)))
#\-))
(arch (first system))
(boot-efi
@@ -454,29 +454,30 @@ (define-public (make-grub-efi-netboot name subdir)
("riscv" "riscv32")
(_ arch))
"-efi/core.efi")))
- `(#:modules ((guix build utils))
- #:builder
- (begin
- (use-modules (guix build utils))
- (let* ((bootloader (assoc-ref %build-inputs "grub-efi"))
- (net-dir (assoc-ref %outputs "out"))
- (sub-dir (string-append net-dir "/" ,subdir "/"))
- (boot-efi (string-append sub-dir ,boot-efi))
- (core-efi (string-append sub-dir ,core-efi)))
- ;; Install GRUB, which refers to the grub.cfg, with support for
- ;; encrypted partitions,
- (setenv "GRUB_ENABLE_CRYPTODISK" "y")
- (invoke/quiet (string-append bootloader "/bin/grub-mknetdir")
- (string-append "--net-directory=" net-dir)
- (string-append "--subdir=" ,subdir)
- ;; These modules must be preloaded to allow booting
- ;; from an ESP or a similar partition with a FAT
- ;; file system.
- (string-append "--modules=part_msdos part_gpt fat"))
- ;; Move GRUB's core.efi to the removable media name.
- (false-if-exception (delete-file boot-efi))
- (rename-file core-efi boot-efi))))))
- (inputs `(("grub-efi" ,grub-efi)))
+ (list
+ #:modules ((guix build utils))
+ #:builder
+ #~(begin
+ (use-modules (guix build utils))
+ (let* ((bootloader #$(this-package-input "grub-efi"))
+ (net-dir #$output)
+ (sub-dir (string-append net-dir "/" #$subdir "/"))
+ (boot-efi (string-append sub-dir #$boot-efi))
+ (core-efi (string-append sub-dir #$core-efi)))
+ ;; Install GRUB, which refers to the grub.cfg, with support for
+ ;; encrypted partitions,
+ (setenv "GRUB_ENABLE_CRYPTODISK" "y")
+ (invoke/quiet (string-append bootloader "/bin/grub-mknetdir")
+ (string-append "--net-directory=" net-dir)
+ (string-append "--subdir=" #$subdir)
+ ;; These modules must be pre-loaded to allow booting
+ ;; from an ESP or a similar partition with a FAT
+ ;; file system.
+ (string-append "--modules=part_msdos part_gpt fat"))
+ ;; Move GRUB's core.efi to the removable media name.
+ (false-if-exception (delete-file boot-efi))
+ (rename-file core-efi boot-efi))))))
+ (inputs (list grub-efi))
(synopsis (package-synopsis grub-efi))
(description (package-description grub-efi))
(home-page (package-home-page grub-efi))
--8<---------------cut here---------------end--------------->8---
It's a pity we do not have tests for that, but I'll try to test it
manually and if it works I can push it shortly. I'd still like feedback
on my question above.
--
Thanks,
Maxim
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 01 Dec 2022 15:33:01 GMT) (full text, mbox, link).
Subject: Re: bug#48314: [PATCH] Install guix system on Raspberry Pi
Date: Thu, 01 Dec 2022 11:22:41 -0500
Hi,
Stefan <stefan-guix@vodafonemail.de> writes:
[...]
> new file mode 100644
> index 0000000000..0cfaffe056
> --- /dev/null
> +++ b/guix/build/kconfig.scm
[...]
> +(define-module (guix build kconfig)
> + #:use-module (ice-9 rdelim)
> + #:use-module (ice-9 regex)
> + #:use-module (srfi srfi-1)
> + #:use-module (srfi srfi-26)
> + #:export (modify-defconfig
> + verify-config))
> +
> +;; Commentary:
> +;;
> +;; Builder-side code to modify configurations for the Kconfig build system as
> +;; used by Linux and U-Boot.
> +;;
> +;; Code:
> +
> +(define (config-string->pair config-string)
> + "Parse a configuration string like \"CONFIG_EXAMPLE=m\" into a key-value pair.
> +An error is thrown for invalid configurations.
> +
> +\"CONFIG_A=y\" -> '(\"CONFIG_A\" . \"y\")
> +\"CONFIG_B=\\\"\\\"\" -> '(\"CONFIG_B\" . \"\\\"\\\"\")
> +\"CONFIG_C=\" -> '(\"CONFIG_C\" . \"\")
> +\"# CONFIG_E is not set\" -> '(\"CONFIG_E\" . #f)
> +\"CONFIG_D\" -> '(\"CONFIG_D\" . #f)
> +\"# Any comment\" -> '(#f . \"# Any comment\")
> +\"\" -> '(#f . \"\")
> +\"# CONFIG_E=y\" -> (error \"Invalid configuration\")
> +\"CONFIG_E is not set\" -> (error \"Invalid configuration\")
> +\"Anything else\" -> (error \"Invalid configuration\")"
> + (define config-regexp
> + (make-regexp
> + ;; (match:substring (string-match "=(.*)" "=") 1) returns "", but the
> + ;; pattern "=(.+)?" makes it return #f instead. From a "CONFIG_A=" we like
> + ;; to get "", which later emits "CONFIG_A=" again.
> + "^ *(#[\\t ]*)?(CONFIG_[a-zA-Z0-9_]+)([\\t ]*=[\\t ]*(.*)|([\\t ]+is[\\t ]+not[\\t ]+set))?$"))
> +
> + (define config-comment-regexp
> + (make-regexp "^([\\t ]*(#.*)?)$"))
> +
> + (let ((match (regexp-exec config-regexp (string-trim-right config-string))))
> + (if match
> + (let* ((comment (match:substring match 1))
> + (key (match:substring match 2))
> + (unset (match:substring match 5))
> + (value (and (not comment)
> + (not unset)
> + (match:substring match 4))))
> + (if (eq? (not comment) (not unset))
> + ;; The key is uncommented and set or commented and unset.
> + (cons key value)
> + ;; The key is set or unset ambigiously.
> + (error (format #f "Invalid configuration, did you mean \"~a\"?"
> + (pair->config-string (cons key #f)))
> + config-string)))
> + ;; This is not a valid or ambigious config-string, but mayby a comment.
> + (if (regexp-exec config-comment-regexp config-string)
> + ;; We keep valid comments.
> + (cons #f config-string)
> + (error "Invalid configuration" config-string)))))
> +
> +(define (pair->config-string pair)
> + "Convert a PAIR back to a config-string."
> + (let* ((key (first pair))
> + (value (cdr pair)))
> + (if (string? key)
> + (if (string? value)
> + (string-append key "=" value)
> + (string-append "# " key " is not set"))
> + value)))
> +
> +(define (defconfig->alist defconfig)
> + "Convert the content of a DEFCONFIG (or .config) file into an alist."
> + (with-input-from-file defconfig
> + (lambda ()
> + (let loop ((alist '())
> + (line (read-line)))
> + (if (eof-object? line)
> + ;; Building the alist is done, now check for duplicates.
> + (let loop ((keys (map first (filter first alist)))
^
What is this filter used for here? EDIT: saw later, it's used to filter
out comments.
[...]
> +(define (verify-config config defconfig)
> + "Verify that the CONFIG file contains all configurations from the DEFCONFIG
> +file and return #t in this case. Otherwise throw an error with the mismatching
> +keys and their values."
> + (let* ((config-pairs (defconfig->alist config))
> + (defconfig-pairs (defconfig->alist defconfig))
> + (mismatching-pairs
> + (remove (lambda (pair)
> + ;; Remove all configurations, whose values are #f and whose
> + ;; keys are not in config-pairs, as not in config-pairs
> + ;; means unset, …
> + (and (not (cdr pair))
> + (not (assoc-ref config-pairs (first pair)))))
> + ;; … from the defconfig-pairs different to config-pairs.
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?
> + (lset-difference equal?
> + ;; Remove comments by filtering with first.
> + (filter first defconfig-pairs)
> + config-pairs))))
> + (if (null? mismatching-pairs)
> + #t
> + (error (format #f
> + "Mismatching configurations in ~a and ~a"
> + config
> + defconfig)
> + (map (lambda (mismatching-pair)
> + (let* ((key (first mismatching-pair))
> + (defconfig-value (cdr mismatching-pair))
> + (config-value (assoc-ref config-pairs key)))
> + (cons key (list (list config-value defconfig-value)))))
> + mismatching-pairs)))))
>
>
I've made the following mostly cosmetic changes:
--8<---------------cut here---------------start------------->8---
2 files changed, 43 insertions(+), 45 deletions(-)
gnu/packages/bootloaders.scm | 18 +++++++++---------
guix/build/kconfig.scm | 70 ++++++++++++++++++++++++++++++++++------------------------------------
modified gnu/packages/bootloaders.scm
@@ -792,9 +792,9 @@ (define*-public (make-u-boot-package board triplet #:key defconfig configs)
"_" "-")))
(native-inputs
`(,@(if (not (same-arch?))
- `(("cross-gcc" ,(cross-gcc triplet))
- ("cross-binutils" ,(cross-binutils triplet)))
- `())
+ `(("cross-gcc" ,(cross-gcc triplet))
+ ("cross-binutils" ,(cross-binutils triplet)))
+ `())
,@(package-native-inputs u-boot)))
(arguments
`(#:modules ((ice-9 ftw)
@@ -808,8 +808,8 @@ (define*-public (make-u-boot-package board triplet #:key defconfig configs)
#:make-flags
(list "HOSTCC=gcc"
,@(if (not (same-arch?))
- `((string-append "CROSS_COMPILE=" ,triplet "-"))
- '()))
+ `((string-append "CROSS_COMPILE=" ,triplet "-"))
+ '()))
#:phases
(modify-phases %standard-phases
(replace 'configure
@@ -828,7 +828,7 @@ (define*-public (make-u-boot-package board triplet #:key defconfig configs)
(apply invoke "make" `(,@make-flags ,config-name))
(verify-config ".config" config-file))
(begin
- (display "Invalid board name. Valid board names are:"
+ (display "invalid board name; valid board names are:"
(current-error-port))
(let ((suffix-len (string-length "_defconfig"))
(entries (scandir "configs")))
@@ -839,7 +839,7 @@ (define*-public (make-u-boot-package board triplet #:key defconfig configs)
(string-drop-right file-name
suffix-len))))
(sort entries string-ci<)))
- (error "Invalid boardname ~s." ,board))))))
+ (error "invalid boardname ~s" ,board))))))
(add-after 'configure 'disable-tools-libcrypto
;; Disable libcrypto due to GPL and OpenSSL license
;; incompatibilities
@@ -881,8 +881,8 @@ (define-public u-boot-malta
(define-public u-boot-am335x-boneblack
(let ((base (make-u-boot-package "am335x_evm" "arm-linux-gnueabihf"
- ;; Patch out other device trees to build image small enough to
- ;; fit within typical partitioning schemes where the first
+ ;; Patch out other device trees to build an image small enough
+ ;; to fit within typical partitioning schemes where the first
;; partition begins at sector 2048.
#:configs '("CONFIG_OF_LIST=\"am335x-evm am335x-boneblack\""))))
(package
modified guix/build/kconfig.scm
@@ -50,7 +50,8 @@ (define config-regexp
;; (match:substring (string-match "=(.*)" "=") 1) returns "", but the
;; pattern "=(.+)?" makes it return #f instead. From a "CONFIG_A=" we like
;; to get "", which later emits "CONFIG_A=" again.
- "^ *(#[\\t ]*)?(CONFIG_[a-zA-Z0-9_]+)([\\t ]*=[\\t ]*(.*)|([\\t ]+is[\\t ]+not[\\t ]+set))?$"))
+ (string-append "^ *(#[\\t ]*)?(CONFIG_[a-zA-Z0-9_]+)([\\t ]*="
+ "[\\t ]*(.*)|([\\t ]+is[\\t ]+not[\\t ]+set))?$")))
(define config-comment-regexp
(make-regexp "^([\\t ]*(#.*)?)$"))
@@ -67,13 +68,13 @@ (define config-comment-regexp
;; The key is uncommented and set or commented and unset.
(cons key value)
;; The key is set or unset ambigiously.
- (error (format #f "Invalid configuration, did you mean \"~a\"?"
+ (error (format #f "invalid configuration, did you mean \"~a\"?"
(pair->config-string (cons key #f)))
config-string)))
- ;; This is not a valid or ambigious config-string, but mayby a comment.
+ ;; This is not a valid or ambigious config-string, but maybe a
+ ;; comment.
(if (regexp-exec config-comment-regexp config-string)
- ;; We keep valid comments.
- (cons #f config-string)
+ (cons #f config-string) ;keep valid comments
(error "Invalid configuration" config-string)))))
(define (pair->config-string pair)
@@ -94,6 +95,7 @@ (define (defconfig->alist defconfig)
(line (read-line)))
(if (eof-object? line)
;; Building the alist is done, now check for duplicates.
+ ;; Note: the filter invocation is used to remove comments.
(let loop ((keys (map first (filter first alist)))
(duplicates '()))
(if (null? keys)
@@ -102,11 +104,11 @@ (define (defconfig->alist defconfig)
(if (null? duplicates)
alist
(error
- (format #f "Duplicate configurations in ~a" defconfig)
+ (format #f "duplicate configurations in ~a" defconfig)
duplicates))
;; Continue the search for duplicates.
(loop (cdr keys)
- (if (member (first keys) (cdr keys) equal?)
+ (if (member (first keys) (cdr keys))
(cons (first keys) duplicates)
duplicates))))
;; Build the alist.
@@ -127,13 +129,13 @@ (define (modify-defconfig defconfig configs)
\"CONFIG_D=m\"
\"CONFIG_E=\"
\"# CONFIG_G is not set\"
- ;; For convinience this abbrevation can be used for not set configurations.
+ ;; For convenience this abbrevation can be used for not set configurations.
\"CONFIG_F\")
-Instead of a list, CONFGIS can be a string with one configuration per line."
- (let* (;; Split the configs into a list of single configuations.
- ;; To minimize mistakes, we support a string and a list of strings,
- ;; each with newlines to separate configurations.
+Instead of a list, CONFIGS can be a string with one configuration per line."
+ (let* (;; Split the configs into a list of single configurations. Both a
+ ;; string and or a list of strings is supported, each with newlines
+ ;; to separate configurations.
(config-pairs (map config-string->pair
(append-map (cut string-split <> #\newline)
(if (string? configs)
@@ -141,45 +143,41 @@ (define (modify-defconfig defconfig configs)
configs))))
;; Generate a blocklist from all valid keys in config-pairs.
(blocklist (delete #f (map first config-pairs)))
- ;; Generate an alist from the defconifg without the keys in blocklist.
+ ;; Generate an alist from the defconfig without the keys in blocklist.
(filtered-defconfig-pairs (remove (lambda (pair)
(member (first pair) blocklist))
(defconfig->alist defconfig))))
(with-output-to-file defconfig
(lambda ()
- (for-each
- (lambda (pair)
- (display (pair->config-string pair))
- (newline))
- (append filtered-defconfig-pairs config-pairs))))))
+ (for-each (lambda (pair)
+ (display (pair->config-string pair))
+ (newline))
+ (append filtered-defconfig-pairs config-pairs))))))
(define (verify-config config defconfig)
"Verify that the CONFIG file contains all configurations from the DEFCONFIG
-file and return #t in this case. Otherwise throw an error with the mismatching
-keys and their values."
+file. When the verification fails, raise an error with the mismatching keys
+and their values."
(let* ((config-pairs (defconfig->alist config))
(defconfig-pairs (defconfig->alist defconfig))
(mismatching-pairs
(remove (lambda (pair)
- ;; Remove all configurations, whose values are #f and whose
- ;; keys are not in config-pairs, as not in config-pairs
- ;; means unset, …
+ ;; Remove all configurations, whose values are #f and
+ ;; whose keys are not in config-pairs, as not in
+ ;; config-pairs means unset, ...
(and (not (cdr pair))
(not (assoc-ref config-pairs (first pair)))))
- ;; … from the defconfig-pairs different to config-pairs.
+ ;; ... from the defconfig-pairs different to config-pairs.
(lset-difference equal?
;; Remove comments by filtering with first.
(filter first defconfig-pairs)
config-pairs))))
- (if (null? mismatching-pairs)
- #t
- (error (format #f
- "Mismatching configurations in ~a and ~a"
- config
- defconfig)
- (map (lambda (mismatching-pair)
- (let* ((key (first mismatching-pair))
- (defconfig-value (cdr mismatching-pair))
- (config-value (assoc-ref config-pairs key)))
- (cons key (list (list config-value defconfig-value)))))
- mismatching-pairs)))))
+ (unless (null? mismatching-pairs)
+ (error (format #f "Mismatching configurations in ~a and ~a"
+ config defconfig)
+ (map (lambda (mismatching-pair)
+ (let* ((key (first mismatching-pair))
+ (defconfig-value (cdr mismatching-pair))
+ (config-value (assoc-ref config-pairs key)))
+ (cons key (list (list config-value defconfig-value)))))
+ mismatching-pairs)))))
--8<---------------cut here---------------end--------------->8---
And streamlined the commit messages as:
--8<---------------cut here---------------start------------->8---
build: kconfig: Add new module to modify defconfig files.
* guix/build/kconfig.scm: New file.
* Makefile.am: Register it.
* gnu/packages/bootloaders.scm (make-u-boot-package)
(make-u-boot-sunxi64-package): Add DEFCONFIGS and CONFIGS arguments.
(u-boot-am335x-boneblack, u-boot-pinebook)
(u-boot-novena,u-boot-rockpro64-rk3399): Simplify packages by using the new
keyword arguments.
--8<---------------cut here---------------end--------------->8---
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Thu, 01 Dec 2022 18:02:01 GMT) (full text, mbox, link).
Subject: Re: bug#48314: [PATCH] Install guix system on Raspberry Pi
Date: Thu, 01 Dec 2022 13:01:36 -0500
Hi,
> gnu: linux: New function to modify the configuration of a Linux kernel.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/linux.scm (system->linux-srcarch): New function to return the
> relevent folder name below arch/ in the Linux source code.
> (modify-linux): New function to make a customized Linux package inherited
> from another Linux package, which will be build with an own defconfig or
> configuration changes.
> (make-defconfig): Function to get a defconfig from an uri.
I've renamed it to customize-linux, and streamlined the commit message
like so:
--8<---------------cut here---------------start------------->8---
gnu: linux: Add a 'customize-linux' procedure.
* gnu/packages/linux.scm (linux-srcarch): New procedure.
(customize-linux): Likewise.
(make-defconfig): Procedure to retrieve a defconfig from an URI.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Modified-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
--8<---------------cut here---------------end--------------->8---
Otherwise, I've made the following changes (exporting procedures
explicitly from the modules):
--8<---------------cut here---------------start------------->8---
1 file changed, 25 insertions(+), 25 deletions(-)
gnu/packages/linux.scm | 50 +++++++++++++++++++++++++-------------------------
modified gnu/packages/linux.scm
@@ -190,19 +190,19 @@ (define-module (gnu packages linux)
#:use-module (srfi srfi-2)
#:use-module (srfi srfi-26)
#:use-module (ice-9 match)
- #:use-module (ice-9 optargs)
- #:use-module (ice-9 regex))
+ #:use-module (ice-9 regex)
+ #:export (customize-linux))
-(define-public (linux-srcarch)
+(define (linux-srcarch)
"Return the linux SRCARCH name, which is set in the toplevel Makefile of
-Linux and denotes the architecture specific directory name below arch/ in its
+Linux and denotes the architecture-specific directory name below arch/ in its
source code. Some few architectures share a common folder. It resembles the
definition of SRCARCH based on ARCH in the Makefile and may be used to place a
defconfig file in the proper path."
(let ((linux-arch (platform-linux-architecture
- (lookup-platform-by-target-or-system
- (or (%current-target-system)
- (%current-system))))))
+ (lookup-platform-by-target-or-system
+ (or (%current-target-system)
+ (%current-system))))))
(match linux-arch
("i386" "x86")
("x86_64" "x86")
@@ -213,7 +213,7 @@ (define-public (linux-srcarch)
(define-public (system->defconfig system)
"Some systems (notably powerpc-linux) require a special target for kernel
-defconfig. Return the appropriate make target if applicable, otherwise return
+defconfig. Return the appropriate Make target if applicable, otherwise return
\"defconfig\"."
(cond ((string-prefix? "powerpc-" system) "pmac32_defconfig")
((string-prefix? "powerpc64-" system) "ppc64_defconfig")
@@ -1271,19 +1271,19 @@ (define-public linux-libre-with-bpf
;;; Linux kernel customization functions.
;;;
-(define*-public (modify-linux #:key name
- (linux linux-libre)
- source
- defconfig
- (configs "")
- extra-version)
- "Make a Linux package NAME as a modification of another LINUX package.
+(define* (customize-linux #:key name
+ (linux linux-libre)
+ source
+ defconfig
+ (configs "")
+ extra-version)
+ "Make a customized Linux package NAME derived from the LINUX package.
If NAME is not given, then it defaults to the same name as the LINUX package.
Unless SOURCE is given the source of LINUX is used.
-A DEFCONFIG file to be used can be given as an origin, as a file like object
+A DEFCONFIG file to be used can be given as an origin, as a file-like object
(file-append, local-file etc.), or as a string with the name of a defconfig file
available in the Linux sources. If DEFCONFIG is not given, then a defconfig
file will be saved from the LINUX package configuration.
@@ -1295,11 +1295,11 @@ (define*-public (modify-linux #:key name
defconfig syntax has to be used, but there is a special extension to ease the
removal of configurations. Comment lines are supported as well.
-Here is an explaining usage example:
+Here is an example:
'(;; This string defines the version tail in 'uname -r'.
\"CONFIG_LOCALVERSION=\\\"-handcrafted\\\"
- ;; This '# CONFIG_… is not set' syntax has to match exactly!
+ ;; This '# CONFIG_... is not set' syntax has to match exactly!
\"# CONFIG_BOOT_CONFIG is not set\"
\"CONFIG_NFS_SWAP=y\"
;; This is a multiline configuration:
@@ -1339,13 +1339,13 @@ (define*-public (modify-linux #:key name
#$(cond
((not defconfig)
#~(begin
- ;; Call the original 'configure phase.
- (apply (assoc-ref #$phases 'configure) arguments)
- ;; Save a defconfig file.
- (invoke "make" "savedefconfig")
- ;; Move the saved defconfig to the proper location.
- (rename-file "defconfig"
- guix_defconfig)))
+ ;; Call the original 'configure phase.
+ (apply (assoc-ref #$phases 'configure) arguments)
+ ;; Save a defconfig file.
+ (invoke "make" "savedefconfig")
+ ;; Move the saved defconfig to the proper location.
+ (rename-file "defconfig"
+ guix_defconfig)))
((string? defconfig)
;; Use another existing defconfig from the Linux sources.
#~(rename-file (string-append configs #$defconfig)
--8<---------------cut here---------------end--------------->8---
I'll push it shortly.
--
Thanks,
Maxim
Reply sent
to Maxim Cournoyer <maxim.cournoyer@gmail.com>:
You have taken responsibility.
(Thu, 01 Dec 2022 19:34:02 GMT) (full text, mbox, link).
Notification sent
to Stefan <stefan-guix@vodafonemail.de>:
bug acknowledged by developer.
(Thu, 01 Dec 2022 19:34:02 GMT) (full text, mbox, link).
Subject: Re: bug#48314: [PATCH] Install guix system on Raspberry Pi
Date: Thu, 01 Dec 2022 14:33:24 -0500
Hi,
Stefan <stefan-guix@vodafonemail.de> writes:
> gnu: raspberry-pi: Add a bootloader-chain for the Raspberry Pi and os examples.
>
> From: Stefan <stefan-guix@vodafonemail.de>
>
> * gnu/packages/raspberry-pi.scm (grub-efi-bootloader-chain-raspi-64): New
> bootloader variable, capable to boot a Raspberry Pi over network or from a
> local storage.
> * gnu/system/examples/raspberry-pi-64.tmpl: New operating-system example.
> * gnu/system/examples/raspberry-pi-64-nfs-root.tmpl: New operating-system
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
Information forwarded
to guix-patches@gnu.org: bug#48314; Package guix-patches.
(Sat, 03 Dec 2022 05:54:02 GMT) (full text, mbox, link).
On 2022-12-01, Maxim Cournoyer wrote:
> Stefan <stefan-guix@vodafonemail.de> writes:
>
>> gnu: raspberry-pi: Add a bootloader-chain for the Raspberry Pi and os examples.
>>
>> From: Stefan <stefan-guix@vodafonemail.de>
>>
>> * gnu/packages/raspberry-pi.scm (grub-efi-bootloader-chain-raspi-64): New
>> bootloader variable, capable to boot a Raspberry Pi over network or from a
>> local storage.
>> * gnu/system/examples/raspberry-pi-64.tmpl: New operating-system example.
>> * gnu/system/examples/raspberry-pi-64-nfs-root.tmpl: New operating-system
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
Cc: Stefan <stefan-guix@vodafonemail.de>,
Danny Milosavljevic <dannym@scratchpost.org>,
Ludovic Courtès <ludo@gnu.org>,
phodina <phodina@protonmail.com>, 48314@debbugs.gnu.org
Subject: Re: bug#48314: [PATCH] Install guix system on Raspberry Pi
Date: Sun, 04 Dec 2022 01:28:03 -0500
Hello,
Vagrant Cascadian <vagrant@debian.org> writes:
> On 2022-12-01, Maxim Cournoyer wrote:
>> Stefan <stefan-guix@vodafonemail.de> writes:
>>
>>> gnu: raspberry-pi: Add a bootloader-chain for the Raspberry Pi and os examples.
>>>
>>> From: Stefan <stefan-guix@vodafonemail.de>
>>>
>>> * gnu/packages/raspberry-pi.scm (grub-efi-bootloader-chain-raspi-64): New
>>> bootloader variable, capable to boot a Raspberry Pi over network or from a
>>> local storage.
>>> * gnu/system/examples/raspberry-pi-64.tmpl: New operating-system example.
>>> * gnu/system/examples/raspberry-pi-64-nfs-root.tmpl: New operating-system
>
> 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")))
>
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
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Sun, 01 Jan 2023 12:24:04 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.