Hi Denis,
On Mon Jan 19, 2026 at 10:31 PM CET, Denis 'GNUtoo' Carikli wrote: > On Sat, 17 Jan 2026 09:45:48 +0100 > "Tanguy Le Carrour" <[email protected]> wrote: > >> I would be more than happy to hear how any one else is working with >> their SBC and what advice they would give me not to lose my time and >> my sanity! 🤪 > > I've already asked questions like the ones you ask in this mailing list > several times, tried to ask in person at the FOSDEM, at Guix events in > Paris, etc, and I didn't have proper answers for years. Chances are not many people do Guix on ARM! 😞 I was lucky to find you! 😉🍀 > And if you're unsure how to do something and that nobody else has an > answer, and that the manual isn't clear, then I think that the only way > is also to send patches to fix the manual, and deduce the Guix way of > doing things through the interaction during the review of the patches. Sounds like a good idea. >> (*) I write cross-compile, but I actually tried both `--system` and >> `--target`. They both work on the newer computer, but only `--system` >> seems to work on the old one, but ends up failing with a weird error >> on dangling link: >> <https://lists.gnu.org/archive/html/help-guix/2026-01/msg00006.html> > > As I understand, when the target CPU is incompatible with the builder > CPU, --target= does cross compile and --system uses QEMU (when it is > properly configured) to build natively. > > I've no idea which one is best, that tends to depend a lot on the > situation. > […] > If it does you will have some packages that don't build. For instance > at the time python programs couldn't work because the python build > system of the time didn't support cross compilation. And it would also > output the proper error messages. > > Here's an example: >> $ guix build --target=aarch64-linux-gnu pelican >> guix build: error: gnu/packages/python-xyz.scm:10513:2: >> [email protected]: >> build system `pyproject' does not support cross builds > > When building without substitutes --target= is faster. However --system > probably uses the exact same substitutes on the builder and the target. > Though this needs to be tested in practice to be sure of that. Yep. Got the same problem. The `--system` flagged fixed it, thanks to QEMU. So I’ll keep on using this one. >> I’m pretty much used to the process now and buying an USB-serial cable >> made working with the board even easier, but I feel like it’s not the >> proper way to move forward. > > This depends a lot on the (ARM) computer. Some don't have displays at > all. On some the display don't work in u-boot. It's also very handy to > get boot logs. On the Lime2, I can do either serial or screen/keyboard. I would say that serial is more convenient. > Through once networking works, I do prefer SSH or a display+keyboard as > I never managed to configure the serial ports console (export > TERM=xterm) well enough to make all text editors / ncurses program work > fine in them. As soon as I have Guix System up and running on the board, I connect using SSH. >> - install from a USB stick… FAILED > What does FAILED means here? What command did you try? >> - cross-install from a running ARMbian… FAILED Can remember the exact messages. It’s been discussed in several places. - https://lists.gnu.org/archive/html/help-guix/2024-11/msg00142.html - https://lists.gnu.org/archive/html/help-guix/2024-12/msg00021.html >> - cross-compile* from my old D8… SLOW… FAILED > Does the build fails? - https://lists.gnu.org/archive/html/help-guix/2026-01/msg00006.html … but I’m not sure fixing the installer or the cross-install from a foreign disto really make sense, for… > Personally the way I do installation so far (on 64bit ARM, I didn't > deploy production 32bit ARM with Guix yet) is to build an image, like > the one you have added in Guix, and once booted to somehow reconfigure > the target. Though I didn't try that on armv7 yet. +1 I also found it more logical –now that I’ve went through the pain of trying the above approaches!– to 1) build or download the base image and 2) reconfigure it locally or, even better, remotely using `guix deploy`. > And ideally I want everything to work to have more options and be able > to advise to get specific SBCs because they just work. Amen! 😉 > So making 3 image for these 3 boards is probably not ideal. There might > be a way to somehow share almost everything but the machine name and > the bootloader package by using a function and/or inheriting from > another image. It would make sense to me to have 1 small image per board. You download the one you need and **BOOM** you’re good to go. -- Tanguy
