When an Ubuntu release upgrade (for example 22.04 to 24.04) stops with a message about being unable to evaluate or calculate the upgrade, the real cause is nearly always a small set of installed packages that have no valid dependency path into the new release. The fix is to read the resolver output in /var/log/dist-upgrade/apt.log, purge the packages it flags as broken, and — critically after any failed attempt — verify that your APT sources still point at the old release before trying again.
Why the error blames PPAs, pins, and holds you do not have
The dialog text is a generic checklist, not a diagnosis. Before upgrading, the tool performs a dry run of a distribution upgrade against the new repositories. If even one installed package cannot be resolved to a consistent set of candidates, the entire calculation is aborted and the same warning appears, listing every cause it knows about: third-party sources, pinned packages, held packages.
That is why the usual suspects come up empty. apt-mark showhold only reports packages held with apt-mark; it cannot see pins in /etc/apt/preferences.d/, and it cannot see broken dependencies at all. The most common hidden culprits are packages left behind by a PPA you deleted months ago (removing the source does not remove its packages), manually installed .deb files, and packages that no longer exist in the target release.
Find the blockers in apt.log
Each failed attempt appends a resolver block to /var/log/dist-upgrade/apt.log. The most recent attempt is at the end of the file, so search for the resolver lines and the packages around them:
grep -n -B3 -A5 'Broken' /var/log/dist-upgrade/apt.logLook for lines like these:
Starting pkgProblemResolver with broken count: 32
Starting 2 pkgProblemResolver with broken count: 32Any count above zero means unresolved packages; the Broken: entries nearby name them. Those names are your removal candidates. Because each attempt logs a fresh block, you can also compare counts between attempts to confirm you are making progress.
For completeness, check the other mechanisms the dialog mentions, even if the message seems wrong about them:
apt-mark showhold
cat /etc/apt/preferences /etc/apt/preferences.d/* 2>/dev/null
ls /etc/apt/sources.list.d/The upgrader's own summary lives in /var/log/dist-upgrade/main.log, but the resolver output in apt.log is where the concrete package names appear.
Remove the broken packages and retry
Work through the flagged packages in small batches rather than all at once, re-running the upgrade between batches:
sudo apt purge PACKAGE1 PACKAGE2
sudo apt update
sudo apt upgrade
sudo do-release-upgradeIf you prefer a GUI, Synaptic's Quick Search finds packages fast; use "Mark for Complete Removal", apply, and repeat. Watch the broken count in a fresh apt.log after each failed attempt — it should shrink. The upgrade will only proceed once the resolver reports a broken count of zero.
To find packages inherited from a dead PPA, apt policy PACKAGE shows the origin, or use Synaptic's status filter for locally installed and obsolete packages. Removing those orphans usually clears the cascade with just a handful of purges.
After an abrupt failure, put your sources back on the old release
There is a sharp edge worth knowing about. While preparing the upgrade, the tool rewrites /etc/apt/sources.list to the new release's codename (for example noble replacing jammy, including files like ubuntu-esm-apps.list and ubuntu-esm-infra.list). On a clean abort it restores the old codename. If the upgrade window quits abruptly — which can happen after several consecutive failed attempts — the restore never runs.
The symptom is unmistakable: right after an apt update, a large number of updates from the new release suddenly appear. Do not run apt upgrade at that point. Check and repair the files first:
grep -rn 'noble' /etc/apt/sources.list /etc/apt/sources.list.d/
sudo sed -i 's/noble/jammy/g' /etc/apt/sources.list
sudo sed -i 's/noble/jammy/g' /etc/apt/sources.list.d/*.list
sudo apt updateUse the grep output to confirm which files were affected, and only rewrite the ones that should still reference the old codename. Then confirm sudo apt upgrade reports zero packages to install or upgrade. Only when the system is quiet again should you retry the upgrade.
A short pre-flight checklist
- Run
sudo apt update && sudo apt upgradeand reboot before starting, so you upgrade from a fully patched base. - Remove unused PPAs together with the packages they installed, not just the source entries.
- Empty out
/etc/apt/preferences.d/of pins you no longer need. - Back up
/etcand your data; snapshot the system if you are on a VM or a copy-on-write filesystem. - Run
do-release-upgradefrom a terminal while debugging, so progress and errors are visible live alongside the logs.
Frequently Asked Questions
The log reports a broken count of 32 — must I remove all 32 packages?
No. The count reflects a dependency cascade. The packages named at the start of the resolver block are usually the roots of the problem. Remove those first, re-run the upgrade, and recount; the number typically collapses after a few purges.
I deleted a PPA long ago — can it still break the upgrade?
Yes. Deleting the source only stops future downloads; the packages it installed remain. Check an offender with apt policy PACKAGE to see its origin, then purge it or reinstall it from the official archive.
apt-mark showhold printed nothing, so why does the message mention held packages?
The dialog lists every known cause generically whenever the trial resolution fails. Holds are only one mechanism; pins in /etc/apt/preferences.d/ and unsatisfiable dependencies produce the identical message.
Can I skip the upgrade tool and just point sources.list at the new release?
It is strongly discouraged. The release upgrader performs migration work beyond package resolution, such as removing obsolete packages and adjusting configuration. A manual source switch risks a half-migrated system that is difficult to repair.
Is it safe to retry the upgrade after repeated failures?
Yes, with one caveat: after an abrupt exit, verify that /etc/apt/sources.list and the files under /etc/apt/sources.list.d/ still reference the old release before doing anything else, as described above.