iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The reliable way to update Linux is distribution-specific: identify the release, refresh its repository metadata, install the offered packages, then verify both the transaction and any security-advisory status. On Ubuntu, sudo apt update only downloads current package indexes; sudo apt upgrade installs applicable upgrades. Fedora, RHEL, and other DNF-based systems use a different command sequence.
A successful package update proves only that software covered by the configured repositories was handled. You must separately determine whether a security advisory remains applicable and whether a service restart or reboot is needed before the patched code is actually running.
What “up to date” means on Linux
Linux update status has several distinct layers:
- Repository metadata is current: the package manager successfully fetched indexes and advisory data from configured repositories.
- Packages are upgraded: the installation transaction changed packages on disk.
- No applicable security advisories are reported: the distribution’s advisory metadata does not identify a remaining issue for the installed packages and enabled repositories.
- Patched code is active: affected services have been restarted, and a new kernel has been booted if one was installed.
These are not interchangeable. Refreshing indexes does not install packages, and an upgraded library can remain unused by a running process until that process is reloaded. Results also exclude software outside the package manager’s configured repositories, such as many vendor-installed applications, container images, and packages installed from unrelated third-party sources.
Free tools Windows power users keep installed
One-click scans. No signup required.
1. Identify your distribution and release
Commands, repository policies, advisory formats, and restart behavior depend on the distribution and major release. Start by reading the operating-system identification file:
#1 Best Overall
cat /etc/os-releaseRecord values such as ID, NAME, and VERSION_ID. An Ubuntu system should follow Ubuntu documentation for that release; Fedora, RHEL, and downstream systems should follow their own DNF guidance. Do not combine an Ubuntu APT procedure with Fedora or RHEL commands.
Use the release information to answer three questions before changing anything:
- Which distribution and major release is installed?
- Which package manager is authoritative: APT, DNF, or another tool?
- Which repositories are enabled, and are security advisories available for them?
2. Compare the supported update workflows
| Distribution family | Refresh metadata | Install upgrades | Availability check | Security-advisory check | Transaction evidence |
|---|---|---|---|---|---|
| Ubuntu | sudo apt update |
sudo apt upgrade |
apt list --upgradable |
Use Ubuntu’s configured security origins and unattended-upgrades records; APT itself reports package availability rather than proving every vulnerability is fixed. | Review APT output and installed package versions; automatic activity is logged under /var/log/unattended-upgrades/. |
| Fedora | DNF refreshes repository data as part of its normal operation | sudo dnf upgrade |
dnf check-update |
dnf updateinfo can show advisory summaries, lists, and details where repository metadata supplies them. |
dnf history records completed transactions. |
| RHEL 9 | Use the DNF workflow documented for the installed RHEL release | sudo dnf upgrade, or a security-filtered transaction where supported |
dnf check-update |
Use RHEL’s DNF advisory data and security-update documentation; exact filters can vary with the installed DNF and enabled repositories. | dnf history and package-version queries provide transaction evidence. |
The table is a map, not a universal command recipe. Read the output and prompts for the specific release, especially on systems with pinned packages, multiple repositories, or enterprise maintenance policies.
3. Update Ubuntu safely
Refresh the package indexes
Run:
sudo apt updateAPT contacts the configured repository pockets and downloads current package-index metadata. Its output can state how many packages are eligible for upgrade. This step does not install those upgrades. Treat repository errors, signature failures, or unreachable sources as unresolved problems rather than assuming the machine is current.
See the packages that can be upgraded
apt list --upgradableThe list reflects the metadata just downloaded and the repositories currently enabled. It is useful before and after an upgrade: before, it shows the proposed changes; after, an empty result means APT has no applicable upgrades in those repositories at that moment.
Install the offered upgrades
sudo apt upgradeRead the proposed package list, removals, configuration-file prompts, and any notices about services. Confirm only when the change set is appropriate for the machine’s maintenance window. When the command finishes, keep its output as evidence that the transaction completed.
Ubuntu’s security guidance commonly presents the sequence as sudo apt update && sudo apt upgrade. Keeping the commands conceptually separate is important: the first refreshes metadata, while the second performs installation.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Understand packages that remain pending
A newer version shown by APT is not a guarantee that the next transaction will install it. Dependency relationships, package holds, and release policies can affect the result. Ubuntu also uses phased updates for some non-security updates; a package can be held temporarily while the update is released to more systems. Ubuntu states that security updates are not phased. Do not force a phased package merely because it appears in a list; first determine whether the delay is intentional and whether the release’s documentation gives a reason to intervene.
4. Update Fedora and other DNF-based systems
Check for available updates
sudo dnf check-updateThis asks DNF whether enabled repositories offer updates. The result describes repository-visible availability, not whether a later transaction is guaranteed to succeed. Save the output if you are documenting a maintenance event.
Install package upgrades
On Fedora, the documented general upgrade operation is:
sudo dnf upgradeReview the transaction summary, including packages to install, update, remove, and any dependency changes. Fedora also documents upgrading a particular installed package by supplying its installed package specification:
sudo dnf upgrade <package-installed-specs>Replace the angle-bracketed value with the package specification you intend to update; do not type the brackets literally.
RHEL 9 uses DNF as well, but repository channels, support policies, and advisory content are RHEL-specific. Keep RHEL procedures tied to the enabled RHEL repositories and the DNF version installed on that host. A Fedora command example should not be treated as proof that an identically named RHEL repository or advisory exists.
Account for dependency restrictions
DNF’s command reference cautions that an available update does not necessarily mean a subsequent upgrade transaction will install it. Dependencies, package conflicts, modularity or repository priorities, and other constraints can prevent a candidate from being selected. If DNF leaves a package unchanged, inspect the transaction output and repository configuration instead of claiming that the package is patched.
5. Verify that security patches are installed
Use advisory metadata when the distribution provides it
On DNF systems, the updateinfo command exposes advisory information supplied by repository metadata:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo dnf updateinfo summary
sudo dnf updateinfo list --security
sudo dnf updateinfo info <advisory>The exact filters and fields depend on the installed DNF version and repository content. Advisory availability filters distinguish advisories associated with newer package versions from advisories associated with versions already installed. Read the command reference for the host before interpreting a filter as a complete security inventory.
A clear advisory result means only that the current DNF metadata reports no applicable advisory under the enabled repositories and selected filter. It does not prove that every vulnerability in every application is eliminated.
Check Ubuntu’s security-update coverage
Ubuntu’s automatic-update system applies only the origins allowed by its configuration. The standard setup includes the release’s security pocket and, where applicable, Extended Security Maintenance (ESM) security origins. Adding a repository does not automatically make it an allowed unattended-upgrades source.
For a manual update, combine the APT result with installed-version and transaction evidence. For automatic security updates, inspect the unattended-upgrades log directory:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutels -l /var/log/unattended-upgrades/Ubuntu documents unattended-upgrades as performing work equivalent to refreshing package lists and upgrading packages for the configured origins. The documented configuration files are:
/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgradesReview those files to confirm which origins are allowed and how often the system is scheduled. Daily execution is the documented default for the described setup, but administrators can change the schedule and origins. A log entry demonstrates what the automatic service attempted and changed; it does not cover software installed outside those origins.
Rank #4
Use installed versions as a second line of evidence
Advisories and package lists answer different questions. An advisory identifies a security issue and affected versions; the package manager’s installed-version information shows what is actually on disk. Record the package name and installed version from the package manager’s output, then compare it with the fixed version specified by the relevant distribution advisory when that information is available.
Do not infer a universal “patched” state from a package name alone. Distribution maintainers can backport a fix without changing the upstream version string in the way a reader might expect. The distribution’s advisory and changelog conventions take precedence over comparing version numbers by eye.
6. Confirm that the transaction really changed the system
Review command output
APT and DNF print the packages selected, downloaded, unpacked, configured, and any failures. A command returning to a shell prompt is not sufficient if the output contains repository errors, skipped packages, unresolved dependencies, or a transaction that was cancelled.
Review DNF history
sudo dnf historyDNF records transactions so you can identify when updates ran and what result was recorded. Use the relevant transaction entry to inspect the package changes before declaring a maintenance window complete. History is evidence of the package-manager transaction; it is not evidence that a running service has already loaded the new libraries.
Recheck availability after installation
Run the distribution’s availability check again after the transaction. On Ubuntu, refresh metadata if the check is not based on current indexes, then use apt list --upgradable. On DNF, use dnf check-update. Interpret an empty result narrowly: no applicable updates are reported for the current metadata and configured repositories.
7. Determine whether a restart or reboot is still required
Libraries used by services
An updated library is written to disk, but a long-running process can continue using the old copy in memory. Fedora’s software-management guidance notes that software in use may keep the old version until it is reloaded. Ubuntu uses needrestart to identify affected services and present restart handling; some cases are intentionally excluded from automatic restart.
Recommended Free Tools
Follow the restart prompts and the host’s maintenance policy. Restart only the affected service when that is sufficient and safe; schedule a broader restart when multiple critical services or a maintenance framework require it. If the package manager reports that a service was not restarted, treat the update as installed but not yet active for that process.
Best Value
Kernel updates
A newly installed kernel does not replace the kernel currently running the machine. Fedora documents that kernel updates take effect after a reboot. Plan a reboot when the transaction installed a newer kernel, when the distribution’s restart assessment requests it, or when your operational policy requires rebooting after kernel security fixes.
Before rebooting a production host, verify console or out-of-band access, confirm that critical services have an approved recovery path, and choose a maintenance window. After the reboot, verify that the host returned to service and that the expected kernel is running.
8. Inspect Ubuntu unattended-upgrades without making changes
When you need to understand what automatic security maintenance would do, Ubuntu documents a dry run:
sudo unattended-upgrade -v --dry-runA dry run helps expose candidate packages, origins, and configuration problems without applying changes. It is an inspection, not proof that the next scheduled run will have identical results; repository metadata, package availability, and configuration can change.
Use the dry-run output together with:
/etc/apt/apt.conf.d/20auto-upgradesfor periodic-update settings./etc/apt/apt.conf.d/50unattended-upgradesfor allowed origins and related policy./var/log/unattended-upgrades/for recorded automatic activity.
Confirm the release and local configuration before relying on a daily schedule or assuming that every enabled repository receives unattended security updates.
9. Troubleshoot common verification failures
“The update command ran, but packages are still listed as upgradable”
- Refresh metadata again and check whether the repository returned errors.
- Inspect the transaction summary for packages held back by dependencies or policy.
- On Ubuntu, determine whether a non-security package is in a phased rollout; waiting may be the intended behavior.
- On DNF, inspect dependency and repository messages and use
dnf historyto confirm what was actually installed.
“No security advisories are shown”
- Confirm that advisory metadata is available for the distribution and enabled repositories.
- Check that the security repository or origin is enabled and, for Ubuntu automatic updates, explicitly allowed.
- Verify that the command’s filter distinguishes installed-version advisories from advisories for newer available versions.
- Do not convert an empty advisory result into a claim that third-party applications, containers, or unconfigured repositories are vulnerability-free.
“The update failed because a repository is unreachable or invalid”
Stop and correct the repository, network, certificate, or signing problem before trusting the package list. A partial metadata refresh can leave the machine with an incomplete view of available updates. After correction, rerun the refresh, review the full output, and then perform the installation transaction.
“The package is updated, but the service still behaves as before”
Check whether the service was restarted and whether it loads the changed library only at startup. Follow the package manager’s restart notice or needrestart assessment, then validate service health after the approved restart. If a kernel was updated, reboot and verify the host afterward.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches10. A repeatable verification checklist
- Read
/etc/os-releaseand record the distribution and release. - Use that release’s official package-manager workflow; do not mix APT and DNF instructions.
- Refresh repository metadata and resolve any errors.
- List available upgrades before installation.
- Install the upgrades and review the complete transaction output.
- Recheck available updates after installation.
- Use DNF
updateinfoor Ubuntu’s configured security-update records where advisory metadata is supported. - Confirm the relevant transaction history and installed package versions.
- Read restart notices, restart affected services when policy allows, and reboot for a kernel update when required.
- State the scope of the result: current configured repositories and package-managed software, not every program on the machine.
If every step is clean, you can accurately report that the configured package sources show no remaining applicable updates, the recorded transaction completed, and any required service restart or reboot was performed. That is a defensible Linux patch verification result without overstating what the package manager can know.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
