On Thu, 25 Sep 2025 17:27:33 -0700
Daniel Lakeland <[email protected]> wrote:
> and then drops into the guile REPL.
In the repl, there is a limited version of 'cat'.

To use it you need to type ',bournish' first, and then if I recall well
'cat /proc/partitions' should work.

If /dev/mmcblk0 is missing from /proc/partitions, you then need to find
the modules to add. If not you have another issue that is unrelated to
missing modules. Sometimes you also need to wait a bit for the right
device to appear and that can be fixed with kernel arguments like
rootwait or rootdelay (both being different).

On ARM I have to add missing modules for each computer I want to run
Guix on as linux-libre-aarch64-generic misses important
modules (they are not even compiled) for things like Wireguard. So I use
linux-libre instead, but that doesn't have many things builtin so I've
to find the list of modules required to make the computer boot.

To do that I try to boot on something that works (like another
distribution or Guix on another media like an SSD, an USB key, etc),
and then I list all the modules, and just add them to the
initrd-modules list. With that I've something that boots.

I then setup the new system to easily be reconfigured with ssh and I
try to remove unnecessary modules until it doesn't boot anymore and
mark the modules that broke boot as essential and keep them. I use a
previous generation to boot the machine when the reconfiguration broke
the boot, and I basically repeat the process until I have all the
modules for all the boot medias. 

I'm currently doing that for the rock-4c-plus and I'll send patches
to add these in gnu/system/images/rock-4c-plus.scm as soon as I've all
the ways to boot covered (so far I only have the list of modules for
the microSD).

In your case if the machine you have do require modules to boot, it may
also be an option to try to upstream a machine definition to make sure
people can make images for your machine or similar machines (like
intel-<some-cpu-family>-mmc).

Though also note that I'm also learning what is the way to do things
in Guix by sending patches and seeing the commiters reactions, with
things like adding ARM computers support, so I'll only know if my
approach was right when the patches will land in Guix. Since I want
my machines to be supported upstream, there is 0 overhead, which is
good (because I do care about the committers and the health of Guix as
well).

Basically there is more than one way to do it (the kernel could also be
modified and so on) and even very basic goals can differ depending on
the distributions (like support fewer machines for a long time or
support as many machines as possible without caring about long term
support) and so far the only way for me to find things out is to send
patches (I tried asking first, but I never got replies, and my goal
was ultimately to upstream support for computers anyway).

Denis.

Attachment: pgpi2sGksqQxo.pgp
Description: OpenPGP digital signature

Reply via email to