"emerge -C rt2500" does not remove the module /lib/modules/<kernel version>/net/rt2500.ko. If one is feeling adventurous and decides to test the cvs source code, and follows the instructions in the README file, one ends up with two rt2500 modules - the original ebuild module in "/lib/modules/<kernel version>/net/" and the cvs version in "/lib/modules/<kernel version>/extra/". "/lib/modules/<kernel version>/modules.dep" still points at the original ebuild version. Manually removing the original rt2500.ko module from /net and running "depmod" seems to solve the problem. I'm no guru so I may be missing something here. Reproducible: Always Steps to Reproduce: 1. emerge rt2500, set it up and get it running 2. /etc/init.d/net.ra0 stop && modprobe -r rt2500 3. emerge -C rt2500 Actual Results: # emerge -C rt2500 net-wireless/rt2500 selected: 1.1.0_beta2-r2 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging net-wireless/rt2500-1.1.0_beta2-r2... No package files given... Grabbing a set. <<< obj /usr/share/doc/rt2500-1.1.0_beta2-r2/iwpriv_usage.txt.gz <<< obj /usr/share/doc/rt2500-1.1.0_beta2-r2/README.gz <<< obj /usr/share/doc/rt2500-1.1.0_beta2-r2/LICENSE.gz <<< obj /usr/share/doc/rt2500-1.1.0_beta2-r2/FAQ.gz <<< obj /usr/share/doc/rt2500-1.1.0_beta2-r2/CHANGELOG.gz <<< obj /usr/bin/RaConfig2500 --- cfgpro obj /lib/modules/2.6.12-ck3/net/rt2500.ko --- cfgpro dir /lib/modules/2.6.12-ck3/net --- cfgpro dir /lib/modules/2.6.12-ck3 --- cfgpro obj /etc/modules.d/rt2500 --- cfgpro dir /etc/modules.d --- cfgpro obj /etc/Wireless/RT2500STA/RT2500STA.dat --- cfgpro dir /etc/Wireless/RT2500STA --- cfgpro dir /etc/Wireless <<< dir /usr/share/doc/rt2500-1.1.0_beta2-r2 --- !empty dir /usr/share/doc --- !empty dir /usr/share --- !empty dir /usr/bin --- !empty dir /usr --- !empty dir /lib/modules --- !empty dir /lib --- !empty dir /etc * Removing net-wireless/rt2500-1.1.0_beta2-r2 from moduledb. >>> Regenerating /etc/ld.so.cache... * GNU info directory index is up-to-date. # modprobe rt2500 # iwconfig eth0 no wireless extensions. lo no wireless extensions. ra0 RT2500 Wireless ESSID:"MyESSID" Mode:Managed Frequency=2.437 GHz Bit Rate:54 Mb/s RTS thr=2312 B Fragment thr=2312 B Encryption key:off Link Quality:60 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 # lsmod | grep rt2500 rt2500 172804 1 # ll /lib/modules/2.6.12-ck3/net/ total 196 -rw-r--r-- 1 root root 198283 Jul 13 12:59 rt2500.ko # grep rt2500 /lib/modules/2.6.12-ck3/modules.dep /lib/modules/2.6.12-ck3/net/rt2500.ko: Expected Results: rt2500 module and referrences should be removed. # emerge --info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.12-ck3 i686) ================================================================= System uname: 2.6.12-ck3 i686 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -msse2 -msse -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -msse2 -msse -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo/ http://ftp.du.se/pub/os/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac alsa apache2 apm audiofile avi berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl dga dts dvd dvdr dvdread eds emboss encode esd ethereal fam fame ffmpeg flac foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml imagemagick imap imlib irda irmc ithreads java jpeg ldap libg++ libwww lirc lzo mad mbox mikmod mjpeg mmx mmxext motif mozilla mp3 mpeg mysql mythtv ncurses network nls nptl nvidia oav offensive ogg oggvorbis opengl oss pam pcre pdf pdflib perl png posix ppds pthreads python qt quicktime readline rhythmbox samba sdl slang sndfile spell sse sse2 ssl svga tcpd tiff transcode truetype truetype-fonts type1-fonts v4l v4l2 vcd vorbis wifi win32codecs xine xml xml2 xmms xv xvid xvmc yv12 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #0) > --- cfgpro obj /lib/modules/2.6.12-ck3/net/rt2500.ko As you can see, it's protected, so no - unmerge won't remove the module. Kernel modules are "modprotected", they won't be removed when unmerging, but will be overwritten when upgrading the module. This is not a bug.
(In reply to comment #1) > (In reply to comment #0) > > --- cfgpro obj /lib/modules/2.6.12-ck3/net/rt2500.ko > > As you can see, it's protected, so no - unmerge won't remove the module. Kernel > modules are "modprotected", they won't be removed when unmerging, but will be > overwritten when upgrading the module. > > This is not a bug. That may be true and correct, but it's strange to me. The package installs a module but if one wants to "uninstall" the module, emerge -C won't actually remove remove the module, it will only trivial files like docs. Is that correct? Couldn't this behavior cause problems for users that are unaware of this fact - ie conflicting modules?
(In reply to comment #2) > Couldn't this behavior cause problems for users that are unaware of this fact - > ie conflicting modules? The modules do get upgraded, they just don't get uninstalled, so I don't see that this would cause conflicting modules to be installed. See Bug 1477 for more information.
(In reply to comment #3) > See Bug 1477 for more information. > Thanks for the link. That would be a BIG problem! > The modules do get upgraded, they just don't get uninstalled, so I don't see > that this would cause conflicting modules to be installed. > I thought I'd check out the CVS version. Unmerged rt2500, built module from source and installed (as per README instructions). Ended up with the ebuild version of the module in /net and the CVS version of the module in /extra. So there were TWO rt2500.ko's, but the ebuild module was the one used since it was still referrenced in modules.dep. I had a couple of hard freezes while configuring, then I figured it out. Removing the ebuild module and running depmod solved the problem. If the commands to compile and install a module from source (make, make install) put the source version of the module in a different directory than the ebuild puts its' module, the old module will NOT be overwritten or upgraded. There will be two modules with the same name. In this case I'm talking about the rt2500. Could there possibly be other situations where this could happen. What about ivtv, lirc, alsa-driver, etc.? I admit that Bug 1477 would be a big problem, deleting modules from all installed kernels when emerge -C <module_package> is used, but this is different. IMHO, modules should be removed from the CURRENT kernel when emerge -C <module_package> is invoked. I don't see why that would be a problem. Perhaps difficult to implement, but functionally not a problem.
(In reply to comment #4) > IMHO, modules should be removed from the CURRENT kernel when emerge > -C <module_package> is invoked. I don't see why that would be a problem. > Perhaps difficult to implement, but functionally not a problem. Unless you have a better solution, I'm afraid it will stay as it is...
there is no easy way to tell if a package is being upgraded or cleaned *** This bug has been marked as a duplicate of 8423 ***
