Date: Wed, 20 Jan 2021 10:23:09 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: Ariadne Conill <ariadne@dereferenced.org>,
 ~alpine/devel@lists.alpinelinux.org, Rasmus Thomsen <oss@cogitri.dev>
Subject: keep old kernel on upgrade (was: Implement versioned names for
 major libraries to ease upgrade process)
Message-ID: <20210120102309.32fed780@ncopa-desktop.lan>
In-Reply-To: <874kkrnujk.fsf@ungleich.ch>
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
	<877dpnnxcu.fsf@ungleich.ch>
	<6ce1e9200bc916ef98e6132cd907d07660fcf174.camel@cogitri.dev>
	<2478872.my5MpkESCV@nanabozho>
	<874kkrnujk.fsf@ungleich.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 12 Dec 2020 12:16:47 +0100
Nico Schottelius <nico.schottelius@ungleich.ch> wrote:

> Ariadne Conill <ariadne@dereferenced.org> writes:
> >> > if we are already doing that, why do we not do it for the linux
> >> > kernel?  

Kernel is a bit different animal.

Currently, we don't version the /boot/vmlinuz-lts which means that we
shouldn't need to regenerate the syslinux config. It also means that
multiple versions of the kernel cannot be installed at the same time.

But it is also a question of how to implement it in a clean way for
package manager.

> >>
> >> Because maintaining multiple kernels is a lot of work because they're
> >> released relatively often and we have to rebuild all modules (e.g. zfs)
> >> against new kernel versions.  
> >
> > I don't think they propose maintaining multiple kernels in parallel per se,
> > but instead versioning the package (with a provides linux-lts=${pkgver}) so
> > that older kernels can stick around if a newer kernel has a regression.  
> 
> Correct - it's not about maintaining them, but to `apk upgrade` without
> being forced to reboot, because some modules are missing after the
> upgrade.
> 
> I'd imagine something on the lines of:
> 
> a)
>     "on kernel upgrade, do not remove linux-lts-$(uname -r)"
> 
>     However all other older versions can be replaced.
> 
>     This would already solve a major pain point.
> 
> or b)
>    Keep all previous kernel versions and let the user delete old
>    versions manually
> 
>    I think this is +/- what Debian is doing. It results in a very long
>    grub list and is annoying to cleanup, but it also give a lot of
>    security, being able to switch back to an older version.
> 
> 
> I think (a) is cleaner, but probably more complicated to implement, as
> (b) could just mean that the package *name* differs and they all provide
> the linux-kernel.

I added a few comments here:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/12157#note_134555

After some thought I think what would be nice is:

- mark the kernel package with some flag, "keep-previous" or similar,
  which tells apk that on upgrade, files should not be deleted, but
  moved to a virtual package .$pkgname-previous or similar.

- new kernel gets installed, while previous remains on the system, so
  modprobe still works for running kernel. User can manually delete
  .$pkgname-previous to uninstall the previous kernel if wanted.

- during (re)boot, as last step, we have an openrc script that checks for
  .$pkgname-previous, and deletes it unless it is the running kernel.
  That way, if kernel fails to boot, the old kernel is still around as
  fallback. If boot of new kernel is successful, it will clean up the
  previous kernel and user does not need to manually remove old kernels.

To implement this we need to:

- add a version to /boot/vmlinuz-$flavor and initramfs
- add the move-ownership-of-files-if-keep-previous feature to apk-tools.
- figure out what to do if .$pkgname-previous already exists during upgrade.


> 
> Cheers,
> 
> Nico
> 
> --
> Modern, affordable, Swiss Virtual Machines. Visit
> www.datacenterlight.ch