Stage 2 of 6 · Lab, on the Pi · about 20 minutes

Update & packages

The image you wrote in Week 2 was assembled weeks before today. First move of every admin session: refresh the package catalogue, install the fixes, clean up. Then learn to add and remove software deliberately.

Why update first

Raspberry Pi OS is built from Debian packages. Security fixes arrive as new package versions in Debian's online repositories; your system only benefits once you install them. Updating before the other steps also matters practically: today you install ufw, and installing from a stale catalogue is the classic cause of "package not found" errors.

Two catalogues, one word

An apt repository is a package server; apt update downloads its current catalogue. A Git repository is your project's history. Same word, unrelated things; today you use both.

What a package actually is, and where it comes from

A package is a .deb archive: the program's files, plus metadata that says what it is, which version it is, and, crucially, which other packages it depends on. Ask apt to show one:

$ apt show htop
Package: htop
Version: 3.4.1-5
Depends: libc6 (>= 2.34), libncursesw6 (>= 6.5), libnl-3-200 (>= 3.2.7), ...
Description: interactive processes viewer

That Depends line is why a package manager exists at all: when you install one package, apt reads its dependencies, their dependencies, and so on, and installs the whole set in a working order. When you remove software, autoremove walks the same graph backwards and drops what nothing needs any more. You never chase missing libraries by hand.

Your Pi reads two catalogues, listed in /etc/apt/sources.list and /etc/apt/sources.list.d/: Debian's own repositories (the operating system's thousands of packages) and Raspberry Pi's repository (the Pi-specific firmware, kernel and tools). Every catalogue is cryptographically signed, and apt checks the signature and its validity dates before trusting anything. That check is a real defence, packages cannot be swapped for tampered ones on the way to you, and it is exactly why a wrong clock breaks apt update: yesterday's clock makes today's valid signature look like it comes from the future.

The package system in the project's own words: Debian FAQ, basics of the package management system. The Raspberry Pi angle, including recommended commands: the Raspberry Pi OS documentation.

The apt cycle

Catalogue first, packages second, cleanup last. update changes no software; it only learns what exists. full-upgrade does the installing.

$ sudo apt update            # refresh the list of available packages
$ sudo apt full-upgrade -y   # install the newer versions
$ sudo apt autoremove -y     # remove packages nothing depends on any more

On the class network the upgrade can take several minutes. While it runs, read the key-pair idea on the next page; do not close the terminal or power off.

upgrade versus full-upgrade

Both install newer versions. Plain upgrade refuses any step that would remove a package; full-upgrade may remove one when the dependency graph demands it, for example when a package was replaced by a successor. On Raspberry Pi OS, full-upgrade is the documented choice, precisely so kernel and firmware transitions complete instead of stalling half-done.

When a kernel or firmware update lands

If the upgrade lists packages whose names start with linux- or raspi-firmware, finish with sudo reboot. The new kernel only runs after a restart; everything else takes effect immediately.

Certificate or "release file" date errors

If apt update complains about certificates or files "not valid yet", the Pi's clock is wrong, usually after weeks unpowered: the Pi has no clock battery. Check with date. On most networks time syncs itself once online; the campus network blocks public time servers, so it may not. Set it once with sudo date -s "2026-09-14 15:00" and run the update again. The lasting fix is pointing the Pi at the campus time server: Michel Paquette's clock notes show exactly that.

Read what apt tells you

$ sudo apt update
Hit:1 https://deb.debian.org/debian trixie InRelease
Get:2 https://archive.raspberrypi.com/debian trixie InRelease [39.0 kB]
Fetched 39.0 kB in 2s (19.5 kB/s)
128 packages can be upgraded. Run 'apt list --upgradable' to see them.

Hit: that catalogue has not changed since last time. Get: a fresh copy was downloaded.
The last line is the summary you care about: how many upgrades are waiting. apt list --upgradable names them.
During full-upgrade, apt prints the packages it will install, upgrade and remove, and the download size, before it starts. Read that block once instead of trusting -y blindly.

Install, inspect, remove

The same four verbs cover almost all package work. Try them on htop, a friendlier process viewer than top from last week:

$ apt search htop            # find packages by name or description (no sudo needed to look)
$ apt show htop              # description, version, size, dependencies
$ sudo apt install htop      # install it
$ htop                       # run it; quit with q
$ sudo apt remove htop       # uninstall, keeping its config files (purge removes those too)

Reinstall htop if you like it; it is genuinely useful. The package you must have for the next stages:

$ sudo apt install ufw       # the firewall you enable two stages from now

apt now, pip next week

apt installs system software, for every user, from Debian's tested catalogue. Python libraries for your own projects are installed with pip inside a virtual environment; that separation is the first topic of Week 4. Rule of thumb until then: if the whole system needs it, apt.

Quick health checks

Three commands worth running after any big upgrade, and before asking for help:

$ df -h /                    # disk space on the boot drive; watch the Use% column
$ free -h                    # memory in use versus available
$ vcgencmd get_throttled     # 0x0 means no power or heat problem (see Week 2 Troubleshoot)

A drive above roughly 90 % full makes upgrades fail in confusing ways. If yours is close, mention it to the teacher before continuing.

Checklist for this stage

sudo apt update ran without errors and reported the upgradable count
sudo apt full-upgrade -y finished; I rebooted if a linux- or firmware package was in the list
sudo apt autoremove -y ran
ufw is installed (apt show ufw finds it)
df -h / shows comfortable free space and vcgencmd get_throttled says 0x0

Check yourself

What does apt update change on your system?

Only the local copy of the package catalogues. No software is installed or upgraded; that is full-upgrade's job. That is why the two always run as a pair, in that order.

apt says a release file is "not valid yet". What is the actual problem?

The Pi's clock is behind reality, so the repository's signatures look like they come from the future. Fix the date, not apt.

When is a reboot part of the update, and why?

When the kernel or firmware was upgraded. The running kernel was loaded at boot; the new one sits on the drive until the next start. Ordinary packages take effect without rebooting.

Your teammate wants a Python library for the project. apt or pip?

pip, inside a virtual environment, starting Week 4. apt is for system software. Mixing the two on the system Python is how installations get broken.