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@canonical.com> wrote:
On Tue, 25 Apr 2023 11:05:39 +0200
Steve Langasek <steve.langasek@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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Phil Roche
Staff Software Engineer
Canonical Public Cloud
