Bug 909722 – sys-kernel/genkernel looks for existence of obsolete moduledb file to trigger @module-rebuild (was: x11-drivers/nvidia-drivers since june 6th no automatic rebuild of nvidia driver)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Julien Delquié 2023-07-05 06:15:08 UTC]

I’m using genkernel to build my sys-kernel/gentoo-sources.
It also automatically rebuild x11-drivers/nvidia-drivers since it has always been in @module-rebuild set.

But since June 6th, I have seen a strange behavior.
After a kernel build with genkernel, there is no more automatic rebuild of x11-drivers/nvidia-drivers.
Also I do not see any nvidia reference in @module-rebuild set.
I have to not forget to rebuild manually x11-drivers/nvidia-drivers after kernel build, so to avoid a black screen on next reboot.
This is an issue.

As far as I can see in my genlop history :
- Everything was fine on May 31st (automatic rebuild of nvidia-drivers)
     Wed May 31 07:02:14 2023 >>> sys-kernel/gentoo-sources-6.3.5
       merge time: 54 seconds.

     Wed May 31 07:17:40 2023 >>> x11-drivers/nvidia-drivers-525.116.04
       merge time: 1 minute and 27 seconds.

- Everything went wrong on June 6th (manual rebuild of nvidia-drivers to fix my black screen, explaining the « huge » date/time difference between gentoo-sources and nvidia-drivers)
     Tue Jun  6 19:09:47 2023 >>> sys-kernel/gentoo-sources-6.3.6
       merge time: 51 seconds.

     Tue Jun  6 22:06:21 2023 >>> x11-drivers/nvidia-drivers-525.116.04-r2
       merge time: 1 minute and 21 seconds.

I checked today the history of x11-drivers/nvidia-drivers on git.
And I found this: x11-drivers/nvidia-drivers: migrate all remaining to linux-mod-r1
https://gitweb.gentoo.org/repo/gentoo.git/commit/x11-drivers/nvidia-drivers?id=8c062caccf596d19a3c886901865309f567cdab4

And I think my problem is linked to this.

If you need any other information, I will try to give them to you.

[Comment 1 Ionen Wolkens 2023-07-05 06:28:46 UTC]

Still seems normal on my end:

$ emerge -q @module-rebuild
[ebuild   R   ] games-util/xpadneo-9999  USE="dist-kernel strip -modules-sign" 
[ebuild   R   ] x11-drivers/nvidia-drivers-535.54.03  USE="X dist-kernel modules static-libs strip tools -kernel-open -modules-sign -persistenced -wayland" ABI_X86="32 (64)" 

To handle the @module-rebuild set, portage checks for packages that own files in /lib/modules[1] and does not care about the eclass or anything the ebuilds are doing. So it's not something linux-mod-r1 can have an impact on in theory.

Can check ownership with e.g. qfile
$ qfile -v /lib/modules/6.3.10/video/nvidia.ko 
x11-drivers/nvidia-drivers-535.54.03: /lib/modules/6.3.10/video/nvidia.ko

It's possible you installed drivers for a different kernel, then cleaned up *that one* and reverted to an older kernel. So none of the files are owned by portage anymore?

[1] https://gitweb.gentoo.org/proj/portage.git/tree/cnf/sets/portage.conf#n71

[Comment 2 Julien Delquié 2023-07-05 08:00:55 UTC]

Okay, it seems that this command is working:
emerge -q @module-rebuild
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) x11-drivers/nvidia-drivers-535.54.03::gentoo
[…]

So searching for module to rebuild is working.

Module exists:
$ ls -l /lib/modules/6.4.1-gentoo-r1-x86_64/video 
total 67296
-rw-r--r-- 1 root root   141008  5 juil. 07:43 nvidia-drm.ko
-rw-r--r-- 1 root root 63842592  5 juil. 07:43 nvidia.ko
-rw-r--r-- 1 root root  1656512  5 juil. 07:43 nvidia-modeset.ko
-rw-r--r-- 1 root root     6328  5 juil. 07:43 nvidia-peermem.ko
-rw-r--r-- 1 root root  3240608  5 juil. 07:43 nvidia-uvm.ko

Here is my current kernel:
$ uname -a
Linux pasokon.maison 6.4.1-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jul  2 07:04:02 CEST 2023 x86_64 Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz GenuineIntel GNU/Linux

Here is the result of this command:
$ qfile -v /lib/modules/6.4.1-gentoo-r1-x86_64/video/nvidia.ko 
x11-drivers/nvidia-drivers-535.54.03: /lib/modules/6.4.1-gentoo-r1-x86_64/video/nvidia.ko


So, maybe the issue is in Genkernel?
Note that in configuration I have MODULEREBUILD correctly set:
$ grep MODULEREBUILD= /etc/genkernel.conf
MODULEREBUILD="yes"

Seems really strange.

[Comment 3 Ionen Wolkens 2023-07-05 08:49:21 UTC]

fwiw this is the command that genkernel uses from a quick look:

DEFAULT_MODULEREBUILD_CMD="emerge --ignore-default-opts --buildpkg=n --usepkg=n --quiet-build=y @module-rebuild"

Which still works for me. Not that I use genkernel, so haven't tried with it.

Also, the command /is/ being run right? I wouldn't be surprised if there's some historical cruft that prevents it from being run. I'd be kind of surprised if portage is not getting it right, but genkernel not so much.

Looking at the scripts, genkernel should print a warning if it skipped it though.

[Comment 4 Ionen Wolkens 2023-07-05 08:53:42 UTC]

(In reply to Ionen Wolkens from comment #3)
> I'd be kind of surprised if portage is not getting it right, but genkernel not so much.
I do see one suspicious bit (which would emit a warning):

        local modulesdb_file="/var/lib/module-rebuild/moduledb"
        if [ ! -s "${modulesdb_file}" ]
        then 
                print_info 2 "$(get_indent 1)>> '${modulesdb_file}' does not exist or is empty; Skipping '${MODULEREBUILD_CMD}' ..."
                return
        fi

It does not actually use this file that I can see (old deprecated cruft that portage does not need either), it just checks if it's there and not empty.

But with linux-mod-r1 it's fairly likely to end up empty and/or never created.

[Comment 5 Larry the Git Cow 2023-07-05 17:41:38 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=57a4a1e250dfcc37f0169d3dd9d4a6a7d9308e67

commit 57a4a1e250dfcc37f0169d3dd9d4a6a7d9308e67
Author:     Sam James <[e-mail]>
AuthorDate: 2023-07-05 17:40:44 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-07-05 17:40:44 +0000

    Don't require obsolete /var/lib/module-rebuild/moduledb to exist
    
    See 71110f715fc46f148280b52b297121786504a325 and d9687a4df038382187300d6f44230661ff5bc377
    in gentoo.git.
    
    Bug: https://bugs.gentoo.org/909722
    Signed-off-by: Sam James <[e-mail]>

 doc/genkernel.8.txt | 4 +---
 gen_compile.sh      | 7 -------
 2 files changed, 1 insertion(+), 10 deletions(-)

[Comment 6 Larry the Git Cow 2023-07-05 18:27:29 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e01ec132717e83208d78eb8b81e00ddb0ef91f7b

commit e01ec132717e83208d78eb8b81e00ddb0ef91f7b
Author:     Sam James <[e-mail]>
AuthorDate: 2023-07-05 18:26:47 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-07-05 18:27:15 +0000

    sys-kernel/genkernel: add 4.3.5
    
    Closes: https://bugs.gentoo.org/909650
    Bug: https://bugs.gentoo.org/909722
    Signed-off-by: Sam James <[e-mail]>

 sys-kernel/genkernel/Manifest               |   2 +
 sys-kernel/genkernel/genkernel-4.3.5.ebuild | 322 ++++++++++++++++++++++++++++
 sys-kernel/genkernel/genkernel-9999.ebuild  |   6 +-
 3 files changed, 327 insertions(+), 3 deletions(-)

[Comment 7 Sam James 2023-07-05 18:30:30 UTC]

Can you try genkernel-4.3.5 and let us know if that works?

[Comment 8 Julien Delquié 2023-07-05 19:27:25 UTC]

Just tried it, and it works!

Thank you very much for the fix and your time. :)

[Comment 9 Ionen Wolkens 2023-07-18 19:33:16 UTC]

re-assigning (nothing to do with nvidia)

fixed by comment #6 but not closing myself given stable is technically affected too

[Comment 10 Sam James 2023-07-18 21:51:56 UTC]

Thanks for the reminder!