[Bug]: `Recommends: linux-image` installs unrelated cloud kernel flavor (e.g. gke) instead of host's real kernel

[robkorv]

Title

[Bug]: Recommends: linux-image resolves to wrong cloud kernel flavor (gke) instead of the host's real kernel — confirms/extends #21415

Body

Summary

This confirms and extends a previously reported, still-open issue on the old tracker: https://www.virtualbox.org/ticket/21415 ("Debian/Ubuntu repositories: remove dependency 'virtualbox-x.y recommends linux-image'"), open since 2023-01-17 with no maintainer response and no linked GitHub issue.

That report described apt occasionally installing a random cloud kernel flavor (-azure, -gcp, -oracle, -aws) due to VirtualBox's packaging. This report adds:

• the exact, confirmed root-cause mechanism (captured via apt's live solver debug trace), and
• reproduction across 2 independent machines and 4 separate occurrences, with identical results each time a kernel SRU landed.

Environment

• Ubuntu 26.04 (Resolute Raccoon), amd64
• virtualbox-7.2, installed from Oracle's official apt repo (download.virtualbox.org)
• Reproduced on 2 independent physical machines

Confirmed occurrences

Machine	Date	Real kernel installed	Unwanted kernel auto-installed
A	2026-08-21	linux-image-7.0.0-30-generic	linux-image-7.0.0-1005-gke
A	2026-09-11 (caught live, pre-transaction)	linux-image-7.0.0-31-generic	linux-image-7.0.0-1006-gke
B	2026-08-24	linux-image-7.0.0-30-generic	linux-image-7.0.0-1005-gke
B	2026-09-07	linux-image-7.0.0-31-generic	linux-image-7.0.0-1006-gke

Both machines pulled the identical unwanted kernel version on every occasion a kernel SRU landed, days apart from each other. This is fully deterministic, not incidental — same trigger, same outcome, every time.

Root cause (confirmed via apt solver debug trace)

Captured live, before letting the real transaction run, with:

sudo apt-get full-upgrade -s -o Debug::pkgDepCache::AutoInstall=true -o Debug::pkgProblemResolver=true -o Debug::pkgAutoRemove=true

Relevant trace:

Following dep: virtualbox-7.2:amd64 Recommends on linux-image:amd64 <none>, provided by linux-image-7.0.0-1006-gke:amd64 7.0.0-1006.7 (2/1)
Marking: linux-image-7.0.0-1006-gke:amd64 7.0.0-1006.7 (Dependency)
Following dep: linux-image-7.0.0-1006-gke:amd64 Depends on linux-modules-7.0.0-1006-gke:amd64, provided by linux-modules-7.0.0-1006-gke:amd64 (1/1)
Marking: linux-modules-7.0.0-1006-gke:amd64 7.0.0-1006.7 (Dependency)

Mechanism:

1. virtualbox-7.2's control file carries a legacy, unversioned Recommends: linux-image — the exact dependency named in #21415 — a pre-DKMS-era catch-all meant to ensure some kernel image/headers exist.
2. Every kernel flavor Ubuntu publishes (generic, gke, gcp, aws, azure, oracle, oem, nvidia, realtime, ...) provides the unversioned virtual package linux-image. With --install-recommends on by default (apt's default), the solver must pick exactly one real package to satisfy this.
3. Ubuntu's cloud/appliance kernel flavors use a disjoint, much higher ABI numbering series (currently ~1006.x) than the desktop -generic series (currently ~31.x). apt resolves an unversioned virtual dependency by preferring the highest raw version number among providers: dpkg --compare-versions "7.0.0-1006.7" gt "7.0.0-31.31" → true. So apt deterministically prefers the cloud kernel over the host's real kernel, every single time.

This will keep recurring on every full-upgrade/dist-upgrade for as long as virtualbox-7.2 is installed and any higher-numbered cloud kernel flavor exists in the archive — which, given Ubuntu's kernel numbering scheme, will always be true.

Suggested fix

Per #21415: drop the unversioned Recommends: linux-image entirely. Any real Linux install already has a kernel image; the dependency serves no purpose in the DKMS era (VirtualBox builds vboxdrv/vboxnetflt against the running kernel via DKMS regardless of what this Recommends resolves to). If a softer hint is still wanted for less-common Debian derivatives, it should be scoped to linux-image-amd64 | linux-image-generic rather than the bare, flavor-agnostic virtual name — anything that lets apt's version-based tie-break reach an irrelevant cloud kernel reproduces this bug.

Disclosure

This report was diagnosed with the assistance of Claude (Anthropic's AI coding assistant), used to capture and interpret the apt solver debug traces, cross-reference package/kernel metadata, and correlate the pattern across the two machines. All findings were independently verified against live system state (installed packages, dpkg --compare-versions, apt-cache showpkg, and the debug trace above) before writing this report.

[robkorv]

Workaround (until this is fixed upstream)

For anyone hitting this in the meantime: pinning the cloud/appliance kernel flavors to a negative priority stops apt from ever selecting them to satisfy VirtualBox's unversioned Recommends: linux-image, forcing it to fall back to -generic/-realtime instead.

Apply:

sudo tee /etc/apt/preferences.d/no-cloud-kernels > /dev/null << 'PIN'
Package: linux-image-*-gke linux-image-*-gcp linux-image-*-aws linux-image-*-azure* linux-image-*-oracle linux-image-*-oem linux-image-*-nvidia*
Pin: release *
Pin-Priority: -1
PIN
sudo apt update

Verify it's working (should show no new install of any pinned flavor):

sudo apt full-upgrade -s | grep -iE "gke|gcp|aws|azure|oracle|-oem|nvidia-bos"

Confirmed effective on our end against a real (not simulated) trigger: the day after applying the pin, Ubuntu's unattended-upgrade service automatically installed the next kernel SRU in the background, and this time it did not pull in the gke kernel — dpkg -l and apt-cache policy both confirm the pinned flavor stayed uninstalled while the real -generic kernel updated normally.

Removing the workaround once this is fixed upstream:

sudo rm /etc/apt/preferences.d/no-cloud-kernels
sudo apt update

No further cleanup needed — the pin only affects candidate selection during dependency resolution, so removing it simply lets apt consider those flavors again on the next upgrade.

Note: adjust the flavor list to whatever's relevant on your system — the underlying bug can surface as any of gke/gcp/aws/azure/oracle/oem/nvidia-*, since all of them provide the same unversioned linux-image virtual package that VirtualBox's Recommends resolves against.