Safely Replace purge-old-kernels with an APT Dry Run

purge-old-kernels looks like a targeted kernel cleanup tool, but it is really a thin wrapper around APT autoremove. Its own manual page marks it deprecated, so you will check what it would remove before letting it touch anything. On this machine the command comes from byobu 6.11-0ubuntu1.1. Allow about ten minutes for the checks; the actual removal can take longer and may need a reboot plan.

1. Confirm the installed command

Start by checking you are using the expected executable and package version. These checks change nothing:

$ command -v purge-old-kernels
/usr/bin/purge-old-kernels
$ dpkg-query -W -f='${Package} ${Version} ${Status}\n' byobu apt
byobu 6.11-0ubuntu1.1 install ok installed
apt 2.8.3 install ok installed

The exact package version depends on your distribution release. The important point is that this is the byobu utility documented on the host, not a similarly named local script.

2. Read the command as a wrapper, not a kernel tool

• It delegates to APT. The installed script no longer has its old kernel-selection logic; it runs sudo apt-get, passes through any arguments you supply, and appends autoremove.
• Its behaviour is APT's behaviour. Not a separate kernel-only algorithm.
• Autoremove is broader than kernels. APT describes it as removing packages that were installed automatically and are no longer needed, which can catch more than old kernel packages. Do not treat the command name as a guarantee that only kernels and headers are affected.

The manpage says the utility requires administrative access and recommends using APT instead. Keep that warning in view before moving past the dry run.

3. Produce a dry-run removal plan

Pass --simulate to the wrapper. It reaches apt-get before the appended autoremove and removes nothing:

$ sudo purge-old-kernels --simulate
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.

Your counts will differ. The line containing to remove is the one to read closely. If the plan lists packages you still need, stop here and do not run the real command. Save the output if someone else needs to review it.

You can also ask APT directly, which makes the deprecated wrapper unnecessary:

$ sudo apt-get --simulate autoremove

Compare the package list from this command with the wrapper's list. A mismatch is a reason to stop and investigate arguments, APT configuration, or the command version.

4. Check the kernel you are actually running

Before any package removal, record the running kernel and the installed kernel packages. This is an observation step, not a removal step:

$ uname -r
6.8.0-XX-generic
$ dpkg-query -W -f='${binary:Package}\n' 'linux-image*' 'linux-headers*' 2>/dev/null
linux-image-6.8.0-XX-generic
linux-headers-6.8.0-XX

5. Approve the destructive step deliberately

Only after reviewing the complete dry-run output should you run:

$ sudo purge-old-kernels

Do not add a package name to this command expecting it to remove that specific package: the wrapper appends autoremove, so its whole purpose is the APT cleanup transaction. If APT asks for confirmation, read the package list again before accepting.

6. Verify the result

After the transaction, check APT's state and the kernel list. These commands remove nothing:

$ dpkg --audit
$ dpkg-query -W -f='${binary:Package} ${Version}\n' 'linux-image*' 2>/dev/null
$ uname -r
6.8.0-XX-generic

An empty dpkg --audit result means the package database reports no incomplete configuration. It does not prove every retained kernel is bootable. If the cleanup removed the kernel you are currently running, the running system may keep working until the next reboot, which is exactly why the pre-removal checks matter.

If the command reports that old kernels remain, follow the manpage's advice and investigate APT rather than repeating the deprecated wrapper blindly. Capture the simulated plan and the relevant package state before filing a bug or changing package selections.