Patch a Linux VM with a recovery plan

Patch a known, disposable baseline

Use the Ubuntu OrbStack machine from the setup bite. This is a userspace package-maintenance rehearsal. A full VM also needs a guest-kernel and boot verification plan; OrbStack's shared kernel is maintained through OrbStack, so an APT operation inside a machine does not establish that kernel has been replaced.

Before changing packages, record the machine name, distribution, important service checks, available disk space, and installed package versions. Close applications using lab data. Retain a recoverable copy or export; a live database needs an application-consistent backup rather than an assumed filesystem copy.

Know what each maintenance step changes

A distribution package is a versioned set of files plus installation metadata and scripts. A configured repository publishes candidate versions. Refreshing repository metadata updates your machine's knowledge of candidates; it does not install all of them. An upgrade changes installed packages and can run maintenance scripts, restart services, or ask about modified configuration files.

Use this worked decision before the commands. Suppose Bash is installed at version A and the repository offers B. You need a record of A, a recovery copy made before changes, a preview showing the proposed move to B and its dependencies, and a post-change command/behavior check. If installed and candidate are both A, a “nothing to upgrade” result is valid. You do not need to force an artificial difference.

The recovery lab immediately after this bite gives the named stop/clone workflow. Read its baseline/copy steps before performing the real upgrade below. Use this page to understand the sequence; do not patch first and create the “before” copy afterward.

Review the maintenance proposal

Inside the disposable Ubuntu machine:

cat /etc/os-release
df -h /
dpkg-query -W -f='${Package} ${Version}\n' bash coreutils
sudo apt-get update
apt list --upgradable
apt-get --simulate upgrade

The metadata update contacts configured repositories. Inspect warnings, package changes, held-back packages, disk requirements, and any suggested restarts. If no upgrades are available, record that result; do not force a downgrade to manufacture an update.

After reviewing the proposal and recovery copy, perform the interactive upgrade:

sudo apt-get upgrade

Read the prompt and any configuration-file decisions. A package upgrade is different from a distribution release upgrade. Do not add dist-upgrade, force flags, or automatic removal just to make a held-back package disappear.

Verify and recover

Re-run version and service checks and inspect /var/log/apt/history.log. Restart affected services deliberately. For a full VM, follow the distribution's reboot guidance, reconnect through a known recovery path, and verify the running kernel and services after boot. For OrbStack, restart only the named machine when needed and report that as a machine restart, not proof of independent kernel boot.

Make verification more than a version list

Before and after the change, compare the same dpkg-query output, inspect the APT history, and read your existing ~/foundations-notes/environment.txt if you made it in setup. Confirm that you can still open a regular-user shell. Once you have the MicroBank evidence-page fixture later, its expected response becomes another check; record that check only after creating the fixture.

If a package prompt asks whether to replace a locally modified configuration, inspect the offered difference and retain the needed local configuration deliberately. If a restart is required, identify what it interrupts and how to reconnect. A clone of this stopped simple fixture can preserve its state, while a running database needs an application-aware backup process. Downgrading a package is not automatically a rollback of its data changes.

Self-check: does a successful upgrade prove a long-running process has loaded a new library? No. It may still use the old mapped code until restarted. Does starting an OrbStack machine prove that an independent guest kernel boot succeeded? No. Record the maintenance boundary you actually exercised.

Check and revise

A maintenance report needs the reviewed change, actual result, behavior checks, remaining restarts, and recovery evidence. Package-manager success alone is insufficient. Revision: baseline → recoverable copy → preview → patch → restart where needed → verify → record.

Apply this to MicroBank

Treat the disposable machine as preparation for maintaining a future MicroBank host. Record the package, expected effect, recovery route, and post-update shell/file checks. Once the local evidence-page fixture exists, also request its expected page after maintenance. Do not count these checks as an application or database upgrade; those require the selected MicroBank runtime and compatibility checks.

Keep this observation in the MicroBank readiness project.

Sources

Primary references: Ubuntu package management↗; APT upgrade behavior↗; OrbStack shared-kernel boundary↗.