Backed up kernels
Hi Masahiro, Michal,
When I run "make install", if a kernel by the same version number + flavor string already exists, a backup is created with ".old" appended. Over time, this adds many entries to my boot menu, makes some package updates take much longer (e.g. when all initrds must be regenerated), and ultimately confuses grub2, which fails to find the matching modules directory under /lib/modules.
You could argue that grub2 could be fixed to find the right modules directory, but in fact there is no guarantee that the modules built for the new kernel are fully compatible with the old kernel. Keeping a backup copy of the old modules is also not possible, because both kernels have the same $(uname -r) and therefore the modules of both kernels must live under the same /lib/modules/$(uname -r), which collides.
Given that, is there really any practical value in saving a backup of old kernels? I'm doing kernel development for 15 years and I can't remember ever booting one of these ".old" kernels. If my latest development kernel doesn't work for any reason, I will just boot back to the distribution kernel.
Therefore I am asking, can we change "make install" so that it does NOT create a backup copy of an existing kernel?
Thanks,
Signature · 2 lines
Jean Delvare SUSE L3 Support
Hi Jean,
Quoted 18 lines · Jean Delvare
Hi Masahiro, Michal,
When I run "make install", if a kernel by the same version number + flavor string already exists, a backup is created with ".old" appended. Over time, this adds many entries to my boot menu, makes some package updates take much longer (e.g. when all initrds must be regenerated), and ultimately confuses grub2, which fails to find the matching modules directory under
/lib/modules.You could argue that grub2 could be fixed to find the right modules directory, but in fact there is no guarantee that the modules built for the new kernel are fully compatible with the old kernel. Keeping a backup copy of the old modules is also not possible, because both kernels have the same $(uname -r) and therefore the modules of both kernels must live under the same /lib/modules/$(uname -r), which collides.
Quoted 8 lines
Given that, is there really any practical value in saving a backup of old kernels? I'm doing kernel development for 15 years and I can't remember ever booting one of these ".old" kernels. If my latest development kernel doesn't work for any reason, I will just boot back to the distribution kernel.
Therefore I am asking, can we change "make install" so that it does NOT create a backup copy of an existing kernel?
I think your suggestion makes sense, but "make install" is basically implemented by arch-specific shell script.
(For example, arch/x86/boot/install.sh)
Will you talk to the maintainers
of architecture you are interested in?
(or send it to [email protected])
Quoted 4 lines
Thanks,
--
Jean Delvare
SUSE L3 Support
Signature · 2 lines
Best Regards Masahiro Yamada
Hi Masahiro,
Quoted 8 lines · Masahiro Yamada
Quoted 2 lines · Jean Delvare
Therefore I am asking, can we change "make install" so that it does NOT create a backup copy of an existing kernel?
I think your suggestion makes sense, but "make install" is basically implemented by arch-specific shell script.
(For example,arch/x86/boot/install.sh)
Thanks for the pointer. However I have a hard time believing that the script above is what is run when I call "make install". It looks pretty old, doesn't support kernel files with version strings, and only knows of lilo as a boot loader.
But I see there is a hook at the beginning for a user or distribution provided install script:
if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
So I guess that what I really care about is the /sbin/installkernel script on my system, which is part of the dracut package. Which means I must talk to the dracut package maintainer of my distribution.
Quoted 4 lines
Will you talk to the maintainers
of architecture you are interested in?(or send it to [email protected])
It doesn't seem x86-specific, as apparently a lot of code was copy-and-pasted across architectures over time. It probably doesn't make sense to change it on one architecture and not on the others.
Also, if anyone is using these basic kernel-provided installation scripts, then keeping a backup may actually make sense, because the kernel files have no version strings, so a new kernel would always overwrite the previous one, only leaving one kernel in place. If that kernel doesn't boot for whatever reason, then game over.
So I think we should leave things as is on the kernel side.
Thanks again,
Signature · 2 lines
Jean Delvare SUSE L3 Support