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 screen or tmux. 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:

  1. Ask if you want to proceed — read the release notes shown
  2. Download all required packages (may take 10–30 minutes depending on bandwidth)
  3. Ask how to handle modified config files (see below)
  4. Apply the changes
  5. Remove obsolete packages
  6. 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 reboot

Post-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

ProblemCauseFix
SSH disconnected during upgradesshd was restartedscreen -r upgrade to reconnect
Services not starting after rebootConfig files incompatible with new versionCheck logs: journalctl -u servicename -b
PHP version changed, app brokenUbuntu 24.04 ships PHP 8.3 instead of 8.1Update app config to use new PHP version
MySQL auth plugin changedDefault auth plugin changed in 8.0Migrate user auth: ALTER USER ... IDENTIFIED WITH mysql_native_password
Third-party repo broken post-upgradePPA has no packages for new release codenameUpdate 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