<div dir="ltr"><div dir="ltr">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.<div><br></div><div>This issue with GKE specifically was reported publicly @ <a href="https://lists.ubuntu.com/archives/kernel-team/2023-May/139318.html">https://lists.ubuntu.com/archives/kernel-team/2023-May/139318.html</a></div><div><br></div><div>Phil</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 May 2023 at 13:20, Juerg Haefliger <<a href="mailto:juerg.haefliger@canonical.com">juerg.haefliger@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 25 Apr 2023 11:05:39 +0200<br>
Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com" target="_blank">steve.langasek@ubuntu.com</a>> wrote:<br>
<br>
> Hi folks,<br>
> <br>
> Kernel updates have an interesting property that, unlike most SRUs, the<br>
> binary package names change for each update, because the ABI is presumed to<br>
> change each time.<br>
> <br>
> The result of this is that each kernel update causes the binary packages<br>
> from the previous version to become "NBS" (not built from source).<br>
> <br>
> Cleanup of NBS packages from the archive is a manual process involving<br>
> Archive Admins; they are not automatically removed from the archive.  And<br>
> historically, we did not want to remove NBS kernel packages during a release<br>
> cycle, because our netboot images relied on modules of matching ABI being<br>
> available in the archive corresponding to the kernel ABI used in the netboot<br>
> image - and as we did not control when our users deployed netboot images on<br>
> their infrastructure, we did not want to arbitrarily break working customer<br>
> systems, we did not remove NBS kernel packages as we went - only at EOL of a<br>
> release.<br>
> <br>
> However, netboot images that rely on kernel packages of a matching ABI being<br>
> available in the archive are an artifact of debian-installer, and as of<br>
> jammy, we no longer ship debian-installer.  Therefore, this rationale for<br>
> retaining the old kernel binary packages in the archive no longer exists.<br>
> <br>
> Nearly 50% of all binary packages published in the jammy-updates pocket<br>
> today are from kernels[1], and this proportion only increases as an LTS<br>
> ages.  I have not done the analysis, but I expect the kernel packages to<br>
> represent a similar or higher proportion of the *size* of the -updates<br>
> pocket.  Thus, keeping these old binary packages around impacts both the<br>
> speed of `apt update` for both -updates and -security pockets, and the size<br>
> of the mirror set for these releases.<br>
> <br>
> I am therefore intending that, for jammy and later releases, we start to<br>
> prune NBS kernel packages on an ongoing basis, not just at EOL time.<br>
> <br>
<br>
We already have users complaining on IRC about missing kernel packages...<br>
What is the official way/process for getting older packages for example for<br>
crash dump analysis where one might need an older kernel+dbgsym from an<br>
active series?<br>
<br>
...Juerg<br>
-- <br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Phil Roche<br></div><div>Staff Software Engineer<br><div>Canonical Public Cloud</div></div></div></div>