Recovering Ubuntu Boot Space Without Removing Your Recovery Path

When /boot fills up, patching can fail at exactly the point when a system most needs a security update. Removing old kernels may be necessary, but the real objective is not to reclaim every possible megabyte. It is to restore enough capacity without eliminating the path back to a known-good boot.

This is a small maintenance task with a useful operating principle behind it: optimize for recoverability before efficiency.

Establish what is running

Start by recording the active kernel and the available space:

uname -r
df -h /boot /

Do not remove the running kernel. I also retain at least one previously booted, known-good kernel until the new kernel has survived a reboot and basic service validation.

List the installed image packages:

dpkg-query -W 'linux-image-*' 2>/dev/null

Package names and retention behavior vary by Ubuntu release and by how kernels were installed. That is one reason I prefer APT’s dependency model over a handcrafted pipeline that guesses which version is safe to purge.

Preview before changing the system

Ask APT what it considers removable:

sudo apt-get --simulate autoremove --purge

Review the complete removal set. Confirm that it excludes:

• The output of uname -r
• The kernel you intend to keep as a fallback
• Bootloader, storage, encryption, or other packages the host requires

If the list is not obviously safe, stop. A full filesystem is inconvenient; an unbootable remote server is an incident.

Remove only after review

When the simulation is acceptable:

sudo apt-get autoremove --purge
sudo apt-get clean

Then confirm the result:

df -h /boot /
dpkg-query -W 'linux-image-*' 2>/dev/null

The Ubuntu community documents apt-get autoremove --purge as the routine cleanup path and notes that APT normally retains fallback kernels. The current Ubuntu Server documentation also emphasizes reviewing an autoremove transaction because dependency removal can have broader effects than expected.

Lessons learned and verification

Cleanup is not complete until the host has rebooted successfully into the intended kernel and its critical services have been checked. For remote systems, verify console or out-of-band access before rebooting.

If old kernels repeatedly exhaust the filesystem, treat that as a reliability problem rather than a recurring manual chore. Review unattended-upgrade policy, partition sizing, monitoring thresholds, and alert ownership. A safe cleanup restores service; a durable control prevents the same failure from returning.

The habit I carry into larger maintenance work is simple: protect recovery before reclaiming capacity. The standalone ESXi patching runbook follows the same sequence—record the starting state, preserve a known-good path, preview the change, and test the service after reboot.

One successful cleanup does not show that the problem is fixed. Watch the next patch cycles. /boot should retain enough headroom, updates should complete without space failures, a known-good fallback should remain until validation, and alerts should reach an owner before the filesystem becomes an incident.

Sources and disclosures

• Ubuntu community guidance for removing old kernels
• Ubuntu security guidance on removing unnecessary packages

This historical field note reflects a general Ubuntu maintenance pattern. Package retention behavior varies by release and installation method; review the complete simulated transaction and the current Ubuntu documentation before removing packages.