installkernel symlinks and /lib/modules

[Goverp]

I hate to raise the possibility of more complexity in the new-improved installkernel, especially as I don't use it, but ...

I used to use the original Debian (I think) simple installkernel script that simply copied kernels into /boot while maintaining "vmlinuz" and "vmlinuz.old" symlinks, should they exist. Then I wrote my own super-dooper installkernel that has handled a lot more configurations, and further supported a "vmlinuz.new" symlink, providing test, current and fallback kernels.

Whatever, I once got burned when the vmlinuz.old kernel wouldn't boot because I'd changed compiler from LLVM to gcc, and therefore /lib/module was compiled with the wrong compiler. This was a symptom of something deeper - while having "old" and "current" kernels, installkernel doesn't similarly maintain "old" and "current" /lib/modules unless there have different version names. Logically it should maintain /lib/modules/v.r.x.old as well.
_________________
Greybeard

[AndrewAmmerlaan]

sys-kernel/installkernel does not interact at all with /lib/modules. That is handled by the 'make modules_install' target (as opposed to the 'make install' target which calls /sbin/installkernel provided by sys-kernel/installkernel).

Your idea is good though, but installkernel is not the right place to implement it. One easy way you could accomplish what you describe is to change the "CONFIG_LOCALVERSION" of the kernel before re-compiling and re-installing it. This will locally give the new kernel an effectively different version name, which means it will be separate from your old kernel both in /lib/modules and /boot.
_________________
OS: Gentoo 6.8.10-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400