public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org,
	Martin Wilck <martin.wilck@suse.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Backed up kernels
Date: Tue, 20 Nov 2018 14:40:07 +0100	[thread overview]
Message-ID: <20181120144007.016e4998@endymion> (raw)

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

             reply	other threads:[~2018-11-20 13:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 13:40 Jean Delvare [this message]
2018-11-21  6:59 ` Backed up kernels Masahiro Yamada
2018-11-21  9:06   ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181120144007.016e4998@endymion \
    --to=jdelvare@suse.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.wilck@suse.com \
    --cc=michal.lkml@markovi.net \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox