Upgrading Ubuntu 18.04 LTS to 20.04 LTS: Field Guide

Supporting aging systems past end-of-life is a risk most engineering teams can't justify. For anyone still relying on Ubuntu 18.04 “Bionic Beaver”, the window for vendor-supported updates has closed (official standard support ceased April 2023). Meanwhile, Ubuntu 20.04 “Focal Fossa” delivers security updates through April 2025. Kernel 5.4, updated toolchains, improved ZFS support, and enhanced driver compatibility are only part of the gains. There’s no benefit in waiting.

Yet, migrations can introduce service disruptions if handled poorly—lost configurations, failed boots, broken dependencies. Below is a streamlined, field-tested upgrade path for production and development systems.

Pre-Upgrade: Risk Mitigation

Before running any major release upgrade, focus on what matters—data preservation, system consistency, and roll-back planning.

1. Data Backups (Non-Negotiable)

Use cold, testable backups, not just local rsync copies. For servers:

sudo rsync -avh --progress /etc /var/www /home /mnt/backup/ubuntu18-backup-$(date +%F)/

For desktops, snapshot tools (e.g., Timeshift) can be used, but verify restore points aren’t on the root partition.

Tip: For databases, use native dump tools:

sudo mysqldump --all-databases > /mnt/backup/all_databases.sql

Verify integrity. Skipping this step isn’t an option.

2. System Update & Cleanup

An inconsistent package state causes most upgrade failures.

sudo apt update
sudo apt upgrade -y
sudo apt dist-upgrade -y
sudo apt autoremove --purge -y

Note: Unattended-upgrades or dpkg errors in /var/log/apt/term.log usually reveal broken dependencies—resolve now.

3. PPA and Third-Party Repositories

Inventory and temporarily disable all PPAs. List with:

ls /etc/apt/sources.list.d/

Move .list files out, or comment out entries—many won’t be available immediately for 20.04. For essential PPAs, confirm upstream support.

4. Disk Space: Minimum Requirements

Upgrader fails with ‘No space left on device’. Production systems often hit this due to logs, docker volumes, or tmp. Minimum 2GB on /, but 4GB+ is safer.

df -h /

Purge /var/log archives if needed.

Release Upgrade Procedure

The canonical path: do-release-upgrade. No need for ISO or PXE unless past a failed system (not covered here).

Step 1: Confirm Prerequisites

sudo apt install update-manager-core -y

Ensure /etc/update-manager/release-upgrades contains:

Prompt=lts

Step 2: Initiate the Upgrade

sudo do-release-upgrade
# For staged rollouts or if not offered, use:
sudo do-release-upgrade -d

Despite the -d (development), it will target Focal Fossa as the latest LTS.

During upgrade, expect prompts regarding obsolete packages and modified configuration files.

• If heavy customization in /etc, review diffs carefully.
• “Keep local version currently installed” is generally safest for services like SSH, but check release notes for major changes.

Example prompt:

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
The default action is to keep your current version.

Critical: If a package upgrade fails, note the package and error from the on-screen log. Proceed cautiously—do not reboot until all dependencies are resolved.

Post-Upgrade: Validation & Tuning

1. Reboot and Validate

sudo reboot

After boot, confirm:

lsb_release -a
cat /etc/os-release

2. Service Checks

Check all expected services immediately. For example:

systemctl status nginx
systemctl status postgresql
systemctl status docker

Side note: Custom startup scripts in /etc/rc.local or legacy init.d may be disabled; verify all expected daemons.

3. System Integrity

Check for critical errors in logs:

journalctl -p err -b

Scan /var/log/dist-upgrade/main.log and /var/log/syslog for repeated warnings.

4. Package Cleanup

sudo apt update
sudo apt autoremove --purge -y
sudo apt clean

Remove orphaned configs and “residual config” packages.

5. Application-Level Testing

Execute primary business workflows. For web stacks, hit application endpoints, reload reverse proxies, test scheduled jobs. For CI/CD runners, trigger a pipeline.

Troubleshooting

• In case of partial upgrade (e.g., upgrade interrupted, “dpkg was interrupted, you must manually run ‘sudo dpkg --configure -a’ to correct the problem”):

sudo dpkg --configure -a
sudo apt install -f
sudo apt --fix-broken install

• Stalled on PPA conflicts: Rename/disable .list files then rerun apt update; sometimes legacy packages (e.g., from old graphics PPAs) require explicit removal.

• Networking loss post-upgrade: check /etc/netplan/ configuration changes (netplan supersedes ifupdown in newer Ubuntu). Sometimes old config files are left in place, causing ambiguity.

Notes from Production

• Not all hardware drivers migrate cleanly. On bare metal, always test kernel/network interface changes before changing control-plane nodes in a cluster.
• In-place upgrades are officially supported only between consecutive LTS versions. Jumping from 16.04 to 20.04 directly is not reliable.
• ZFS root setups are better handled offline, with bpool snapshots.
• On some VPS (notably OpenVZ-based), do-release-upgrade is blocked—provider OS images are mandatory.

Summary

A carefully staged upgrade from Ubuntu 18.04 LTS to 20.04 LTS, using do-release-upgrade, is reliable if you:

• Run comprehensive backups
• Disable extraneous repositories
• Patch and clean the OS before proceeding
• Verify application functionality immediately after

Direct reinstalls can sometimes be faster for heavily customized or neglected systems, but that’s not always practical.

Most failed upgrades tracked in support channels stem from incomplete preparation or overlooked PPAs. If you’re orchestrating this on multiple nodes (e.g., via Ansible), stagger the upgrades to avoid simultaneous outages.

Further questions? Unusual package mix? Real-world edge cases rarely fit all in one document.

No system survives neglect. Plan, backup, execute, verify.