Updating Linux packages is not one universal command. Ubuntu and Debian use APT, Fedora uses DNF, Arch uses pacman, and openSUSE uses zypper. Running the wrong package manager—or treating a routine update like a release upgrade—can lead to confusion or an unexpected change.
The safest first step is to identify the system you’re working on, then review what the package manager plans to do before confirming.
Identify the distribution first
On most Linux systems, this prints the distribution name and version:
cat /etc/os-release
Look for fields such as ID and PRETTY_NAME. If you’re on an appliance, container image, or managed server, follow its documentation or administrator instructions rather than assuming a standard package workflow.
Use the matching package manager
| Distribution | Routine package update |
|---|---|
| Ubuntu or Debian | sudo apt update && sudo apt upgrade |
| Fedora or another DNF-based system | sudo dnf upgrade |
| Arch Linux | sudo pacman -Syu |
| openSUSE | sudo zypper refresh && sudo zypper update |
These commands update packages within the system’s existing release or rolling-release setup. They are not interchangeable, and they do not all work the same way.
Ubuntu and Debian: refresh, then upgrade
APT separates checking repository information from installing package updates:
sudo apt update
sudo apt upgrade
apt update refreshes the local package indexes. It does not install updates. apt upgrade uses those indexes to find updates for installed packages and presents the proposed changes for confirmation.
You can combine the steps with &&, which runs the second command only if the first succeeds:
sudo apt update && sudo apt upgrade
Review the package summary before accepting it, especially on a production machine. If you’re installing new software rather than updating what’s already installed, that’s a different APT task; the APT install command and its common checks cover that workflow.
APT may report that some packages were kept back. Don’t reach for apt full-upgrade automatically: it can remove installed packages to resolve dependency changes. Inspect its proposed actions before confirming.
Fedora: use DNF
On Fedora and other systems that use DNF, run:
sudo dnf upgrade
DNF also accepts update as an alias. It applies available package updates from the configured repositories. For more DNF-specific details, see this guide to DNF updates and the update/upgrade naming.
Arch Linux: upgrade as a whole
For Arch Linux, the routine command is:
sudo pacman -Syu
This synchronizes package databases and performs a full system upgrade. Avoid refreshing package databases with pacman -Sy and then leaving installed packages out of sync; Arch advises against partial upgrades.
openSUSE: refresh metadata, then update
On openSUSE, the usual sequence is:
sudo zypper refresh
sudo zypper update
Repository configuration and the appropriate workflow can vary by openSUSE edition, so read the proposed actions and use the repositories configured for your system.
Routine updates are not release upgrades
A package update keeps software current within the release you’re already using. Moving from one major Ubuntu, Debian, or Fedora release to another is a separate process with its own prerequisites and steps.
Don’t treat apt upgrade, dnf upgrade, or a similar routine command as a universal operating-system upgrade procedure. Follow instructions for the specific source and target releases when planning a version change.
Updating a remote server safely
Package managers use administrator privileges, which is why these commands start with sudo. They may ask for your account password, request confirmation, or show packages that will be installed, upgraded, or removed. Pause and read that summary before proceeding.
A reboot is not needed after every update. Restart when the package manager or distribution indicates one is needed—for example, after certain kernel updates—or when your maintenance procedure requires it. Some services may also need to restart before they use updated files.
If you’re connected over SSH, plan around any service restart or reboot that might interrupt your session. Make sure you know how you’ll reconnect before starting maintenance, and don’t accept a package plan you don’t understand just to get through the prompt.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)