linux-check-removal is the guard dpkg calls before deleting a kernel package, and this guide gives it a safe smoke test. You will identify the running kernel and read the exit status correctly. It does not remove a kernel, select a replacement, or prove that every installed kernel is safe to delete.
Allow about ten minutes. You need a shell and the linux-base package. The examples are read-only and normally need no elevated privileges. Actual package removal is a separate, privileged operation; do not combine it with these checks until you have confirmed that a different bootable kernel is installed.
Confirm the binary and package version first. This matters because the installed package, rather than a web page for another distribution release, defines the behaviour you will see:
$ command -v linux-check-removal
/usr/bin/linux-check-removal
$ dpkg-query -W -f='${Package} ${Version}\n' linux-base
linux-base 4.5ubuntu9+24.04.2The installed command accepts exactly one argument. That argument is a kernel version string, not a Debian package version. It must match the value printed by uname -r and the version used in kernel filenames.
Checkpoint: if command -v finds nothing, stop here and install or repair linux-base through your normal package-management process. Do not copy a similarly named script into a system directory.
Read the current kernel version without changing anything:
$ uname -r
6.8.0-139-genericYour value will differ. Keep it available for comparison, but do not treat it as the version to remove. A successful check for a different version says only that this particular guard did not identify the running kernel.
The common distraction here is confusing the kernel version with the package version. For example, linux-base 4.5ubuntu9+24.04.2 is the helper package version, while 6.8.0-139-generic is a kernel version. Pass the latter to linux-check-removal.
Use an explicit version that is not the value from uname -r. This test is read-only and should return status zero:
$ linux-check-removal 6.8.0-999-example
$ printf 'exit status: %s\n' "$?"
exit status: 0The example version is deliberately illustrative. It does not need to name an installed kernel for this helper to complete. The useful result is the zero exit status, with no removal performed. In a maintainer script, that result allows the surrounding package operation to continue.
Do not use a guessed version as evidence that a real package can be removed. To decide whether a package exists, inspect the package list separately. To decide whether the machine can boot after removal, identify another installed kernel and its boot path separately.
Passing the running version is potentially dangerous during a real package removal, so this guide does not run an uninstall. You can exercise the helper's noninteractive branch safely by setting DEBIAN_FRONTEND=noninteractive for one command:
$ DEBIAN_FRONTEND=noninteractive linux-check-removal "$(uname -r)"
W: Removing the running kernel
$ printf 'exit status: %s\n' "$?"
exit status: 0The warning text above is from the installed Ubuntu package version and the exact prefix can vary with the package release. The important facts are that the running-kernel case is recognised and the command succeeds when prompts are disabled. The manual also documents the normal interactive behaviour: outside a chroot or container, a prompt normally asks for confirmation and aborting it gives a failing status.
This exception is easy to misunderstand. A zero status with DEBIAN_FRONTEND=noninteractive is not approval to remove the running kernel. It means the helper cannot stop the package operation through an interactive answer. Automation that removes kernels must provide its own policy and recovery plan.
linux-check-removal is intended for a kernel package's prerm maintainer script. It does not inspect boot-loader entries, initramfs health, disk space, signed images, running services or whether a second kernel is actually bootable.
Before any real removal, use ordinary, read-only inspection to establish the current state. The exact package names differ between distributions, so start with the package manager's installed-kernel listing rather than pasting a distribution-specific command. On Debian or Ubuntu, you can list installed packages whose names contain linux-image:
$ dpkg-query -W -f='${binary:Package}\n' 'linux-image*' 2>/dev/null
linux-image-6.8.0-139-generic
linux-image-generic
Glob matching and output depend on what is installed. Treat an empty result as a reason to investigate, not as permission to remove anything. A kernel package removal normally requires elevated privileges, often through sudo, and can affect the next reboot. Stop before that command if you cannot name a different kernel that you have good reason to boot.
There is no undo operation for removing a kernel package. Recovery normally means booting an older retained kernel from the boot menu and reinstalling the missing package, which may not be possible if the remaining boot path is broken or the machine is remote. Keep a console or out-of-band recovery route for maintenance on important systems.
In a chroot or container, the helper assumes that the environment's running kernel is independent of the package being removed, so the command quietly succeeds even when the version argument matches the host kernel. That makes sense for package image construction, but it is not evidence that removing the corresponding host kernel is safe.
If DEBIAN_FRONTEND is set to noninteractive, prompts are disabled. The installed command warns for a matching running kernel and still exits successfully. Check the environment when a script behaves unexpectedly:
$ printf 'DEBIAN_FRONTEND=%s\n' "${DEBIAN_FRONTEND-<unset>}"
DEBIAN_FRONTEND=noninteractiveUnset it only for an explicitly supervised interactive test, and do not use an interactive test inside an unattended job:
$ env -u DEBIAN_FRONTEND linux-check-removal "$(uname -r)"
That command may need a real terminal and may ask for confirmation. Do not answer yes merely to make a script continue. If the command is run without its version argument, it prints usage information and exits with status 2. A non-zero status from a maintainer script should be treated as a package-operation failure requiring investigation.
linux-base version and command path.uname -r.