How to Upgrade to a New Distro Release

Major distribution upgrades carry real risk: a broken bootloader, incompatible third-party repositories, or a partially upgraded package set can leave a system unbootable. Done carefully, however, in-place upgrades save hours of reinstallation and preserve your configuration. This guide covers the three dominant upgrade paths — Ubuntu/Debian via do-release-upgrade, Fedora/RHEL-family via dnf system-upgrade, and Arch Linux's rolling model — with verification and recovery pointers at each stage.

Before You Upgrade Anything

These steps apply regardless of distro. Skip them and you are gambling with your data.

Back up critical data and the boot configuration

At minimum, snapshot /etc, your home directory, and the current package list so you can reconstruct a working system if the upgrade fails.

# Capture installed package list (Debian/Ubuntu)
dpkg --get-selections > ~/pkg-list-before-upgrade.txt

# Capture installed package list (Fedora/RHEL)
dnf list installed > ~/pkg-list-before-upgrade.txt

# Snapshot /etc with a datestamp
sudo tar -czf ~/etc-backup-$(date +%F).tar.gz /etc

If the machine runs in a VM or on a ZFS/Btrfs filesystem, take a snapshot now. On bare metal, a full disk image with dd or clonezilla is the gold standard.

Update fully before upgrading

The target release's upgrade tooling expects you to be at the latest point release, not just any version in the current series.

# Debian/Ubuntu
sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y

# Fedora/RHEL/Rocky
sudo dnf upgrade --refresh -y

# Arch
sudo pacman -Syu

Reboot after the full-upgrade if a new kernel was installed, then confirm you are running the current kernel before proceeding.

uname -r

Ubuntu and Debian: do-release-upgrade

Ubuntu: run the upgrade manager

Ubuntu ships update-manager-core (which provides do-release-upgrade) in all default installs. On a server without a GUI, this is the correct tool.

sudo apt install update-manager-core
sudo do-release-upgrade

By default the tool only offers upgrades to the next LTS when you are on an LTS release. To upgrade from one LTS to the next non-LTS, or to upgrade to the development release, pass the -d flag — but only do this on non-production machines.

If you are upgrading over SSH, use -f DistUpgradeViewNonInteractive or, better, run the upgrade inside a tmux or screen session so a dropped connection does not kill the process mid-upgrade.

tmux new -s upgrade
sudo do-release-upgrade

The tool will: disable third-party PPAs, rewrite /etc/apt/sources.list to point at the new release, download packages, and prompt you about configuration file conflicts. Read each prompt; accepting a maintainer's default on files like /etc/ssh/sshd_config can lock you out over SSH.

Debian: manual source list rewrite

Debian does not ship a do-release-upgrade equivalent. The supported path is editing /etc/apt/sources.list (and any files under /etc/apt/sources.list.d/) to reference the new codename, then running a full upgrade.

# Example: bookworm -> trixie
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list 2>/dev/null || true

sudo apt update
sudo apt upgrade -y
sudo apt full-upgrade -y
sudo apt autoremove -y

If apt full-upgrade wants to remove a large number of packages, inspect the list carefully before confirming. Packages that conflict with the new release are expected; losing your entire desktop environment is not.

Verify the Ubuntu/Debian upgrade

lsb_release -a
# Expected output includes the new codename and version number

sudo reboot
# After reboot:
uname -r
journalctl -b -p err

Check journalctl -b -p err after the first boot into the new release to catch any unit failures early.

Fedora: dnf system-upgrade

The dnf system-upgrade plugin is the official Fedora upgrade path and works equally well on desktops and servers. It downloads all packages first, then applies them during a dedicated offline boot phase, which significantly reduces the chance of a partially upgraded system.

Install the plugin and download packages

sudo dnf install dnf-plugin-system-upgrade -y

# Replace 40 with your target Fedora release number
sudo dnf system-upgrade download --releasever=40

If third-party repositories do not have packages for the new release yet, dnf will complain. Add --allowerasing to permit the removal of packages that cannot be upgraded, or --skip-broken if you understand which packages will be left behind. Neither flag is a substitute for checking the Fedora release notes first.

# Only use if you understand the implications
sudo dnf system-upgrade download --releasever=40 --allowerasing

Trigger the offline upgrade

sudo dnf system-upgrade reboot

The system reboots into a special upgrade environment (a Plymouth-animated offline phase). Do not power off during this step. Upgrade time depends on package count; 10–30 minutes is typical on modern hardware.

Verify the Fedora upgrade

cat /etc/fedora-release
# Fedora release 40 (Forty)

rpm -qa --last | head -20
# Shows recently installed packages; all should reflect the upgrade date

# Check for packages from the old release still installed
sudo dnf list extras

# Check for and clean leftover dnf cache
sudo dnf system-upgrade clean

Rocky Linux / RHEL: leapp

On RHEL 8→9 and Rocky 8→9, the upgrade tool is leapp, not dnf system-upgrade. Cover it briefly: install leapp-upgrade from the standard repos, run sudo leapp preupgrade to get a compatibility report, fix any inhibitors the report flags, then run sudo leapp upgrade. The process reboots twice. Full documentation lives at Red Hat's upgrade guide.

Arch Linux: Rolling Upkeep

Arch has no release versions to upgrade between. The risk model is different: neglecting updates for weeks or months, then running a large catch-up upgrade, is where breakage happens. Frequent, small updates are safer than infrequent large ones.

Regular update workflow

sudo pacman -Syu

Read the output. If pacman reports a conflict or asks you to choose between providers, make an informed choice rather than blindly pressing Enter.

Check the Arch news before large upgrades

The Arch Linux news page announces manual intervention points — situations where you must take a specific action before or after updating, such as config file migrations or package splits. Subscribe to the RSS feed or install informant (AUR) to see news items before each upgrade.

# After a large upgrade, check for .pacnew files that need merging
sudo find /etc -name '*.pacnew' 2>/dev/null

# pacdiff shows diffs between current configs and .pacnew files
sudo pacdiff

Handling a partial upgrade (Arch)

If a package installation was interrupted — power loss, killed terminal — you may have a partially upgraded system. Boot from the Arch ISO, arch-chroot into the installation, and re-run pacman -Syu to finish. Never leave Arch in a partial upgrade state; many packages depend on shared library versions that will mismatch mid-upgrade.

Troubleshooting Common Failures

• Broken bootloader after Debian/Ubuntu upgrade: Boot from a live USB, chroot into the installed system, and run sudo grub-install /dev/sdX && sudo update-grub.
• SSH lockout mid-upgrade: If you changed sshd_config during prompts, boot the rescue console from your hosting provider or local terminal and restore the original config from your /etc backup.
• dnf system-upgrade stuck at 0% download: Check DNS and proxy settings; confirm the new release repos are reachable with curl -I https://dl.fedoraproject.org.
• Third-party repos blocking the upgrade: Disable them before upgrading (sudo dnf config-manager --set-disabled <repo-id>), upgrade, then re-enable and check for updated packages.
• Arch: key ring errors after long gap between updates: Run sudo pacman -Sy archlinux-keyring before the full -Syu.