[gentoo-user] Since when does module-rebuild delete modules for previous kernel version?

[gentoo-user] Since when does module-rebuild delete modules for previous kernel version?

[Nikos Chantziaras]

So I just noticed that when I run:

emerge @module-rebuild

after having installed a kernel update, the kernel modules of the 
previous kernel version are being deleted. I am sure this didn't use to 
be the case. I have two entries configured in grub:

   Gentoo
   Gentoo (previous kernel)

They load /boot/vmlinuz and /boot/vmlinuz.old respectively (these are 
created by "make install" of gentoo-sources.)

Right now, I have gentoo-sources-5.10.47 booted. Modules are in:

   /lib/modules/5.10.47-gentoo

I just built 5.10.48 and did the usual "make install" and "make 
modules_install". This updated the vmlinuz and vmlinuz.old symlinks in 
/boot (as well as the config[.old] and System.map[.old] symlinks) and 
installed its modules into:

   /lib/modules/5.10.48-gentoo

So far, so good. But when I ran "emerge @module-rebuild", which rebuilds 
these two packages:

   app-emulation/vmware-modules
   x11-drivers/nvidia-drivers

The vmwware and nvidia kernel modules got deleted from 
/lib/modules/5.10.47-gentoo.

This is bad. When did this change? How can I prevent this from happening?

Re: [gentoo-user] Since when does module-rebuild delete modules for previous kernel version?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Thu, 8 Jul 2021 02:09:17 +0300, Nikos Chantziaras wrote:

> So far, so good. But when I ran "emerge @module-rebuild", which
> rebuilds these two packages:
> 
>    app-emulation/vmware-modules
>    x11-drivers/nvidia-drivers
> 
> The vmwware and nvidia kernel modules got deleted from 
> /lib/modules/5.10.47-gentoo.
> 
> This is bad. When did this change? How can I prevent this from
> happening?

Hasn't this always been the case. emerging a package removes files
installed by the previous merge.

I think adding /lib/modules to CONFIG_PROTECT will prevent their
deletion. 


-- 
Neil Bothwick

It is impossible to fully enjoy procrastination
unless one has plenty of work to do.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Since when does module-rebuild delete modules for previous kernel version?

[Nikos Chantziaras]

On 08/07/2021 02:18, Neil Bothwick wrote:
> On Thu, 8 Jul 2021 02:09:17 +0300, Nikos Chantziaras wrote:
> 
>> So far, so good. But when I ran "emerge @module-rebuild", which
>> rebuilds these two packages:
>>
>>     app-emulation/vmware-modules
>>     x11-drivers/nvidia-drivers
>>
>> The vmwware and nvidia kernel modules got deleted from
>> /lib/modules/5.10.47-gentoo.
>>
>> This is bad. When did this change? How can I prevent this from
>> happening?
> 
> Hasn't this always been the case. emerging a package removes files
> installed by the previous merge.
> 
> I think adding /lib/modules to CONFIG_PROTECT will prevent their
> deletion.

I just tried that after "eselect kernel set 1" and rebuilding modules, 
and it doesn't help.

I am quite sure the modules were not uninstalled in my old system. It 
could be that I had to set some option somewhere, but I don't remember :-/

Re: [gentoo-user] Re: Since when does module-rebuild delete modules for previous kernel version?

[Dale]

Nikos Chantziaras wrote:
> On 08/07/2021 02:18, Neil Bothwick wrote:
>> On Thu, 8 Jul 2021 02:09:17 +0300, Nikos Chantziaras wrote:
>>
>>> So far, so good. But when I ran "emerge @module-rebuild", which
>>> rebuilds these two packages:
>>>
>>>     app-emulation/vmware-modules
>>>     x11-drivers/nvidia-drivers
>>>
>>> The vmwware and nvidia kernel modules got deleted from
>>> /lib/modules/5.10.47-gentoo.
>>>
>>> This is bad. When did this change? How can I prevent this from
>>> happening?
>>
>> Hasn't this always been the case. emerging a package removes files
>> installed by the previous merge.
>>
>> I think adding /lib/modules to CONFIG_PROTECT will prevent their
>> deletion.
>
> I just tried that after "eselect kernel set 1" and rebuilding modules,
> and it doesn't help.
>
> I am quite sure the modules were not uninstalled in my old system. It
> could be that I had to set some option somewhere, but I don't remember
> :-/
>
>
>


I don't recall it doing that way either.  I've had a kernel go bad
before and had to reboot a old kernel.  If it deleted the files in the
old modules directory, then my GUI wouldn't come up because the video
drivers would no longer be there.  I think I'd remember that.  :/

Just for giggles, I did a ls for my current installed kernel versions
modules directory.  This is what it shows.


root@fireball / # ls -al /lib/modules/4.19.40-gentoo/
total 80
drwxr-xr-x  4 root root  4096 May  3  2020 .
drwxr-xr-x 14 root root  4096 Jul  1 01:39 ..
lrwxrwxrwx  1 root root    29 May 15  2019 build ->
/usr/src/linux-4.19.40-gentoo
drwxr-xr-x  3 root root  4096 Apr 23  2020 kernel
-rw-r--r--  1 root root   334 May  3  2020 modules.alias
-rw-r--r--  1 root root   530 May  3  2020 modules.alias.bin
-rw-r--r--  1 root root 12021 Apr 23  2020 modules.builtin
-rw-r--r--  1 root root 15879 May  3  2020 modules.builtin.bin
-rw-r--r--  1 root root   156 May  3  2020 modules.dep
-rw-r--r--  1 root root   321 May  3  2020 modules.dep.bin
-rw-r--r--  1 root root     0 May  3  2020 modules.devname
-rw-r--r--  1 root root    36 Apr 23  2020 modules.order
-rw-r--r--  1 root root    55 May  3  2020 modules.softdep
-rw-r--r--  1 root root  3838 May  3  2020 modules.symbols
-rw-r--r--  1 root root  4271 May  3  2020 modules.symbols.bin
lrwxrwxrwx  1 root root    29 Apr 23  2020 source ->
/usr/src/linux-4.19.40-gentoo
drwxr-xr-x  2 root root  4096 Feb 15 01:23 video

root@fireball / # ls -al /lib/modules/5.6.7-gentoo/
total 184
drwxr-xr-x  4 root root   4096 Apr 20 01:47 .
drwxr-xr-x 14 root root   4096 Jul  1 01:39 ..
lrwxrwxrwx  1 root root     27 May  2  2020 build ->
/usr/src/linux-5.6.7-gentoo
drwxr-xr-x  3 root root   4096 May  9  2020 kernel
-rw-r--r--  1 root root    334 Apr 20 01:47 modules.alias
-rw-r--r--  1 root root    530 Apr 20 01:47 modules.alias.bin
-rw-r--r--  1 root root  12558 May  9  2020 modules.builtin
-rw-r--r--  1 root root      0 Apr 20 01:47 modules.builtin.alias.bin
-rw-r--r--  1 root root  16054 Apr 20 01:47 modules.builtin.bin
-rw-r--r--  1 root root 101792 May  9  2020 modules.builtin.modinfo
-rw-r--r--  1 root root    193 Apr 20 01:47 modules.dep
-rw-r--r--  1 root root    401 Apr 20 01:47 modules.dep.bin
-rw-r--r--  1 root root      0 Apr 20 01:47 modules.devname
-rw-r--r--  1 root root     36 May  9  2020 modules.order
-rw-r--r--  1 root root     55 Apr 20 01:47 modules.softdep
-rw-r--r--  1 root root   3768 Apr 20 01:47 modules.symbols
-rw-r--r--  1 root root   4321 Apr 20 01:47 modules.symbols.bin
lrwxrwxrwx  1 root root     27 May  9  2020 source ->
/usr/src/linux-5.6.7-gentoo
drwxr-xr-x  2 root root   4096 Apr 20 01:47 video

root@fireball / # ls -al /lib/modules/5.10.46-gentoo/
total 184
drwxr-xr-x  3 root root   4096 Jul  1 01:39 .
drwxr-xr-x 14 root root   4096 Jul  1 01:39 ..
lrwxrwxrwx  1 root root     29 Jul  1 01:39 build ->
/usr/src/linux-5.10.46-gentoo
drwxr-xr-x  3 root root   4096 Jul  1 01:39 kernel
-rw-r--r--  1 root root    108 Jul  1 01:39 modules.alias
-rw-r--r--  1 root root    335 Jul  1 01:39 modules.alias.bin
-rw-r--r--  1 root root  12739 Jul  1 01:39 modules.builtin
-rw-r--r--  1 root root      0 Jul  1 01:39 modules.builtin.alias.bin
-rw-r--r--  1 root root  16480 Jul  1 01:39 modules.builtin.bin
-rw-r--r--  1 root root 103263 Jul  1 01:39 modules.builtin.modinfo
-rw-r--r--  1 root root     37 Jul  1 01:39 modules.dep
-rw-r--r--  1 root root     74 Jul  1 01:39 modules.dep.bin
-rw-r--r--  1 root root      0 Jul  1 01:39 modules.devname
-rw-r--r--  1 root root     36 Jul  1 01:39 modules.order
-rw-r--r--  1 root root     55 Jul  1 01:39 modules.softdep
-rw-r--r--  1 root root     49 Jul  1 01:39 modules.symbols
-rw-r--r--  1 root root     12 Jul  1 01:39 modules.symbols.bin
lrwxrwxrwx  1 root root     29 Jul  1 01:39 source ->
/usr/src/linux-5.10.46-gentoo
root@fireball / #


I currently have three available kernels, one I did recently and have
yet to reboot and use.  I also haven't changed the pointer and
re-emerged any modules yet.  Still, as one can see, there is a video
directory for video which contains my nvidia drivers for each kernel
version like this:


root@fireball / # ls -al /lib/modules/4.19.40-gentoo/video/
total 28020
drwxr-xr-x 2 root root     4096 Feb 15 01:23 .
drwxr-xr-x 4 root root     4096 May  3  2020 ..
-rw-r--r-- 1 root root    80504 May  3  2020 nvidia-drm.ko
-rw-r--r-- 1 root root 27162104 May  3  2020 nvidia.ko
-rw-r--r-- 1 root root  1437216 May  3  2020 nvidia-modeset.ko
root@fireball / # ls -al /lib/modules/5.6.7-gentoo/video/
total 43536
drwxr-xr-x 2 root root     4096 Apr 20 01:47 .
drwxr-xr-x 4 root root     4096 Apr 20 01:47 ..
-rw-r--r-- 1 root root    92224 Apr 19 22:38 nvidia-drm.ko
-rw-r--r-- 1 root root 40951920 Apr 19 22:38 nvidia.ko
-rw-r--r-- 1 root root  1566736 Apr 19 22:38 nvidia-modeset.ko
-rw-r--r-- 1 root root  1950824 Apr 19 22:38 nvidia-uvm.ko
root@fireball / #


So, at least when I updated that 5.6.7 kernel ages ago, it didn't delete
anything old.  It should install to the new location as if it is a new
install, since it is a new kernel, it sort of is a new install since it
has never been installed for THAT kernel before. 

Has this changed?  Is it a setting somewhere that is a new default? 
Can't imagine what that is tho.  I know I don't like the change if it
has because I tend to keep multiple kernels installed as fall backs.  If
I have to fall back on a older kernel, I expect everything to work like
it did the last time I used that kernel as far as drivers go, including
and especially video drivers. 

So, let me test this theory a bit.  I used eselect to point to new
kernel.  I emerged the nvidia drivers again and here is the listing now,
old kernels and the one I've yet to use but just re-emerged the drivers
for. 


root@fireball / # ls -al /lib/modules/4.19.40-gentoo/video/
total 28020
drwxr-xr-x 2 root root     4096 Feb 15 01:23 .
drwxr-xr-x 4 root root     4096 May  3  2020 ..
-rw-r--r-- 1 root root    80504 May  3  2020 nvidia-drm.ko
-rw-r--r-- 1 root root 27162104 May  3  2020 nvidia.ko
-rw-r--r-- 1 root root  1437216 May  3  2020 nvidia-modeset.ko

root@fireball / # ls -al /lib/modules/5.6.7-gentoo/video/
total 43536
drwxr-xr-x 2 root root     4096 Apr 20 01:47 .
drwxr-xr-x 4 root root     4096 Apr 20 01:47 ..
-rw-r--r-- 1 root root    92224 Apr 19 22:38 nvidia-drm.ko
-rw-r--r-- 1 root root 40951920 Apr 19 22:38 nvidia.ko
-rw-r--r-- 1 root root  1566736 Apr 19 22:38 nvidia-modeset.ko
-rw-r--r-- 1 root root  1950824 Apr 19 22:38 nvidia-uvm.ko

root@fireball / # ls -al /lib/modules/5.10.46-gentoo/video/
total 43532
drwxr-xr-x 2 root root     4096 Jul  7 19:24 .
drwxr-xr-x 4 root root     4096 Jul  7 19:24 ..
-rw-r--r-- 1 root root    93000 Jul  7 19:22 nvidia-drm.ko
-rw-r--r-- 1 root root 40953232 Jul  7 19:22 nvidia.ko
-rw-r--r-- 1 root root  1566784 Jul  7 19:22 nvidia-modeset.ko
-rw-r--r-- 1 root root  1947848 Jul  7 19:22 nvidia-uvm.ko
root@fireball / #


So, old version of modules are still there as they should be and new
modules installed for the new kernel version.  This is the build info:


[ebuild   R    ] x11-drivers/nvidia-drivers-460.67:0/460::gentoo  USE="X
driver tools -dist-kernel -static-libs"


It seems to work as it used to here.  Maybe a USE flag above will change
that?? I dunno.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Since when does module-rebuild delete modules for previous kernel version?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Thu, 8 Jul 2021 02:46:32 +0300, Nikos Chantziaras wrote:

> > Hasn't this always been the case. emerging a package removes files
> > installed by the previous merge.
> > 
> > I think adding /lib/modules to CONFIG_PROTECT will prevent their
> > deletion.  
> 
> I just tried that after "eselect kernel set 1" and rebuilding modules, 
> and it doesn't help.

Shame, the man page indicates that it should:
"In addition to protecting overwritten files, Portage will not delete any
 files from a protected directory when a package is unmerged."

> I am quite sure the modules were not uninstalled in my old system. It 
> could be that I had to set some option somewhere, but I don't remember
> :-/

I've just tried letting it re-emerge virtualbox-modules here and the old
modules are still there.


-- 
Neil Bothwick

WinErr 678: This will end your Windows session. Do you want to play
another game?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Since when does module-rebuild delete modules for previous kernel version?

[Nikos Chantziaras]

On 08/07/2021 02:09, Nikos Chantziaras wrote:
> So I just noticed that when I run:
> 
> emerge @module-rebuild
> 
> after having installed a kernel update, the kernel modules of the 
> previous kernel version are being deleted. I am sure this didn't use to 
> be the case.
Found the issue. On my new system, I had this in my make.conf:

   UNINSTALL_IGNORE="/usr/src"

because /usr/src is a symlink to a directory on my HDD (as I don't want 
to write all that data to my SSD.) Portage would bark about it during 
depclean if I don't put that in UNINSTALL_IGNORE.

 From "man make.conf":

   UNINSTALL_IGNORE = [space delimited list of fnmatch patterns]

   This variable prevents uninstallation of files that match
   specific fnmatch(3) patterns. [...] Defaults to
   "/lib/modules/*".

Right. However, it's obvious I've hit a portage inconsistency here. For 
example, when I use:

   CONFIG_PROTECT="blah"

in make.conf, "blah" is appended to CONFIG_PROTECT. But for whatever 
reason, this is not the case for UNINSTALL_IGNORE. It completely nukes 
the default value instead. I had to change this to:

   UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /usr/src"

and now all is fine.

Re: [gentoo-user] Re: Since when does module-rebuild delete modules for previous kernel version?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Sat, 10 Jul 2021 11:22:38 +0300, Nikos Chantziaras wrote:

> Right. However, it's obvious I've hit a portage inconsistency here. For 
> example, when I use:
> 
>    CONFIG_PROTECT="blah"
> 
> in make.conf, "blah" is appended to CONFIG_PROTECT. But for whatever 
> reason, this is not the case for UNINSTALL_IGNORE. It completely nukes 
> the default value instead. I had to change this to:
> 
>    UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /usr/src"

I've seen these inconsistencies before. The documentation usually states
when a variable's contents are replaced rather than appended to, so I'd
suggest a bug report against the make.conf man page.


-- 
Neil Bothwick

"Everything takes longer than expected, even when you take
  into account Hoffstead's Law." - Hoffstead's Law

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]