Right, let’s talk about keeping your system from turning into a digital museum exhibit. The apt update and apt upgrade dance is the most fundamental maintenance task you’ll perform, and most people get it about 80% right. We’re here to close that gap.

Think of your system like a giant, ever-changing recipe book for software. The recipes aren’t stored on your machine—that would be a nightmare to maintain. Instead, your system just knows where to go to get the latest versions of those recipes. Those locations are the repositories you’ve defined in /etc/apt/sources.list and /etc/apt/sources.list.d/.

When you run apt update, you’re not actually downloading any new software. You’re sending a polite shout-out to all those repositories saying, “Hey, send me your latest menu!” Your machine then downloads the latest package lists—essentially a massive index of what packages are available and their versions—and stores them locally. APT uses this local cache to figure out what it can do.

sudo apt update

You’ll see it hit all your configured repositories. If you haven’t run this in a while, it’ll download a bunch of data. If you just did it, it’ll be blazingly fast, often reporting ‘All packages are up to date.’ because your local cache is already fresh. This is why you must run apt update right before an upgrade. Running apt upgrade with a stale cache is like trying to navigate a city with a map from 1998; you’ll miss all the new roads and probably end up in a field.

What apt upgrade Actually Does (And Doesn’t Do)

Now for the main event. With your freshly downloaded index, apt upgrade gets to work.

sudo apt upgrade

This command looks at every installed package on your system, checks the new index for a newer version, and if it finds one, it plans to install it. Simple, right? Here’s the crucial bit everyone misses: upgrade will never remove a package. Its primary directive is to upgrade existing packages. If a new version of a package depends on a new library, apt will happily install that new library. But if upgrading a package requires removing another package—perhaps because of a nasty dependency conflict—apt upgrade will simply skip that package and leave it unchanged. It plays it safe.

This is why you might sometimes run update and upgrade and still see a few packages “kept back.” This isn’t a mistake; it’s apt politely telling you, “Hey, I could upgrade this, but it would require removing something you have installed. I didn’t want to make that call for you.” It’s waiting for you to say the magic word.

When apt full-upgrade is Your Friend (And Enemy)

That magic word is apt full-upgrade (you might see old-timers use apt-get dist-upgrade, which is the same thing). This command is far more powerful and, consequently, more dangerous. It has one job: make your system match the state of the new package index. To do this, it will happily remove packages that are conflicting with the upgrade process.

sudo apt full-upgrade

Let’s be direct: this is usually fine on a standard desktop or server system receiving routine security updates. But on a system where you’ve installed a lot of weird, conflicting, or third-party packages, it can propose solutions that might break things you care about. It will always, always ask for your confirmation before proceeding. Read that screen! Don’t just hammer ‘yes’ like you’re closing a pop-up ad. If it says it’s going to remove 87 packages including your favorite desktop environment, maybe hit ’n’ and figure out what went wrong first.

Best Practices from the Trenches

  1. Update First, Always: I don’t care if you ran it an hour ago. Get in the habit. sudo apt update && sudo apt upgrade is a classic combo for a reason. The && ensures the upgrade only runs if the update succeeds.

  2. Read the damn output. Before you confirm an upgrade, especially a full-upgrade, it will list what it’s going to install, upgrade, and—most importantly—remove. A removal list shouldn’t be a surprise. If it is, abort and investigate.

  3. Reboot when it asks you to. Some updates, particularly for the Linux kernel or critical system libraries, cannot be applied live. The package will often post a message telling you a restart is required. You can usually check if you need one by checking if the file /var/run/reboot-required exists.

    cat /var/run/reboot-required

  4. Hold packages you don’t want to upgrade. If a certain upgrade is consistently breaking something, you can pin it to its current version. It’s a band-aid, not a cure, but it’s a vital tool.

    sudo apt hold package-name
# To remove the hold later
sudo apt unhold package-name

The goal isn’t to be on the bleeding edge, it’s to be on the security-patched and stable edge. This two-step process is your primary tool for getting there without accidentally turning your system into a modern art installation.