Skip to content

Check Security Updates and the Running Kernel

A fix can be available in a repository without being installed, and a kernel can be installed without running yet. Verify those states separately rather than treating a successful APT command as the end of maintenance.

Outcome: an update record naming your OS, package source, installed/candidate versions, running kernel and verification plan. Start with the protection and recovery checklist. You need an APT-based Raspberry Pi OS or Ubuntu host, working access and a backup before administrative changes.

1. Identify the system before choosing instructions

Run these read-only commands on the host:

1
2
3
4
cat /etc/os-release
dpkg --print-architecture
uname -r
df -h / /boot /boot/firmware

Some images do not have /boot/firmware; an error for that path is a prompt to inspect your actual mount layout, not create the directory. Check the space needed on the filesystems that hold the OS and boot files.

Do not select instructions from the board model alone. Ubuntu on a Pi and Raspberry Pi OS can use different kernel packages, support policies and repositories. A container's OS label does not identify its host's kernel provider.

2. Inventory installed images without guessing which one booted

This Bash block lists common fully installed kernel-image package names. It changes nothing:

1
2
3
4
5
6
7
(
    set -o pipefail
    dpkg-query -W -f='${db:Status-Abbrev}\t${binary:Package}\t${Version}\n' |
        awk -F '\t' '$1 ~ /^ii/ && $2 ~ /^(linux-image-|raspberrypi-kernel(:|$))/ {
            print $2 "\t" $3
        }'
)

You may see an older image, a newer image and a metapackage. A metapackage tracks dependencies; its presence is not evidence that a particular image is running. An empty list may mean a custom kernel or different package naming. Stop and identify the provider instead of declaring the host updated.

For an exact image package from that list, replace the placeholder:

1
2
image_package=REPLACE_WITH_EXACT_IMAGE_PACKAGE_NAME
apt-cache policy "$image_package"

Read Installed, Candidate and the repository URLs. This information comes from the local cache, which may be stale. An installed version missing from the listed repositories needs further records to establish its origin. Do not publish private repository URLs or credentials in a support post.

3. Match the provider's advisory, not just upstream numbers

Providers may backport a correction into an older maintained branch. A lower-looking version is therefore not automatically vulnerable, and a larger version from an unrelated repository is not a safe replacement.

For a specific issue, match distribution, release, kernel family and the full package version to its provider's advisory. Ubuntu's security update documentation explains backports and package maintenance; Ubuntu Security Notices describe published fixes. CVE-reading basics explain how to interpret a dated status.

If there is no verified fixed package for your stream, say so. A candidate version alone is not proof that a named CVE was corrected. Do not switch repositories to make a version comparison turn green.

4. Review and apply updates during planned maintenance

The following commands are administrative changes. Make sure you can recover access, have sufficient space, and can tolerate a service interruption. Read the proposed installations/removals before approving. Resolve errors rather than chaining past them.

For Raspberry Pi OS, its official maintenance procedure recommends:

1
sudo apt update && sudo apt full-upgrade

For Ubuntu, follow its security update guidance and any package-specific notice:

1
sudo apt update && sudo apt upgrade

&& prevents the second command from starting if the first fails. Inspect held-back packages and dependency changes; do not remove a working kernel merely to complete the command. Follow the vendor's supported resolution if a kernel transition needs additional steps.

This maintains the configured release; it is not a Bookworm-to-Trixie migration recipe. Do not edit release names, use an untrusted kernel download, or run rpi-update as a routine security-update shortcut. Major migrations have a separate backup and cutover plan.

5. Verify activation after the required restart

A normal kernel installation leaves the running kernel in memory. Reboot only when the maintenance plan permits it and the new installation completed successfully. Save work and arrange local recovery first; no lesson here requires you to reboot a shared host immediately.

After reconnecting, rerun uname -r, the package inventory and provider check. Then test SSH, required storage and applications. A non-kernel update may instead need the affected service restarted; consult its advisory. Do not assume an installed live-patching client covers every issue or kernel.

Record:

1
2
3
4
5
6
7
8
9
OS / release / provider / date:
Relevant advisory and package family:
Installed version before and after:
Candidate / repository checked:
Running kernel before and after:
Required restart performed, or still pending:
SSH / storage / application checks:
Backup and recovery path retained:
Unresolved update or fix-status questions:

The result may legitimately be “new image installed, reboot pending.” That is more useful than an unsupported claim that everything is secure.

When something goes wrong

If package-list refresh fails, check the reported network/repository/signature error; do not disable signature verification. If a package operation fails, preserve its messages and investigate the package-manager state before rebooting blindly.

If the new kernel will not boot, use the prepared local recovery procedure and the provider's instructions. Do not improvise broad boot-file deletion over an unstable remote connection. Returning to an older affected kernel may restore availability but also restores its security exposure; record the tradeoff and plan the supported repair.

Verification and next step

Read-only OS/package/provider checks were exercised on Pi 4B, Debian 13 with Raspberry Pi kernel 6.18.50+rpt-rpi-v8 on 31 October 2026. Update and restart instructions were reviewed against vendor guidance, not executed on the shared Pi. Ubuntu was not hardware-tested.

Checkpoint: which evidence distinguishes “a fixed package exists,” “it is installed,” and “the corrected kernel is running”?

Next: practise file permissions without changing system files. Return to Security.

Donate