metas: point the umbrella straight at the concrete kernel #66
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix-umbrella-meta-autoremove"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
After the 7.1 → 7.2 line advance,
apt full-upgradeon trixie fails:apt ≥ 3.0 removes unused old kernels during
full-upgrade/dist-upgrade(APT::Get::AutomaticRemove::Kernels). It only removes packages named after an old kernelrelease (APT::VersionedKernelPackages,^linux-.*-<kr>$). The umbrella depended on the per-line meta (umbrella →<X.Y>meta → concrete). After an advance, the old line's meta was left auto-installed and unused. Its name has no kernelrelease in it, so apt removed the kernel, kept the meta that depends on it, and then refused the broken result. This would recur at every line advance.Change
build/build-debs.sh: the umbrella now depends directly onlinux-<kind>-<kr> (= version), plusunredacted-hardened-defaultsfor the image. This is the same shape as Debian'slinux-image-amd64. Per-line metas are unchanged and remain an opt-in series pin. Because users install them by hand, apt never autoremoves their kernel.config-architecture.mddescribes the new shape and why the umbrella must not go through the per-line meta.pinning.mddocuments the one-time cleanup for existing installs.recovery.mdcovers the error itself.Verification
I ran dummy packages under apt 3.0.3 in
debian:trixie:apt autoremoveI also ran the edited meta-emission code from
build-debs.shin the container and checked the generatedDepends:fields. shellcheck reports no warnings. Plainapt upgradenever hits this, since it skips kernel autoremoval.Follow-up: release note for the first release built from this
Every existing umbrella install has
linux-image-hardened-unredacted-7.2-amd64(and the headers meta, if installed) auto-installed. A packaging change alone can't remove it without breaking deliberate series pins, so the first release's notes need this:🤖 Generated with Claude Code
After the 7.1 -> 7.2 line advance, `apt full-upgrade` on trixie failed with: linux-image-hardened-unredacted-7.1-amd64 : Depends: linux-image-7.1.13-hardened-unredacted-amd64 (= 7.1.13-hardened1) but it is not going to be installed Error: Internal Error, AutoRemover broke stuff apt >= 3.0 removes unused old kernels during full-upgrade/dist-upgrade (APT::Get::AutomaticRemove::Kernels), but only packages named after an old kernelrelease (APT::VersionedKernelPackages, `^linux-.*-<kr>$`). The umbrella depended on the per-line meta (umbrella -> <X.Y> meta -> concrete), so an advance left the old line's meta auto-installed and unused. Its name carries no kernelrelease, so apt removed the kernel, kept the meta that depends on it, and then refused the broken result. That recurs at every line advance, once the old line's last kernel is neither booted nor among the two newest. - build/build-debs.sh: the umbrella now depends directly on linux-<kind>-<kr> (= version), plus unredacted-hardened-defaults for the image. This matches Debian's linux-image-amd64. Per-line metas are unchanged and remain an opt-in series pin. Installed by hand, they keep their kernel out of autoremoval. - docs: config-architecture.md describes the new shape and why the umbrella must not go via the per-line meta. pinning.md documents the one-time `apt autoremove` (or `apt-mark manual`) for installs from v7.2.8-hardened1 or earlier, which carry an auto-installed per-line meta. recovery.md covers the error itself. Verified with dummy packages under apt 3.0.3 in debian:trixie. The old shape reproduces the error verbatim. The new shape removes the old kernel cleanly across an advance. A hand-pinned per-line meta keeps its kernel. An install migrated from the old shape still fails at the next advance unless the stale meta is autoremoved once, hence the docs. Plain `apt upgrade` never hits this, since it skips kernel autoremoval. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>