Backed up kernels

Backed up kernels

[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.

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,
-- 
Jean Delvare
SUSE L3 Support

Re: Backed up kernels

[Masahiro Yamada]

Hi Jean,


On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare <jdelvare@suse.de> wrote:
>
> 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?


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 linux-arch@vger.kernel.org)


> Thanks,
> --
> Jean Delvare
> SUSE L3 Support



-- 
Best Regards
Masahiro Yamada

Re: Backed up kernels

[Jean Delvare]

Hi Masahiro,

On Wed, 21 Nov 2018 15:59:49 +0900, Masahiro Yamada wrote:
> On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare <jdelvare@suse.de> wrote:
> > 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.

> Will you talk to the maintainers
> of architecture you are interested in?
> 
> (or send it to linux-arch@vger.kernel.org)

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,
-- 
Jean Delvare
SUSE L3 Support