We have all been there. You patch a server, expect a standard upgrade, and suddenly a specific package version sticks like glue while everything else updates fine. You check your repo configs, you check the metadata, and you pull your hair out because you forgot you created a pin file months ago to stop a regression. It is invisible, it is silent, and it is almost certainly buried in a subdirectory you have not touched in a year.

Why apt-mark won’t show you the whole truth

People reach for apt-mark hold by reflex, but that only covers state flags. It does not touch the policy files in /etc/apt/preferences.d/. If you used an older guide or a heavy-handed configuration management module, you probably have a text file there defining a priority of 1001 for a package version. This overrides the release version entirely. APT will just pretend the newer version doesn’t exist. It doesn’t throw a warning. It just ignores it.

grep -r 'Pin:' /etc/apt/preferences.d/

• Check files in /etc/apt/preferences.d/ for explicit Pin entries
• Run apt-cache policy <package_name> to see which file is holding the weight
• Verify if any local .deb files were forced into the state database manually

If you are working on RHEL or Fedora, the same logic applies to DNF versionlock. Checking /etc/dnf/plugins/versionlock.list is your first move before you start debugging repo metadata caches. These tools are trying to be helpful, but they store their state in plain text files that vanish from your working memory the second you stop editing them. If you suspect an upgrade path is broken, check the pins before you blow away your cache or refresh your entire repo stack.

The next time your package manager refuses to see that latest version, stop looking at the network and look at the filesystem. A quick grep in the preferences directory will save you an hour of misery every single time.