Confirm the Ubuntu release is supported and record enabled repositories. Check application and control-panel compatibility, available disk space and a recoverable backup. Arrange a maintenance window for services that may restart and console access for a kernel reboot.

1. Review current security notices and pending packages. Run sudo apt update and inspect repository errors before considering the package list trustworthy.
2. Review the proposed upgrade and any held packages or configuration-file prompts. Test high-impact changes against a representative staging system when available.
3. Install the approved updates through the normal package workflow, keeping the transaction output. Do not kill the package manager or delete its lock files while another legitimate update is active.
4. Review service restarts and the system's reboot-required indication. Schedule a controlled reboot when needed, preserving a working console and recovery kernel option.
5. Afterward, verify the active kernel and important services, then test the application through its normal external endpoint. Review unattended-upgrades settings so future behavior matches the operational plan.

On Ubuntu Server, inspect the proposed package transaction without installing it. Run this after the package lists have been refreshed through your normal update workflow. The simulation reflects those lists, not necessarily packages published after the last refresh.

sudo apt-get --simulate upgrade
apt-mark showhold
uname -r

Read the result: Review packages marked for upgrade and any packages kept back. A held package may reflect a deliberate vendor requirement. Compare the running kernel with the kernel package transaction when preparing a restart plan. A successful simulation checks the proposed package actions but does not test your website or database.

Schedule the actual installation using your managed update policy, then check services and applications. Do not assume every update requires a reboot or that none do. Keep a tested recovery route for the affected stack, especially when third-party repositories or a control panel manage part of it.

No. Routine package updates within the configured release are separate from an operating-system release upgrade, which needs its own supported path, compatibility review and recovery plan.

Confirm package metadata refreshes without error, intended updates are installed and no interrupted configuration remains. Check application login, database connectivity and scheduled tasks. Record reboot completion separately from package installation.

If a package fails, inspect the exact transaction and dependency error before running repair commands. For a configuration prompt, compare changes rather than blindly replacing local settings. A phased non-security update can be intentionally delayed; security updates follow their own delivery policy. Avoid disabling signature checks or permanently holding all updates to suppress one issue.

• Diagnosing a Linux package repository signature failure
• Investigating a failed systemd service
• Reading logs from the previous Linux boot
• Changing Ubuntu server networking with Netplan safely

• Ubuntu: Automatic Updates
• documentation.ubuntu.com: Security Updates
• Ubuntu: About Apt Upgrade And Phased Updates

• APT simulation and package operations