| Message ID | 65cf1060a7ce60b1b91a25f809af6264abdcfa59.1655579477.git.bjc@spork.org |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#55231,v3,1/2] Allows copying of out-of-tree modules to the Linux initrd. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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.
> 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. If you have another example, I'll put it in instead. I used this one, because I know this one works, and that's all. That said, I'm not sure how this would cause the module to be distributed as a binary. In order for it to be added to the initrd, it will still need to built using the DKMS mechanism, and thus compiled on (or at least for) the target Guix installation. If the complaint is that one could generate a USB stick, or some such, with ZFS in the initrd, then yes, that's possible. But that's also possible by using the existing ‘kernel-loadable-modules’ mechanism to generate an image with ‘guix system image’ and distributing that. I don't think it's our job to try and prevent such things, since, even if desirable, it's not really feasible. If the complaint is merely that it's in the documentation, then ok, I'll change it to whatever module you want. -bjc
Brian Cully schreef op za 18-06-2022 om 16:43 [-0400]: > That said, I'm not sure how this would cause the module to be > distributed as a binary. [...] Because #:substitutable? isn't set appropriately in dependents, substitute servers exist, ZFS can be used on substitute servers and someone using the substitute server might have a sufficiently similar system configuration to do substitution of a store item containing a copy of the ZFS binary. Greetings, Maxime.
Maxime Devos <maximedevos@telenet.be> writes: > Because #:substitutable? isn't set appropriately in dependents, > substitute servers exist, ZFS can be used on substitute servers > and > someone using the substitute server might have a sufficiently > similar > system configuration to do substitution of a store item > containing a > copy of the ZFS binary. So, simply using ZFS in ‘kernel-loadable-modules’ would be enough to trigger this misbehavior? That sounds like a pretty serious issue. Would it be possible to have the substitute servers filter on the #:substitutable flag? This is getting out of scope, though. I don't really want this patch to go in without /some/ documentation regarding how modules get looked up, so if anyone has an alternate module and use-case, I'll just swap it in for the ZFS one. -bjc
Brian Cully schreef op za 18-06-2022 om 19:11 [-0400]: > So, simply using ZFS in ‘kernel-loadable-modules’ would be enough > to trigger this misbehavior? That sounds like a pretty serious > issue. Would it be possible to have the substitute servers filter > on the #:substitutable flag? That's exactly what the #:substitutable flag is for (IIUC)! However, the problem is that currently, that flag isn't set for derivations that make a copy of the ZFS module. As I wrote previously: > > and IIUC, the code inside expression->initrd copies the kernel > > module into the new store item, > This is getting out of scope, though. I don't really want this > patch to go in without /some/ documentation regarding how modules > get looked up, so if anyone has an alternate module and use-case, > I'll just swap it in for the ZFS one. I don't have any. Greetings, Maxime.
diff --git a/doc/guix.texi b/doc/guix.texi index eda0956260..d97909695f 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -36461,6 +36461,19 @@ Initial RAM Disk (initrd-modules (cons "megaraid_sas" %base-initrd-modules))) @end lisp +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 + @defvr {Scheme Variable} %base-initrd-modules This is the list of kernel modules included in the initrd by default. @end defvr