[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#55231] [PATCH v3 2/2] doc: ‘initrd-modules’ will search ‘kernel-loa
From: |
Maxime Devos |
Subject: |
[bug#55231] [PATCH v3 2/2] doc: ‘initrd-modules’ will search ‘kernel-loadable-modules’. |
Date: |
Sat, 18 Jun 2022 22:34:53 +0200 |
User-agent: |
Evolution 3.38.3-1 |
Brian Cully via Guix-patches via schreef op za 18-06-2022 om 15:11 [-
0400]:
> +If a module listed in @code{initrd-modules} is not included in the
> +Linux-libre kernel, then the location to it must be added to the
> +@code{kernel-loadable-modules} list. For example, if your root file
> +system exists on a ZFS pool, then your configuration might look like the
> +following:
> +
> +@lisp
> +(operating-system
> + ;; @dots{}
> + (initrd-modules (cons "zfs" %base-initrd-modules))
> + (kernel-loadable-modules (list (list zfs "module"))))
> +@end lisp
As written previously, this is not a good example, because:
> As-is, I don't think this is a good example, because
> 'expression->initrd' does not set #:substitutable? #false,
> the 'zfs' package has the comment (*)
>
> `(;; The ZFS kernel module should not be downloaded since the
> license
> ;; terms don't allow for distributing it, only building it
> locally.
> #:substitutable? #f [...])
>
> and IIUC, the code inside expression->initrd copies the kernel module
> into the new store item, so it looks like this accidentally suggest
> people to commit copyvios, and copyvios are currently against the
> law.
and because the defense for not considering the ZFS license to be a
problem consists of the ZFS module not being distributed in binary
form, whereas this suggestion would in some situations cause it to be
distributed in binary form.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part