Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1477 - SLOT enhancement in /var/db/pkg to enable good kernel module handling
Summary: SLOT enhancement in /var/db/pkg to enable good kernel module handling
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Portage team
: 9561 12170 12690 22177 29240 32019 35587 37800 (view as bug list)
Depends on: 3120 5477
Blocks: 2765 28846
  Show dependency tree
Reported: 2002-04-02 14:11 UTC by Avi Schwartz
Modified: 2011-10-30 22:21 UTC (History)
15 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Avi Schwartz 2002-04-02 14:11:00 UTC
When you build modules which are not part of the kernel, for example the alsa or
the pcmcia_cs modules, emerge should remove the previous version of a module
ONLY for the currently running kernel hierarchy and not from a different kernel
version.  In the current system, the modules are removed even from a different
kernel version causing problems when trying to boot using the other kernel.
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-04-03 23:39:30 UTC
yep, we need to fix this.
Comment 2 Troy Dack 2002-10-23 21:11:53 UTC
This has been annoying me too and I have been manually copying

/lib/modules/<last-kernel-drivers were emerged against>

to a backup diirectory, performing the emerge and then restoring the directory.

I just had a thought, could CONFIG_PROTECT be used to protect /lib/modules/* ?

Thus prevent a re-emerge from deleting the previous emerge that was done against
a different kernel.
Comment 3 SpanKY gentoo-dev 2002-12-15 08:32:24 UTC
*** Bug 9561 has been marked as a duplicate of this bug. ***
Comment 4 SpanKY gentoo-dev 2002-12-15 08:32:37 UTC
*** Bug 12170 has been marked as a duplicate of this bug. ***
Comment 5 SpanKY gentoo-dev 2002-12-26 08:13:57 UTC
*** Bug 12690 has been marked as a duplicate of this bug. ***
Comment 6 Martin Holzer (RETIRED) gentoo-dev 2003-06-05 11:59:36 UTC
*** Bug 22177 has been marked as a duplicate of this bug. ***
Comment 7 TGL 2003-09-16 14:59:35 UTC
I've proposed a portage patch that could fix this issue on bug #24990.
Comment 8 Martin Holzer (RETIRED) gentoo-dev 2003-09-21 03:45:27 UTC
*** Bug 29240 has been marked as a duplicate of this bug. ***
Comment 9 A. Craig West 2003-09-27 17:25:49 UTC
I'm not really clear what SLOT's have to do with this problem It seems to
be something that is unique to kernel modules. I sort of like the CONFIG_PROTECT
idea, though.
Comment 10 Peter Ruskin 2003-10-15 08:09:14 UTC
CONFIG_PROTECT seems to work for me.  I made a new kernel 2.4.23_pre6-gss-r1
and still had 2.4.22_pre2-gss.  The video directory was wiped from 2.4.22_pre2-gss

when I emerged nvidia-kernel.  I use:

env AUTOCLEAN="no" ACCEPT_KEYWORDS="~x86" emerge nvidia-kernel, so the 
env AUTOCLEAN="no" setting gets ignored. I added CONFIG_PROTECT="/lib/modules" to /etc/make.conf and that seems
to do the trick.

BTW here's a useful script from Georgi that tells you which ebuilds are affected:

# /usr/local/bin/kernel-deps
# list the ebuilds that depend on kernel version.
# suggested by Georgi Georgiev <>

for i in `grep -l ' /lib/modules/' /var/db/pkg/*/*/CONTENTS`; do
	ii=`dirname $i`;
	cat $ii/COUNTER; echo " $ii";
done | sort -n | cut -f5,6 -d/ | sed -e 's/^/>=/'
Comment 11 SpanKY gentoo-dev 2003-10-27 15:20:28 UTC
*** Bug 32019 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Robbins (RETIRED) gentoo-dev 2003-10-27 19:24:11 UTC
This needs to get fixed soon. This bug has been open for well over a year.
Comment 13 Daniel Robbins (RETIRED) gentoo-dev 2003-10-31 22:32:40 UTC
OK, I fixed this. /lib/modules is now "unmerge protected", which means that
nothing in /lib/modules will get unmerged (sorta like how config protection
works), but if you upgrade a module it won't get named ._cfg0000_nvidia.o
for example. This is actually a good approach since ebuilds like emu10k1
install a module *and* supporting tools. You wouldn't want to put each emu10k1
ebuild in a different SLOT since those supporting tools do overwrite each
other. This is a nice compromise that didn't require massive hacks, and should
fix all user problems.

This fix should show up in Portage 2.0.49-r17.
Comment 14 Paul Varner (RETIRED) gentoo-dev 2003-12-03 08:50:21 UTC
I was doing some testing for Bug 34921 (A proposed script to rebuild third party packages that supply kernel modules)  For the testing I installed portage 2.0.49-r18.  During my testing, modules were still removed from /lib/modules.  Full test results are located at the above mentioned bug.  Is there something that needs to go into make.globals or make.conf that I somehow missed when upgrading? Here is the output from emerge info.  I will supply make.* files if needed to determine what is wrong.

Portage 2.0.49-r18 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.22-gentoo-test-r1)
System uname: 2.4.22-gentoo-test-r1 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz
Gentoo Base System version
CFLAGS="-march=pentium4 -O2 -pipe"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc /etc/gconf /etc/env.d"
CXXFLAGS="-march=pentium4 -O2 -pipe"
FEATURES="autoaddcvs ccache fixpackages sandbox"
USE="X acpi alsa arts avi berkdb cdr crypt cups dvd encode esd fbcon foomaticdb gdbm gif gpm gtk gtk2 imlib java jpeg kde libg++ libwww mad mbox mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls oggvorbis opengl oss pam pda pdflib perl png ppds python qt quicktime readline sasl sdl slang spell sse ssl svga tcltk tcpd truetype usb x86 xml2 xmms xv zlib"
Comment 15 Paul Varner (RETIRED) gentoo-dev 2003-12-03 12:51:54 UTC
After searching and diff'ing through CVS, I have noticed that the fix isn't in the source tarball that is downloaded and built.  The CVS header for the current shows version 1.341 while, the CVS header for the fixed version is 1.345  Do we have an idea which release the fixed will actually make it into the source tarball? The information given in the previous comments is misleading as it indicates that the fix is in 2.0.49-r18 when it actually is not.
Comment 16 SpanKY gentoo-dev 2003-12-11 08:01:59 UTC
*** Bug 35587 has been marked as a duplicate of this bug. ***
Comment 17 SpanKY gentoo-dev 2004-01-10 13:54:09 UTC
*** Bug 37800 has been marked as a duplicate of this bug. ***
Comment 18 Jakub Moc (RETIRED) gentoo-dev 2005-06-04 00:37:24 UTC
*** Bug 94953 has been marked as a duplicate of this bug. ***