On Ubuntu and Debian systems you can hold a package so that apt will not upgrade it. This is useful for packages that must stay at a fixed version, such as ones with dependency relationships that would break an application if moved forward. This article covers the commands, how holds interact with Automox patching, and what to watch for.
Where a hold fits alongside Automox exclusions
There are two layers at which a package can be excluded, and they behave differently.
- In Automox, using a Patch Except policy or by ignoring the software. This is managed centrally and is the right choice for routine scoping. The exclusion applies to the list of packages Automox sends to the package manager.
- On the device, using an apt hold. This is enforced by apt and dpkg themselves, so it applies no matter which policy runs or who runs it.
The distinction matters because excluding a package on the Automox side does not always stop it from being upgraded. If another package being upgraded depends on a newer version of the excluded package, the package manager can upgrade it anyway to satisfy that dependency. Automox invokes the native package manager, and dependency resolution is the package manager's decision. For dependency-sensitive packages that must never move, a device-side hold is the stronger control.
1. Holding a package
To prevent a package from being upgraded:
sudo apt-mark hold <package_name>
For example:
sudo apt-mark hold firefox
The package stays at its current version and is skipped by upgrades.
2. Checking packages on hold
To list everything currently held:
sudo apt-mark showhold
Older guidance often uses the following, which also works:
sudo dpkg --get-selections | grep "hold"
3. Removing a hold
To allow a package to be upgraded again:
sudo apt-mark unhold <package_name>
For example:
sudo apt-mark unhold firefox
Confirm with sudo apt-mark showhold that the package no longer appears.
4. Applying holds across multiple devices
These commands act on one device at a time. Running them by hand does not scale and leaves no record of which devices were configured. Deploy them with a Worklet instead, so the same holds are applied consistently and can be re-applied or removed later. Have the Worklet report the output of apt-mark showhold so the resulting state is visible in the activity log.
5. What to watch for
- "Kept back" is not the same as a hold. When apt reports that packages have been kept back, it is deferring an upgrade on its own, usually because applying it would require installing or removing other packages. That is a transient decision, not an instruction to leave the package alone. Only an explicit hold is a durable instruction.
- A hold does not hide the update. The newer version still exists as far as the package manager is concerned, so the update can continue to be reported as available. Seeing it listed does not mean the hold failed.
- Dependencies can still force a change. A hold is respected for direct upgrades, but complex dependency chains can produce situations where the package manager needs to move the package. Verify the installed version after a patch run on anything critical rather than assuming the hold held.
- Holds are invisible from the console. They live on the device, so document which devices have which holds. A held package is a common explanation for a device that looks persistently out of date.
- Be careful with security packages. A hold suppresses security updates for that package for as long as it is in place. Review held packages periodically rather than treating a hold as permanent.