Twice in the last few months, a tool sysadmins assumed would always be there vanished from Ubuntu's minimal cloud images. First curl disappeared in August. Then xxd, the hex-viewer CLI, went missing from Ubuntu 26.04 LTS's minimal cloud images. Both times, the cause was the same: Canonical dropped its pollinate tool, which generated boot-time randomness, and that single change rippled through the dependency chain, taking other packages with it.
Canonical restored both curl and xxd to the 26.04 minimal images, saying it didn't want to "regress people that got used to rely on it being present." But xxd's reprieve is temporary. Canonical has already confirmed it's intentionally removing xxd from the 26.10 minimal images, even though the package stays available in the archive via apt.
If you build or maintain server images, containers, or VM templates, this is your problem now, not a curiosity. Headless systems don't show you a missing icon or a broken menu item. You find out a tool is gone when a script fails at 3 a.m. Here's how to check what you're actually running, and how to stop assuming.
Step 1: Check whether specific packages are installed right now
Before you can fix anything, find out what's actually on your image. Don't guess based on what used to ship by default. Verify it directly on the running system.
Run this sequence on your current minimal cloud image or container:
- Check if the binary exists on the PATH:
which curl xxd— if either returns nothing, the binary isn't there. - Confirm package installation status with dpkg:
dpkg -s curl xxd 2>&1 | grep -E "Package|not installed"— this tells you definitively whether apt's package database considers it installed. - Cross-check with apt's own listing:
apt list --installed 2>/dev/null | grep -E "curl|xxd"— useful because dpkg and apt occasionally disagree during partial installs. - For a broader sweep, script it against a list of tools you rely on:
for pkg in curl xxd wget vim-tiny netcat-openbsd; do dpkg -s "$pkg" >/dev/null 2>&1 && echo "$pkg: present" || echo "$pkg: MISSING"; done
Run this against every image variant you deploy: the base cloud image, your Dockerfile's final stage, and any golden VM template built with Packer. A tool present in one might be absent in another, especially if they were built from different base image snapshots.
Step 2: Understand why these removals happen silently
The curl and xxd disappearances weren't deliberate trims of "nice to have" tools. They were side effects. Canonical removed pollinate, a boot-time entropy helper, and packages that depended on it lost their reason to be pulled in by the dependency resolver. This pairs well with perf script's python overhaul: what changes for you explained.
This matters because the next silent removal probably won't be announced as "we're removing curl." It'll be an unrelated changelog entry about some low-level dependency, and your monitoring tool, backup script, or CI pipeline will just start failing without a clear signal why. Minimal cloud images are built to be minimal by design, so Canonical has less incentive to preserve convenience tools that aren't strictly required for boot.
There's also a distinction worth understanding: a package missing from the image isn't the same as a package missing from the archive. xxd was never on the initial 26.04 minimal image, but it was still installable via apt install xxd the whole time. That's a very different failure mode from a package being deprecated or dropped from Ubuntu's repositories entirely. One is an image-composition decision; the other is an availability problem. Your audit needs to check both: is it installed now, and if not, is it still fetchable from your configured apt sources?
Step 3: Pin required packages explicitly instead of relying on image defaults
Once you know what's missing, or what might go missing next, stop trusting the base image's package set. Declare your dependencies explicitly in whatever tool builds your image.
For a Dockerfile, add an explicit install layer rather than assuming the base image carries what you need:
FROM ubuntu:26.04
RUN apt-get update && apt-get install -y --no-install-recommends \
curl \
xxd \
ca-certificates \
netcat-openbsd \
&& rm -rf /var/lib/apt/lists/*
For cloud-init, use the packages module in your user-data so the instance installs your required tools on first boot regardless of what the image shipped with: We cover related ground in our guide to avx-512 xor_gen: check raid5/6 support in linux 7.4.
#cloud-config
package_update: true
packages:
- curl
- xxd
- vim-tiny
- netcat-openbsd
For Packer, add a shell provisioner step in your build template that runs before you bake the image, so the tools are already present in the artifact rather than installed at runtime:
provisioner "shell" {
inline = [
"sudo apt-get update",
"sudo apt-get install -y curl xxd ca-certificates netcat-openbsd"
]
}
The principle is the same across all three: treat "assumed present" tools as explicit dependencies in your build pipeline, not defaults inherited from the base image. If Canonical prunes another dependency chain next release, your build still installs what you need because you're not relying on it being there by accident.
Step 4: Recover a package that turns out to be missing
If your audit from Step 1 turns up a gap on a live system, the fix is usually straightforward, assuming you have apt access and outbound connectivity to Ubuntu's archive.
Run sudo apt-get update first to refresh the package index, then sudo apt-get install -y xxd (substitute the package name you're missing). Once it completes, verify the fix worked by rerunning the checks from Step 1: which xxd should return a path, and dpkg -s xxd should report "Status: install ok installed."
Also read: wine vs wine-staging: which one should gamers use?
One caveat worth flagging for locked-down environments: these minimal cloud images are frequently deployed where apt access is restricted for security reasons. If you can't SSH in and run apt install on demand, live recovery isn't an option, which makes the Step 3 pinning strategy non-negotiable rather than a nice-to-have.
If apt reports the package can't be found at all, check your sources list with apt-cache policy xxd to confirm which repositories are configured and whether the package still exists in Ubuntu's archive for your release. That distinguishes a local configuration problem from an actual archive-level removal, which is rarer but has happened for other packages during major Ubuntu transitions.
What to expect next
Run the Step 1 audit against your fleet's images now, not after something breaks. Canonical has already signaled that xxd's removal from 26.10 minimal images is intentional, so treat the 26.04 restoration as a temporary window, not a guarantee. Bake your dependency list into your Dockerfile, cloud-init config, or Packer template once, and future dependency-chain prunes become a non-event instead of an incident.
