Hi Ludo,

>   1. ‘device-module-aliases’ returns the empty list for /dev/dm-0, which
>      is a LUKS device on my laptop.  I’m not sure what it would take to
>      have it return “dm-crypt”, etc.  Same for RAID devices.

Hmm...  I don't know either.

(same happens on my machine)

>   2. Let’s assume you have: (initrd-modules '("a")).  ‘guix system’
>      could report that module “b” is missing, even if “b” is actually a
>      dependency of “a” and will therefore be automatically included in
>      the initrd.  I think that’s an acceptable limitation (fixing it is
>      non-trivial since we’d ideally need to build the target kernel so
>      we can inspect its modules and determine their closure.)

I think that's okay.

> You’re welcome to give it a try.  In particular it’d be great if you
> could check that ‘device-module-aliases’ returns the right thing on your
> machine, as I shown in the example above.

scheme@(guile-user)> (device-module-aliases "/dev/sda5")
$1 = ("scsi:t-0x00" "pci:v00008086d00009C03sv000017AAsd00002214bc01sc06i01")
scheme@(guile-user)> (device-module-aliases "/dev/sda1")
$2 = ("scsi:t-0x00" "pci:v00008086d00009C03sv000017AAsd00002214bc01sc06i01")

> Note that, in addition to that, we could also have a tool to generate a
> template ‘operating-system’ declaration.  Let’s say:
> 
>   guix system template desktop encrypted-root
> 
> would generate a config based on the desktop config but with the right
> ‘initrd-modules’.

Sounds like a good idea!

P.S. I just integrated my patchset (v5) and your patchset and have a working system
with pure guile initrd (modprobe is in guile, too).  I ran basic system tests and
also rebooted my machine with it :)

Attached is the integration patch, so let's just review the patchsets
as normal and then push both and then push the integration patch.

I'm not sure about the module resolution order, first use the aliases or first
use the real module files?

The Linux modules should be much more under control then...

(zip file attached for convenience, but please ignore duplicates - it contains the same
patches as in the other E-Mails already - except for patch context)