All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	martin.wilck@suse.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Backed up kernels
Date: Wed, 21 Nov 2018 10:06:03 +0100	[thread overview]
Message-ID: <20181121100603.5afd53ed@endymion> (raw)
In-Reply-To: <CAK7LNATyF4GvvoMz0FphfBu739Qvy7L1KzdFcNyj5HhFsYK53Q@mail.gmail.com>

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

      reply	other threads:[~2018-11-21 19:39 UTC|newest]

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

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=20181121100603.5afd53ed@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.