Re: Kernel modules in initrd

[Mark H Weaver <mhw@netris.org>]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> recently I had an unpleasant experience in installing GuixSD: After booting
> with the USB key and following the installation instructions, then rebooting
> into the installed system, the "/" file system was not found: neither using
> file system labels, nor device nodes.
>
> The problem turned out to be that the disk of the machine needed special
> kernel modules, and adding
>   (initrd (lambda (file-systems . rest)
>             (apply base-initrd file-systems
>                    #:extra-modules '("mptbase" "mptsas" "mptscsih")
>                                    rest)))
> to the operating-system declaration solved the problem.
> However, it took us quite some time and several trials to diagnose the
> problem in the first place.
>
> So I wonder:
> 1) Could we add more kernel modules to the base-initrd, whenever people
>    report that new ones are needed? For instance, the berlin server has
>    modules (list "megaraid_sas" "libsas" "scsi_transport_sas").

We need a better system for dealing with this.

I don't think that loading every kernel module that any GuixSD user ever
needed during the early boot process is a good approach.  To make
matters worse, it's easy for a user to add modules to their initrd, but
there's no easy way to remove modules from the default set.

I don't want *every* GuixSD user to unconditionally load, into their
kernels during early boot, code to support LSI MegaRAID SAS cards, just
because there exists one GuixSD user out there who needs it.

Every extra loaded kernel module means more RAM usage in the kernel, a
larger initrd image that must be loaded by possibly slow bootloaders,
and code complexity in the running kernel, leading to a greater attack
surface for possible security exploits.  For example, last year some
memory corruption bugs were found in the LSI MegaRAID SAS module.  See
<https://patchwork.kernel.org/patch/9585337/>.

To make this easier, I think the right approach is to include many
modules like these to our installation image initrd, and then to
automatically detect which modules are needed for booting.  A future
easy installer could automatically add those modules to the OS config,
but in the meantime we could simply print a message recommending that
the user should add the needed modules to their initrd config.

What do you think?

      Mark