Skip to content
Documentation
View as Markdown

How to patch and update a Quake AI VM

How-to · Updated Sep 2026

Coming from another cloud?

▸AWS·SSM Patch Manager

This Quake AI feature maps to AWS’s SSM Patch Manager.

▸Azure·Update Management

This Quake AI feature maps to Azure’s Update Management.

▸DigitalOcean·Droplet Updates

This Quake AI feature maps to DigitalOcean’s Droplet Updates.

▸Google Cloud·OS Patch Management

This Quake AI feature maps to Google Cloud’s OS Patch Management.

Before this
Instances

How to patch and update a Quake AI VM

Patch the guest operating system manually or on a schedule. Plan reboots for kernel updates, and create a Quake AI snapshot as a rollback point before a major upgrade.

Start from a running Linux VM with SSH access. If you still need to lock down a fresh instance, follow How to harden a Quake AI VM first.

Prerequisites

Windows: CLI examples use bash. Set up a Linux CLI environment on Windows before proceeding.

  • A running Linux instance with SSH access and a user that can run sudo
  • Enough disk space for package downloads (check with df -h before large upgrades)

Manual patching#

Review pending updates before you install them. On production VMs, run upgrades during a maintenance window and monitor application health after installation.

Refresh the package index and list upgrades:

bash
sudo apt update
apt list --upgradable

Apply pending upgrades:

bash
sudo apt full-upgrade

For a smaller change set, upgrade individual packages:

bash
sudo apt install PACKAGE_NAME

Remove dependencies that no installed package needs:

bash
sudo apt autoremove

Automatic security updates#

Configure the guest operating system to install security patches on a schedule. The hardening how-to walks through a baseline unattended-upgrades or dnf-automatic setup. This section covers scope, logs, and tuning.

Security-only origins are the default in /etc/apt/apt.conf.d/50unattended-upgrades. Confirm the file limits upgrades to security suites:

bash
grep -E 'origin|label' /etc/apt/apt.conf.d/50unattended-upgrades

To include normal updates, add the distribution suite you run (for example, jammy-updates) to the Allowed-Origins block. On production VMs, keep the security-only scope unless your maintenance policy covers broader automatic changes.

Enable periodic runs in /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Read the log after an unattended run:

bash
sudo grep -i upgrade /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

Kernel updates and reboots#

Kernel packages often require a reboot before the new kernel runs. Plan reboots during a maintenance window.

Check whether a reboot is pending:

bash
test -f /var/run/reboot-required && cat /var/run/reboot-required

List processes still using old libraries:

bash
sudo apt install -y debian-goodies
checkrestart

Reboot when you are ready:

bash
sudo reboot

Canonical offers kernel live patching for supported Ubuntu releases through an Ubuntu Pro subscription. Check its status:

bash
sudo pro status

Snapshot before a major upgrade#

Before a distribution upgrade, a large dependency change, or an update with no direct rollback path, capture an instance snapshot. The Image service stores snapshots as Glance images. You can use the image to launch a replacement instance if the upgrade fails.

Follow How to create an instance snapshot. Name the snapshot with the date and purpose (for example pre-dist-upgrade-2026-06-19).

For a file-level backup workflow alongside a snapshot, see Automated backups with object storage. For platform snapshot recovery and offsite copy patterns, see How to back up and restore a Quake AI VM.

To roll back after a failed upgrade:

  1. Launch a new instance from the snapshot image.
  2. Reattach or restore data volumes if your workload stored state on separate volumes.
  3. Update DNS, reverse-proxy targets, or external edge origins to point at the recovered instance.

Verify after patching#

Confirm the VM serves traffic and core services restart cleanly.

Package versions reflect the upgrade:

bash
uname -r
apt list --installed | grep -E 'linux-image|linux-headers' | tail -5

Services you care about are active:

bash
sudo systemctl is-active SERVICE_NAME
curl -fsS http://localhost/health || true

Replace SERVICE_NAME and the health URL with your workload checks.

The VM reports its reboot state:

bash
test -f /var/run/reboot-required && echo "reboot still required" || echo "no reboot pending"

Usage Guidelines

The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.

For the full policy, see Usage Guidelines.

Last validated: 01.09.2026

Quick answers

See all Compute FAQs

See Also

Instances

Prerequisite

→

How to maintain a Quake AI VM over its lifetime

Shares: Operations, Compute

→

How to operate a running Quake AI VM

Shares: Operations, Compute

→

How to back up and restore a Quake AI VM

Shares: Snapshots, Images

→

How to create an instance snapshot

Shares: Snapshots, Images

→
Was this page helpful?