Hi, On Wed, 18 Feb 2026 10:30:56 +0100 Wilko Meyer <[email protected]> wrote:
> The arm64-generic kernel is quite minimal at the moment and not as
> generic (as in available modules) as the x86_64 counterpart is. I
> don't know how feasible a enable-everything-by-default approach is
> for SBC kernels, I'd rather would go a defaults (as in kernel config
> defaults) + stuff people actually use kind of route, take in new
> modules by PR, and keep things minimal otherwise?
I sent a PR after this mail for switching the rock-4c-plus to
linux-libre by adding all the modules required for booting.
And I was told that I should instead add modules to linux-libre and
linux-libre-arm64-generic, so I guess we're good here and don't need to
discuss the kernel situation further.
I now just need to do it and this should scale way better than having
to list individual modules for each computer.
> I've been daily-driving Guix System on ARM64 for more than a month
> now and everything I expect to work works and is already there except
> for two things, FDE (unencrypted /boot would work though) and Haskell
> support (the git-annex and pandoc guix packages are x86_64 only).
FDE can probably work if you use u-boot-> GRUB (UEFI) -> LUKS1 encrypted
rootfs and probably switch to LUKS2 when we have GRUB 2.14.
On some computers (maybe all?), U-boot can boot UEFI images, so this is
probably the easiest way to get GRUB on ARM64.
And GRUB can open LUKS1 disks, but I've not tried that with the GRUB
provided by Guix (I use the one provided by GNU Boot instead), but I
guess that since it works on x86_64 it should work on ARM 64bit as well.
> That would allow people to come up with bootable images themselves
> and would only require guix to be installed on the host computer to
> build those. WDYT?
This is exactly what I want. I just want to make sure it works in all
cases and have that this really works documented somewhere (like in the
manual).
> What's missing in your opinion?
Probably some clear information on how to add complete support for a
given ARM computer.
To me this complete support would consist in:
- A way to get basic system images that can easily installed and that
can boot and be reconfigured later on (a guix command documented
inthe manual is fine).
- A way to get installer images that boots (a guix command documented
in the manual is fine).
- A way to get a list of the computers that we can get basic images
for, and also a list of computers that the installer works on (guix
command are also fine).
- Statement(s) in the manual that tells what is supposed to work and/or
where you are on your own. For instance:
- As a user, do I need to take care about reserving space for the
bootloader in the partition scheme, or will Guix bail out and tell
me that this can't work? If it works we probably don't need
documentation, but does it work?
- What is the status of linux-libre vs linux-libre-arm64-generic,
until it gets fixed and/or a way to know if a board will work with
a given kernel. Generic statement in the manual like "we don't know
what boards work with linux-libre" and "linux-libre-arm64-generic
boots but might miss some modules" are fine.
To differentiate between temporary issues and longer term issues, we
could look if it worked before and the amount of work it requires to
fix (like does it require a rework/adjustments of the bootloader
system, or is a given computer temporarily broken).
Personally I can manage to properly install Guix by creating my own
system and image definitions on machines supported by a u-boot package
in Guix, but as I said in the first mail, but as I understand require
in-depth knowledge of ARM.
And this isn't theoretical: we got multiple mails of people having a
hard time installing Guix on ARM 64bit.
I could also be wrong here, maybe some of these issues have already
been fixed, because in my head I have the status of when I last checked
these things.
Ideally I would also love to put better documentation on how the SOCs
boot directly in Guix, to not have to retrieve it from
Datasheets/Technical reference manuals/etc but if we at least get
images that are known to work, having better documentation is less
needed.
In the long run maybe being able to somehow express constraints of the
boot in Guix would be great, where Guix would bail out if:
- You use GPT on computers where, with the current booting scheme
used by Guix, GPT doesn't work.
- You use GRUB with a filesystem unsupported by GRUB, or u-boot with a
filesystem unsupported by u-boot. Though that is less important as
this doesn't lead to data loss and so on.
This would automatically validate that what we have works, and works in
all cases.
And in the even longer run maybe being able to have more configuration
options for u-boot (like having it on a raw partition or in a fat
partition as supported by the SOC) would be great. This could allow
users to workaround some limitations of the boot. But forcing the users
to use MBR is 100% fine for now.
> Right now to get a board-specific image one would have to:
>
> guix system image --image-type=$board-raw board.scm
Here I assume that board.scm is a system definition.
I've tried on rock-4c-plus with this:
> (C) GPLv3+, 2026, GNUtoo
> (define-module (minimal-system)
> #:use-module (gnu)
> #:use-module (gnu bootloader u-boot))
>
> (define-public minimal-operating-system
> (operating-system
> (host-name "minimal")
> (bootloader (bootloader-configuration
> (bootloader u-boot-rock-4c-plus-rk3399-bootloader)
> (targets '("/dev/mmcblk0"))))
> (file-systems (append (list (file-system
> (device (file-system-label
> "Guix_image")) (mount-point "/")
> (type "ext4")))
> %base-file-systems))))
> minimal-operating-system
And before I assumed that this didn't really work, but this time it at
least boots up to that:
> bournish@(guile-user)> cat /proc/version
> Linux version 6.18.10-gnu (guix@guix) (aarch64-linux-gnu-gcc (GCC)
> 14.3.0, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC 1
Or maybe I had issues with another board.
If the bootloader always works here (don't overwrites the first
partition or be overwritten), then I'm good here as I just need to
go fix linux-libre to get this computer fully supported by Guix.
The M2 SSD doesn't work but that is a limitation of linux/u-boot not
Guix, and I should probably worry about these details later.
I'll try to do tests to see if image-type always boot to the initramfs.
For the installer images, the manual has that:
> guix system image --system=armhf-linux -e '((@ (gnu system install)
> os-with-u-boot) (@ (gnu system install) installation-os)
> "A20-OLinuXino-Lime2")'
When I sent patches for the rock-4c-plus, this was broken for some
reason (I had an error when running commands like the above).
I'll also try to do more tests on that.
> > The 4 ARM images could be:
> >
> > - Two with GRUB for ARM UEFI: one 32bit, one 64bit. This would
> > require u-boot to then load GRUB (this should already work on some
> > ARM computers).
> >
> > - Two without u-boot (32bit and 64bit) but with the
> > /boot/extlinux/extlinux.conf that is required by u-boot to boot.
>
> The latter would be a bring-your-own-bootloader kind of thing which is
> similiar to what I am using right now on my mnt pocket reform. I've
> never used UEFI on ARM so I can't say much about that, but in theory
> these four images should cover at least a set of devices that would
> otherwise have required their own image, right?
All the 4 are bring-your-own-bootloader. And they should work on
computers like the mnt pocket reform.
If images need to be built by bordeaux.guix.gnu.org and
berlin.guix.gnu.org we could have substitutes for these.
But here I'm assuming that not all ARM computers come with a builtin
bootloader, so all 4 images would come with enough space for adding a
bootloader. Users and/or guix could then just dd the bootloader in
the image somehow to produce something that boots on ARM computers that
don't have any bootloader builtin.
Though maybe what we have is already good enough: maybe we can already
have substitutes for each individual partitions, and so maybe the scheme
above isn't required.
This also depends on if the builders actually want to build images, but
I think it would be good to have even if the builders don't want to
build these as it would enable many people to be able to test the exact
same images regardless of the hardware they have.
Denis.
pgp299Plez3rK.pgp
Description: OpenPGP digital signature
