Establish a patching baseline

Outcome

The Ubuntu host has a repeatable security-update routine and a small maintenance log. You will distinguish OS package updates from application or container updates, which need their own schedule.

Before you start

Have a working local login and SSH recovery path from guide 06. Use a short maintenance window for the first run. If the lab already serves anyone else, tell them it may restart. Have a current backup before patching a host containing valuable data. This guide assumes Ubuntu Server 26.04.1 LTS; Canonical's documentation is maintained for the latest LTS, so recheck changes when the release changes.

Steps

1. Record the baseline. Run cat /etc/os-release, uname -r, apt list --upgradable, and systemctl --failed. Save the date and observations in a private change log. Avoid copying package output that contains internal repository credentials.
2. Update package lists and inspect changes. Run sudo apt update then sudo apt list --upgradable. If the packages and origin are expected, run sudo apt upgrade. Read any prompts. Do not blindly approve removal or a distribution upgrade as part of routine patching.
3. Check unattended updates. Canonical says unattended-upgrades is installed and daily security updates are enabled by default after installation. Check the package with dpkg -s unattended-upgrades and inspect /etc/apt/apt.conf.d/20auto-upgrades for its cadence. If it is absent, use sudo apt install unattended-upgrades and follow Canonical's configuration guide. Record what actually exists on your machine; do not infer it from documentation alone.
4. Review restart behavior. Canonical notes that from Ubuntu 24.04 LTS, needrestart can restart affected services during unattended updates. Check /var/run/reboot-required after upgrades and inspect service status. Plan a maintenance window for any host or application that cannot tolerate an unexpected service restart. Do not promise uninterrupted operation from automatic updates.
5. Review the evidence. Read recent entries in /var/log/unattended-upgrades/ and check systemctl --failed. Record whether updates installed, whether a reboot was required, and any failed unit. Schedule a weekly review even if the security updater runs daily.
6. Document the container boundary. apt upgrade will not automatically rebuild or validate your own container image and data. Later guides will add a separate application update, restore, and health-check routine. Keep that distinction in the maintenance log.
7. Repeat a simple functional check. After any reboot, confirm SSH, DNS, and the first service's expected response. An installed patch is not proof the lab is healthy.

Check it worked

The log has before/after OS version and date, no unexplained failed units, an observed unattended-upgrade configuration, and a clear decision on whether a reboot is pending. You can state when the next review will happen.

If it fails / rollback

If an update breaks access, use local console, review apt history and journal entries, and restore from a known-good backup or snapshot as appropriate. Do not remove arbitrary packages in frustration. If a security update is blocked by a conflicting repository, document the exact error and resolve the repository before calling the host current.

Safety and data notes

Automatic patching can restart services. A snapshot or backup is useful only if you have tested restoring it. Do not send package logs containing private repository addresses or tokens to a public forum.

Sources

• Ubuntu Server, automatic updates — default cadence, files, logs, and service restarts; checked 2026-09-29.
• Ubuntu Server, security suggestions — regular updates and least privilege; checked 2026-09-29.
• Ubuntu Server, upgrading your release — major release upgrades differ from routine package patches; checked 2026-09-29.

Next guide

Continue to guide 08, “Run a first containerized service.”