NBS removals of old kernels from stable -security and -updates pockets

[Phil Roche]

Confirming publicly that there has been an exception made for future gke
and gkeop (Anthos on VMware) kernel header and module packages due to the
GKE deployments being long-lived and often having older kernels installed.

This issue with GKE specifically was reported publicly @
https://lists.ubuntu.com/archives/kernel-team/2023-May/139318.html

Phil

On Fri, 12 May 2023 at 13:20, Juerg Haefliger <juerg.haefliger at canonical.com>
wrote:

> On Tue, 25 Apr 2023 11:05:39 +0200
> Steve Langasek <steve.langasek at ubuntu.com> wrote:
>
> > Hi folks,
> >
> > Kernel updates have an interesting property that, unlike most SRUs, the
> > binary package names change for each update, because the ABI is presumed
> to
> > change each time.
> >
> > The result of this is that each kernel update causes the binary packages
> > from the previous version to become "NBS" (not built from source).
> >
> > Cleanup of NBS packages from the archive is a manual process involving
> > Archive Admins; they are not automatically removed from the archive.  And
> > historically, we did not want to remove NBS kernel packages during a
> release
> > cycle, because our netboot images relied on modules of matching ABI being
> > available in the archive corresponding to the kernel ABI used in the
> netboot
> > image - and as we did not control when our users deployed netboot images
> on
> > their infrastructure, we did not want to arbitrarily break working
> customer
> > systems, we did not remove NBS kernel packages as we went - only at EOL
> of a
> > release.
> >
> > However, netboot images that rely on kernel packages of a matching ABI
> being
> > available in the archive are an artifact of debian-installer, and as of
> > jammy, we no longer ship debian-installer.  Therefore, this rationale for
> > retaining the old kernel binary packages in the archive no longer exists.
> >
> > Nearly 50% of all binary packages published in the jammy-updates pocket
> > today are from kernels[1], and this proportion only increases as an LTS
> > ages.  I have not done the analysis, but I expect the kernel packages to
> > represent a similar or higher proportion of the *size* of the -updates
> > pocket.  Thus, keeping these old binary packages around impacts both the
> > speed of `apt update` for both -updates and -security pockets, and the
> size
> > of the mirror set for these releases.
> >
> > I am therefore intending that, for jammy and later releases, we start to
> > prune NBS kernel packages on an ongoing basis, not just at EOL time.
> >
>
> We already have users complaining on IRC about missing kernel packages...
> What is the official way/process for getting older packages for example for
> crash dump analysis where one might need an older kernel+dbgsym from an
> active series?
>
> ...Juerg
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>


-- 
Phil Roche
Staff Software Engineer
Canonical Public Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230512/850450bb/attachment.html>