No — you do not need to uninstall Anaconda before upgrading Ubuntu. The distribution is deliberately self-contained: every binary, library, and environment lives under a single install prefix (typically ~/anaconda3), and none of it is managed by apt. A release upgrade rebuilds the system layer and leaves that directory alone. The only place Anaconda reaches outside its own folder is your shell configuration, and that is what deserves a little attention before you run the upgrade.
Why the installation itself is upgrade-proof
A persistent worry is that Anaconda "mucks with" the system Python. It does not. Ubuntu's /usr/bin/python3 is owned by the package manager, and the Anaconda installer never touches it. What conda changes is the resolution order inside shells it activates: a clearly marked block appended to ~/.bashrc prepends the prefix's bin directory to PATH, so typing python in an activated shell finds conda's interpreter first. That block is plain shell code that behaves identically before and after an upgrade.
Because conda bundles its own copies of Python, numerical libraries, compilers, and everything else inside its prefix, the upgraded system does not need to satisfy any of its dependencies. A newer release ships a newer glibc than the one your Anaconda build targeted, and glibc is backward compatible, so existing conda binaries keep running. This independence also means the upgrade tool has no opinion about conda: it temporarily disables third-party apt repositories during the upgrade, and conda channels are not apt repositories.
What conda deactivate actually does
conda deactivate removes conda's entries from PATH for the current shell only. It writes nothing to disk and has no memory: open a new terminal and the .bashrc block runs again, re-activating the base environment if auto_activate_base is true (the default). Deactivation is therefore a per-session courtesy, not a persistent switch.
If you want fresh shells to start without conda on PATH, turn off auto-activation:
conda config --set auto_activate_base falseNeither command is required for the upgrade to succeed, but both reduce the odds of a script quietly picking up conda's python or utilities when you did not intend it. They also make the upgrade environment more predictable, which is worth the ten seconds they cost.
A sensible pre-upgrade routine
- Record your environments so they can be rebuilt anywhere if something goes wrong later:
conda env export --from-history > envs.yml
conda list --explicit > pkg-list.txt- Close all open terminals, or run
conda deactivatein each one. Closing everything is the simpler and more reliable option. - Optionally disable base auto-activation with the
conda configcommand above. - Run the upgrade from a plain shell as usual:
do-release-upgrade. The upgrade tool operates largely independently of your interactive shell's environment, so this step is about hygiene, not survival.
After the upgrade
Expect everything to work as before. Confirm with:
conda info
which python3The first command should report your unchanged prefix; the second should return /usr/bin/python3 in any shell where conda is not active. Your environments, cached packages, and the .bashrc block all survive untouched.
If a conda operation ever complains after a major system change — rare, but occasionally seen with very old installs — bring the tooling up to date with conda update conda, or as a last resort install a fresh Miniconda into a new directory and recreate your environments from the export files you saved. In practice, the more common post-upgrade breakage involves pip install --user packages sitting in ~/.local against the old system Python, not anything conda-related.
When removal actually makes sense
Uninstalling beforehand buys you almost nothing for the upgrade itself, so reserve it for genuine reasons: you need the disk space back, the prefix was moved or renamed and is half-broken, or you simply want a clean slate. Removal is straightforward — delete the prefix directory and strip the conda initialize block from ~/.bashrc. Edge cases worth knowing about: if you installed into /opt with sudo, the same logic applies, but check for PATH edits in system-wide files such as /etc/profile.d; and if a script of your own hardcodes the anaconda path, nothing about the upgrade changes it.
Frequently Asked Questions
Is conda deactivate before the upgrade mandatory?
No. The upgrade process does not inherit your interactive shell's environment in any way that matters. It is cheap insurance against scripts resolving python unexpectedly, nothing more.
Does auto_activate_base false do anything for the upgrade?
Not directly. It only stops new shells from activating the base environment on startup. It is a convenience setting that happens to make the upgrade window tidier.
Will the release upgrade delete my conda environments?
No. Environments live inside the install prefix under your home directory, and the upgrade preserves home directory contents. Only the system layer is rebuilt.
My PATH still contains anaconda3 after upgrading. Why?
The activation block in ~/.bashrc persists across upgrades and still works. Run conda deactivate for the current shell or disable auto-activation for future ones.
Can old conda binaries break against the new release's libraries?
Rarely, thanks to glibc's backward compatibility. If you see dynamic loader errors after the upgrade, update conda itself or reinstall it fresh in a new directory and restore your environments from export files.