Upgrading Ubuntu Versions
Upgrading Ubuntu Server from 20.04 to 22.04 or from 22.04 to 24.04 is a major operation that takes 30–90 minutes, may restart critical services, and can break applications that depend on specific package versions. On a production server, this requires a maintenance window, a snapshot, and careful post-upgrade verification. This article walks through the full process.
Before you upgrade
This pre-upgrade checklist prevents the most common problems:
# 1. Check current version
lsb_release -a
# 2. Ensure current release is fully updated
sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y
# 3. Check for held packages (they may cause upgrade conflicts)
apt-mark showhold
# 4. List third-party PPAs that may break during upgrade
grep -r "^deb" /etc/apt/sources.list.d/
# 5. Disable all third-party PPAs before upgrading
# (Re-enable after upgrade if still needed)
for f in /etc/apt/sources.list.d/*.list; do sudo mv "$f" "$f.disabled"; done
# 6. Take a VM snapshot BEFORE starting the upgrade
# (In cloud: create an AMI/disk snapshot from your cloud console)
# 7. Open a screen session (SSH disconnection cannot abort it)
screen -S upgrade
⚠️ WARNING: If your SSH session disconnects mid-upgrade, the upgrade process continues but you cannot monitor or interact with it. Always run upgrades inside
screenortmux. If not installed:sudo apt install screen. To reconnect after a disconnect:screen -r upgrade.
Check available upgrades
# Check if a new release is available (LTS to LTS only)
sudo do-release-upgrade -c
Example output when upgrade is available
Checking for a new Ubuntu release
New release '24.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
# Check for any release (including non-LTS)
sudo do-release-upgrade -c -d
By default, do-release-upgrade only offers LTS-to-LTS upgrades. This is the safe behaviour for servers. To upgrade a non-LTS to the next release, use -d.
Run the upgrade
# Run the upgrade (must be inside screen or tmux first)
sudo do-release-upgrade
The upgrade process will:
- Ask if you want to proceed — read the release notes shown
- Download all required packages (may take 10–30 minutes depending on bandwidth)
- Ask how to handle modified config files (see below)
- Apply the changes
- Remove obsolete packages
- Ask to reboot
The most important decision during the upgrade is config file handling:
Configuration file '/etc/ssh/sshd_config'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
For critical config files like sshd_config: press D to see the diff, then decide. For most files, keeping your version (N) is safer unless the diff shows a security-relevant change.
What happens during the upgrade
do-release-upgrade
│
├── Update sources.list to new release (jammy → noble)
├── apt update (new package index)
├── Download all package upgrades
├── Upgrade packages (services may restart here)
│ ├── nginx restarted
│ ├── mysql restarted
│ └── sshd restarted (your SSH session may reconnect)
├── Remove obsolete packages
└── Prompt to rebootPost-upgrade checks
# After reboot, verify the new version
lsb_release -a
uname -r
# Check for failed services
systemctl --failed
# Check that critical services are running
systemctl status nginx mysql ssh
# Check application logs for errors
journalctl -b -p err --no-pager | head -30
# Re-enable your third-party PPAs
# (You need the PPA version for the new release, e.g., noble not jammy)
# Check if the PPA supports the new codename before re-enabling
# Check for obsolete packages left after upgrade
sudo apt autoremove
# Check for packages in broken state
dpkg -l | grep -v "^ii" | grep -v "^rc" | grep -v "^|" | grep -v "^+" | grep -v "Desired"
Common upgrade problems
| Problem | Cause | Fix |
|---|---|---|
| SSH disconnected during upgrade | sshd was restarted | screen -r upgrade to reconnect |
| Services not starting after reboot | Config files incompatible with new version | Check logs: journalctl -u servicename -b |
| PHP version changed, app broken | Ubuntu 24.04 ships PHP 8.3 instead of 8.1 | Update app config to use new PHP version |
| MySQL auth plugin changed | Default auth plugin changed in 8.0 | Migrate user auth: ALTER USER ... IDENTIFIED WITH mysql_native_password |
| Third-party repo broken post-upgrade | PPA has no packages for new release codename | Update the PPA URL to the new codename or remove the PPA |
Conclusion
Ubuntu release upgrades require preparation: take a snapshot, update the current release fully, disable PPAs, and run inside screen. The upgrade tool handles most of the work, but the post-upgrade phase — checking failed services, reviewing log errors, and re-enabling PPAs with the correct codename — is where problems surface. Always verify application functionality after the reboot before declaring the upgrade successful.
FAQ
Is Upgrading Ubuntu Versions important for Ubuntu administrators?+
Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.
Should I practice this on a live server?+
Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.
What should I do after reading this article?+
Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.
Need help with Ubuntu administration?
Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.
Hire Me for Support