Could it be that openafs-kernel would not remove previous kernel modules from the system? Image one wants to test few kernels and wants to have the chance to return back to original. Current behaviour sucks: >>> Install openafs-kernel-1.4.1 into /var/tmp/portage/openafs-kernel-1.4.1/image/ category net-fs * Installing openafs module >>> Completed installing openafs-kernel-1.4.1 into /var/tmp/portage/openafs-kernel-1.4.1/image/ man: strip: i686-pc-linux-gnu-strip --strip-unneeded >>> Merging net-fs/openafs-kernel-1.4.1 to / --- /lib/ --- /lib/modules/ --- /lib/modules/2.6.17.11/ --- /lib/modules/2.6.17.11/kernel/ --- /lib/modules/2.6.17.11/kernel/fs/ >>> /lib/modules/2.6.17.11/kernel/fs/openafs/ >>> /lib/modules/2.6.17.11/kernel/fs/openafs/openafs.ko >>> Safely unmerging already-installed instance... --- cfgpro obj /lib/modules/2.6.16.28/kernel/fs/openafs/openafs.ko --- cfgpro dir /lib/modules/2.6.16.28/kernel/fs/openafs --- cfgpro dir /lib/modules/2.6.16.28/kernel/fs --- cfgpro dir /lib/modules/2.6.16.28/kernel --- cfgpro dir /lib/modules/2.6.16.28 --- !empty dir /lib/modules --- !empty dir /lib * Removing net-fs/openafs-kernel-1.4.1 from moduledb. >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. * Updating module dependencies for 2.6.17.11 ... [ ok ] * Adding module to moduledb. >>> Regenerating /etc/ld.so.cache... >>> net-fs/openafs-kernel-1.4.1 merged.
(In reply to comment #0) > Could it be that openafs-kernel would not remove previous kernel modules from > the system? Yes, this is intentional. > Image one wants to test few kernels and wants to have the chance to > return back to original. Current behaviour sucks: Current behaviour is that if you install a new kernel, and you re-emerge openafs-kernel, the old module still remains on the system. This way, when you want to run the old kernel again, it still works (provided that you didn't upgrade openafs at the same instant). Or am I missing something?
Maybe it is related to this why I don't see the modules always. ;-) oxygen ~ # find /lib/modules/ -name openafs.ko /lib/modules/2.6.15.6/kernel/fs/openafs/openafs.ko /lib/modules/2.6.17.11/kernel/fs/openafs/openafs.ko /lib/modules/2.6.16.28/kernel/fs/openafs/openafs.ko /lib/modules/2.6.17.13/fs/openafs/openafs.ko oxygen ~ #
1) There has been a change in where the openafs.ko module is put, only to make sure it's not deleted by a "make modules_install". That's the reason you see them in two different places. (You'll see more of this stuff when you try 1.5.8, which I currently don't recommend) This wasn't your point, but I thought I'd mention it anyway just to make sure. 2) I don't understand your point. You give a list of modules, and you say some are missing? Which ones? The current behaviour is not to delete previous kernel modules, your request is to have a chance to return to previous kernels. This behaviour EXACTLY accomodates your request. What am I missing here?
Well, I think you don't miss anything here. I think the problem was in the past the startup scripts looked up since some point only in the new locations and did not look into the old locations, or I have been insmoding the module manually through /etc/conf.d/local.start. ;-)
And, well, I have the same feeling that "make modules_install" deleted the previously installed file. That's why I have thought making the ebuild slotted would help. I think after some testing I see current behaviour is fine, only I would be happy if "emerge -u openafs-kernel" would look under /lib/modules/ for all openafs.ko files and recompile all of them against various /usr/src/linux-* tress as necessary (and graciously ignoring those source tress which do not exist anymore -- in that case it coudl delete the openafs.ko file I think).
I think it might be better if you'd write a script to do that, by iteratively calling "emerge openafs-kernel" setting the KERNEL_DIR variable to a new kernel dir each time.
Yes, the KERNEL_DIR variable approach works, thanks for pointing it out. Maybe the ebuild could spit out this before starting teh ebuild so other could learn from this.
