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.
yep, we need to fix this.
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.
*** Bug 9561 has been marked as a duplicate of this bug. ***
*** Bug 12170 has been marked as a duplicate of this bug. ***
*** Bug 12690 has been marked as a duplicate of this bug. ***
*** Bug 22177 has been marked as a duplicate of this bug. ***
I've proposed a portage patch that could fix this issue on bug #24990.
*** Bug 29240 has been marked as a duplicate of this bug. ***
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.
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. ...so 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: ############################################### #!/bin/sh # /usr/local/bin/kernel-deps # list the ebuilds that depend on kernel version. # suggested by Georgi Georgiev <chutz@gg3.net> 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/^/>=/' ###############################################
*** Bug 32019 has been marked as a duplicate of this bug. ***
This needs to get fixed soon. This bug has been open for well over a year.
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.
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 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" 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" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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"
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 portage.py shows version 1.341 while, the CVS header for the fixed version is 1.345 Do we have an idea which release the fixed portage.py 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.
*** Bug 35587 has been marked as a duplicate of this bug. ***
*** Bug 37800 has been marked as a duplicate of this bug. ***
*** Bug 94953 has been marked as a duplicate of this bug. ***
