Cannot use modules with an inferior kernel.

  • Open
  • quality assurance status badge
Details
3 participants
  • Robby Zambito
  • Jelle Licht
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Robby Zambito
Severity
normal
R
R
Robby Zambito wrote on 14 Mar 2023 04:27
(name . Guix Bugs)(address . bug-guix@gnu.org)
87mt4gass9.fsf@robbyzambito.me
Hi,

I use an inferior to pin my kernel version, but it seems like I cannot
use modules with it. The following works fine:

```
(use-package-modules linux)
(operating-system
...
(kernel linux-libre)
(kernel-loadable-modules (list v4l2loopback-linux-module))
...)
```

As does the following:

```
(define rz/linux
(let* ((channels
(list (channel
(name 'guix)
(commit "c81d2d448cbd051800867fe3f4b82ef3f4380ebf"))))
(inferior (inferior-for-channels channels))
(kernel-version "6.1.15"))
(first (lookup-inferior-packages inferior "linux-libre" kernel-version))))

(operating-system
...
(kernel rz/linux)
...)
```

However when I combine the two (using the inferior for the kernel +
specify modules)...

```
(operating-system
...
(kernel rz/linux)
(kernel-loadable-modules (list v4l2loopback-linux-module))
...)
```

I get the following error:

```
Backtrace:
In guix/store.scm:
659:37 19 (thunk)
1298:8 18 (call-with-build-handler #<procedure 7ff5305d4cc0 at g…> …)
2168:25 17 (run-with-store #<store-connection 256.99 7ff526131b90> …)
In guix/scripts/system.scm:
843:2 16 (_ _)
717:8 15 (_ #<store-connection 256.99 7ff526131b90>)
In gnu/system.scm:
1307:19 14 (operating-system-derivation _)
In gnu/services.scm:
1140:36 13 (_ _)
In srfi/srfi-1.scm:
586:29 12 (map1 (#<<service> type: #<service-type profile 7ff5…> …))
586:29 11 (map1 (#<<service> type: #<service-type etc 7ff52978…> …))
586:29 10 (map1 (#<<service> type: #<service-type activate 7ff…> …))
586:29 9 (map1 (#<<service> type: #<service-type boot 7ff5297…> …))
586:17 8 (map1 (#<<service> type: #<service-type linux-builder …>))
In gnu/services.scm:
951:29 7 (linux-builder-configuration->system-entry _)
In guix/profiles.scm:
438:4 6 (packages->manifest _)
In srfi/srfi-1.scm:
586:17 5 (map1 ((#<inferior-package linux-libre@6.1.15 7ff52…>) …))
In guix/inferior.scm:
549:2 4 (loop (#<inferior-package linux-libre@6.1.15 7ff52610…>) …)
529:4 3 (inferior-package-input-field (#<inferior-package lin…>) …)
473:18 2 (inferior-package-field (#<inferior-package linux-lib…>) …)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): (#<inferior-package linux-libre@6.1.15 7ff5261088a0>)
```

It seems to me like this is a bug. If I am mistaken, some guidance would
be appreciated.

Thanks,
Robby
L
L
Liliana Marie Prikler wrote on 14 Mar 2023 20:53
ef393f71882d0a52e4a58a6ef8e48c534afbea1d.camel@gmail.com
Am Montag, dem 13.03.2023 um 23:27 -0400 schrieb Robby Zambito:
Toggle quote (101 lines)
> Hi,
>
> I use an inferior to pin my kernel version, but it seems like I
> cannot
> use modules with it. The following works fine:
>
> ```
> (use-package-modules linux)
> (operating-system
>   ...
>   (kernel linux-libre)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
>
> As does the following:
>
> ```
> (define rz/linux
>   (let* ((channels
>           (list (channel
>                  (name 'guix)
>                  (url "https://git.savannah.gnu.org/git/guix.git")
>                  (commit
> "c81d2d448cbd051800867fe3f4b82ef3f4380ebf"))))
>          (inferior (inferior-for-channels channels))
>          (kernel-version "6.1.15"))
>     (first (lookup-inferior-packages inferior "linux-libre" kernel-
> version))))
>
> (operating-system
>   ...
>   (kernel rz/linux)
>   ...)
> ```
>
> However when I combine the two (using the inferior for the kernel +
> specify modules)...
>
> ```
> (operating-system
>   ...
>   (kernel rz/linux)
>   (kernel-loadable-modules (list v4l2loopback-linux-module))
>   ...)
> ```
>
> I get the following error:
>
> ```
> Backtrace:
> In guix/store.scm:
>    659:37 19 (thunk)
>    1298:8 18 (call-with-build-handler #<procedure 7ff5305d4cc0 at g…>
> …)
>   2168:25 17 (run-with-store #<store-connection 256.99 7ff526131b90>
> …)
> In guix/scripts/system.scm:
>     843:2 16 (_ _)
>     717:8 15 (_ #<store-connection 256.99 7ff526131b90>)
> In gnu/system.scm:
>   1307:19 14 (operating-system-derivation _)
> In gnu/services.scm:
>   1140:36 13 (_ _)
> In srfi/srfi-1.scm:
>    586:29 12 (map1 (#<<service> type: #<service-type profile 7ff5…>
> …))
>    586:29 11 (map1 (#<<service> type: #<service-type etc 7ff52978…>
> …))
>    586:29 10 (map1 (#<<service> type: #<service-type activate 7ff…>
> …))
>    586:29  9 (map1 (#<<service> type: #<service-type boot 7ff5297…>
> …))
>    586:17  8 (map1 (#<<service> type: #<service-type linux-builder
> …>))
> In gnu/services.scm:
>    951:29  7 (linux-builder-configuration->system-entry _)
> In guix/profiles.scm:
>     438:4  6 (packages->manifest _)
> In srfi/srfi-1.scm:
>    586:17  5 (map1 ((#<inferior-package linux-libre@6.1.15 7ff52…>)
> …))
> In guix/inferior.scm:
>     549:2  4 (loop (#<inferior-package linux-libre@6.1.15 7ff52610…>)
> …)
>     529:4  3 (inferior-package-input-field (#<inferior-package lin…>)
> …)
>    473:18  2 (inferior-package-field (#<inferior-package linux-lib…>)
> …)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): (#<inferior-package
> linux-libre@6.1.15 7ff5261088a0>)
> ```
>
> It seems to me like this is a bug. If I am mistaken, some guidance
> would be appreciated.
I think you should try to pin the kernel modules as well. If that
still doesn't work as intended (it very well might), we have a proper
case of something that should work but doesn't.

Cheers
R
R
Robby Zambito wrote on 14 Mar 2023 22:48
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 62174@debbugs.gnu.org)
87sfe73pyq.fsf@robbyzambito.me
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
Toggle quote (6 lines)
> I think you should try to pin the kernel modules as well. If that
> still doesn't work as intended (it very well might), we have a proper
> case of something that should work but doesn't.
>
> Cheers

Thanks for the suggestion. I tested with the following:

```
(define-values (rz/linux rz/linux-kernel-modules)
(let* ((channels
(list (channel
(name 'guix)
(commit "d37b467631d5b0e965ea933b8bda8448993580e9"))))
(inferior (inferior-for-channels channels))
(kernel-version "6.1.15"))
(values (first (lookup-inferior-packages inferior "linux-libre" kernel-version))
(list (first (lookup-inferior-packages inferior "v4l2loopback-linux-module"))))))

(operating-system
...
(kernel rz/linux)
(kernel-loadable-modules rz/linux-kernel-modules)
...)
```

But I receive a different error now:

```
running profile hook of type 'linux-module-database'...
Backtrace:
1 (primitive-load "/gnu/store/7ha0kn8fz8yfi26m3m8997wlc8m?")
In ice-9/boot-9.scm:
2007:7 0 (error _ . _)

ice-9/boot-9.scm:2007:7: In procedure error:
Specified Linux kernel and Linux kernel modules are not all of the same version
```

However, if I use the most recent kernel version available in the
inferior...

```
(define-values (rz/linux rz/linux-kernel-modules)
(let* ((channels
(list (channel
(name 'guix)
(commit "d37b467631d5b0e965ea933b8bda8448993580e9"))))
(inferior (inferior-for-channels channels))
(kernel-version "6.2.2"))
(values (first (lookup-inferior-packages inferior "linux-libre"))
(list (first (lookup-inferior-packages inferior "v4l2loopback-linux-module"))))))
```

It actually works! So it seems that the problem is specifically with
using kernel modules with a kernel version other than the latest
linux-libre kernel from an inferior. I also tried using a specific
kernel version without an inferior like so:

```
(operating-system
...
(kernel (specification->package "linux-libre@6.1.15"))
(kernel-loadable-modules (list (specification->package"v4l2loopback-linux-module")))
...)
```

And that works as well.

TL;DR: The issue has been narrowed down to using kernel modules with a
kernel from an inferior besides the latest kernel from that inferior.
J
J
Jelle Licht wrote on 15 Mar 2023 12:35
Re: bug#62174: Cannot use modules with an inferior kernel.
(name . Robby Zambito)(address . contact@robbyzambito.me)
87h6umtfgr.fsf@fsfe.org
Robby Zambito <contact@robbyzambito.me> writes:

Toggle quote (75 lines)
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> I think you should try to pin the kernel modules as well. If that
>> still doesn't work as intended (it very well might), we have a proper
>> case of something that should work but doesn't.
>>
>> Cheers
>
> Thanks for the suggestion. I tested with the following:
>
> ```
> (define-values (rz/linux rz/linux-kernel-modules)
> (let* ((channels
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git")
> (commit "d37b467631d5b0e965ea933b8bda8448993580e9"))))
> (inferior (inferior-for-channels channels))
> (kernel-version "6.1.15"))
> (values (first (lookup-inferior-packages inferior "linux-libre" kernel-version))
> (list (first (lookup-inferior-packages inferior "v4l2loopback-linux-module"))))))
>
> (operating-system
> ...
> (kernel rz/linux)
> (kernel-loadable-modules rz/linux-kernel-modules)
> ...)
> ```
>
> But I receive a different error now:
>
> ```
> running profile hook of type 'linux-module-database'...
> Backtrace:
> 1 (primitive-load "/gnu/store/7ha0kn8fz8yfi26m3m8997wlc8m?")
> In ice-9/boot-9.scm:
> 2007:7 0 (error _ . _)
>
> ice-9/boot-9.scm:2007:7: In procedure error:
> Specified Linux kernel and Linux kernel modules are not all of the same version
> ```
>
> However, if I use the most recent kernel version available in the
> inferior...
>
> ```
> (define-values (rz/linux rz/linux-kernel-modules)
> (let* ((channels
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git")
> (commit "d37b467631d5b0e965ea933b8bda8448993580e9"))))
> (inferior (inferior-for-channels channels))
> (kernel-version "6.2.2"))
> (values (first (lookup-inferior-packages inferior "linux-libre"))
> (list (first (lookup-inferior-packages inferior "v4l2loopback-linux-module"))))))
> ```
>
> It actually works! So it seems that the problem is specifically with
> using kernel modules with a kernel version other than the latest
> linux-libre kernel from an inferior. I also tried using a specific
> kernel version without an inferior like so:
>
> ```
> (operating-system
> ...
> (kernel (specification->package "linux-libre@6.1.15"))
> (kernel-loadable-modules (list (specification->package"v4l2loopback-linux-module")))
> ...)
> ```
>
> And that works as well.
>
> TL;DR: The issue has been narrowed down to using kernel modules with a
> kernel from an inferior besides the latest kernel from that inferior.

I believe our kernel-loadable-modules is backed by a service with type
linux-builder-service-type. It seems that the
linux-builder-configuration->system-entry only deals gracefully with
modules that are filtered by "(package? mod)" in order to rewrite the
package with "package-for-kernel".

So there are some things we'd need to do to ensure your use case works:
- Get linux-builder-configuration->system-entry to support packages from
an inferior.

Can you try to wrap your kernel module package like such [untested],
with rz/linux being the kernel inferior package you actually want:

Toggle snippet (7 lines)
(kernel rz/linux)
(kernel-loadable-modules
(map
(lambda (mod) (package-for-kernel lz/linux mod))
rz/linux-kernel-modules))

If this doesn't work, we also need to make package-for-kernel support
packages from an inferior for both the kernel and module argument, or
create an alternative implementation that deals
`linux-builder-configuration->system-entry' can dispatch to for this
specific case.

Good luck!
- Jelle
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 62174@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62174
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch