Linux VM Kernel Updates: Verify What Booted and Who Supplies It

Imagine you’ve updated an Ubuntu guest that runs a small API. The package manager finishes, the VM comes back after its maintenance window, and the health check turns green. Before marking the update complete, check one more thing. Which kernel is that guest actually running?

Record the boot ID and running kernel before and after maintenance. Then check how your VM gets its kernel. A VM that boots an Ubuntu package from disk needs a package-and-build check. A Krova Cube uses a provider-supplied guest kernel, so verify the provider’s restart path before reaching for the package manager. In both cases, test the workload before restoring traffic.

Start with the guest and the right advisory

The Linux Kernel Archives list upstream releases, including stable 7.3.3 on 6 November 2026. Ubuntu has its own packaged kernel versions and can carry fixes on a different version line. Use Ubuntu Security Notices for the package and flavour you actually run. Don’t compare the guest’s release string to the newest kernel.org number and assume the smaller one is missing the fix.

Run the checks over SSH in the guest OS you maintain. A container normally shares the kernel of the system it runs on, so a package list inside a container cannot tell you which kernel package the guest booted. A guest check also gives you no visibility into the provider’s underlying host kernel. If your VM uses a provider-supplied image, skip the package check below and follow that provider’s maintenance procedure.

For a disk-booted Ubuntu VM, record the package and running build

cat /etc/os-release
cat /proc/sys/kernel/random/boot_id
release=$(uname -r)
printf 'Running release: %s\n' "$release"
dpkg-query -S "/boot/vmlinuz-$release"
if [ -r /proc/version_signature ]; then cat /proc/version_signature; fi

On a typical Ubuntu guest with a packaged image under /boot, the last command identifies the owning package for the running release. Copy the package name from that output and run dpkg-query -W PACKAGE with the actual name to see its installed version. If the path doesn’t exist or there’s no package match, you may have a different image layout or a custom kernel. Use the image’s provenance and boot tooling instead of guessing. GNU uname, Linux boot ID documentation and Ubuntu’s dpkg-query manual describe the readings. On Ubuntu images that expose it, the version signature identifies the running build. Package inventory describes what’s on disk. Use the running signature where available to verify you loaded the intended build, especially when the release string is unchanged.

Before an approved reboot, write down the expected package and release for this guest. Confirm you have a recovery path appropriate to the workload and enough time to use it. For a stateful guest, check the backup and restore procedure first. Krova’s Cube backup and restore guide describes the product’s recovery workflow.

Read the outcome before bringing traffic back

• Boot ID stayed the same. Confirm you reconnected to the intended guest. If you did, verify whether the reboot actually happened.
• Boot ID changed but the guest still runs an unexpected release. Confirm the intended package was installed for the right flavour. Inspect available boot entries and any fallback before rebooting again. Don’t remove the known-good kernel while diagnosing.
• Boot ID changed and the guest runs the expected release. Check the package version against the advisory. If a package was replaced without a distinguishable release string, also verify the running build identity using the distro’s tooling. Then test a real request and any dependencies such as mounted data or network access.

For Krova Cube, verify the provider-supplied kernel

Krova supplies the Cube’s guest kernel at boot. The Ubuntu package query above does not identify that image. Krova documents a cold restart from the dashboard or API to load the current provider-supplied guest kernel. During an approved maintenance window, capture the boot ID and uname -r, use the documented restart, reconnect to the same Cube and take both readings again. The release can stay the same if the provider’s image hasn’t changed. Check the target build with the provider if a particular fix is your acceptance criterion. Krova explains the Cube kernel update path.

If you maintain several guests, start with one representative VM. Record the before and after readings alongside the workload result. That gives the next operator evidence that the intended image booted and the app worked, beyond a package manager’s success message.

This guide was prepared with AI assistance using the linked documentation. The API guest is hypothetical, and no guest was rebooted for this article.