Hi Denis, Denis 'GNUtoo' Carikli <[email protected]> writes:
> The problem is that adding many images don't scale. I thought that > this was a problem that would show up later once Guix system really > become usable on ARM What's missing in your opinion? 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). > but the reality is that the problem is already > there. According to vagrantc on Codeberg[1]: > >> I am somewhat reluctant to keep building images that are all in the >> GB scale, that share 99% with the other images built for the same >> architecture. That seems pretty rough on CI. Agreeing with you and Vagrant here, albeit providing a ton of images is what other projects in those realms seem to be doing, see: 1. postmarketOS https://images.postmarketos.org/bpo/v25.12/ 2. armbian https://www.armbian.com/download/ all of those offer device-specific images. There's no automatism in that, that guix should do so as well, and not disproportionally allocating CI ressources to build images could probably a better decission being mindful about our resources. Right now to get a board-specific image one would have to: guix system image --image-type=$board-raw board.scm and either come up with a custom operating-system declaration in board.scm or inherit one from (gnu system images ...) to get started. I think collecting as many barebones configuration covering hardware quirks of SBCs in (gnu system images) as possible without building them could work out 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? > 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? > - On 64bit ARM, '(kernel linux-libre-arm64-generic)' results in a > computer that boots but the computer is not usable in many > cases. > > For instance linux-libre-arm64-generic doesn't have WireGuard, and > it probably lack other configuration required by distributions. 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? > Finally we would need a place to list the names of the computers that > are supposed to work (for instance for a given image), and the manual > looks a good place for that. We might also want to list what works > (specific image, installer, etc). Yes, this kind of information should definitely be part of either the manual or the cookbook. Alongside with adding boards to (gnu system images) this could also be a good enough starting point. > And I'm also pretty new to scheme/guile, so I might need help to > properly implement services to make images more generic. Feel free to reach out if there's something you want someone to look at or discuss ideas in that direction as I'm interested in improving the situation as well! -- Kind regards, Wilko Meyer
