Managing system updates with dnf update and yum update
Linux package maintenance is routine work for Australian administrators, whether they maintain RHEL application servers, CentOS Stream build hosts or Fedora workstations. On modern releases, dnf update performs the transaction, while yum update remains useful for older scripts and established runbooks.
The difference is mostly historical. On RHEL 8 and 9, and many CentOS Stream installations, yum is a compatibility link to DNF. RHEL 7 retains the original implementation, while recent Fedora releases favour DNF and may omit yum entirely.
A sound procedure protects services as much as packages. Check the running kernel, repository access, disk space and backup coverage first, then review what the transaction will change. During an arvo maintenance window in Sydney, that sequence matters more than firing off a command and walking away.
The same discipline applies in Melbourne and Brisbane, including daylight-saving changes that shift scheduled jobs. Teams operating a mixed estate should record each distribution version rather than assuming one update workflow covers every machine.
Choosing the right package manager
Start by identifying the distribution rather than the command you remember. cat /etc/os-release, dnf --version, and readlink -f "$(command -v yum)" reveal whether the host uses DNF4, DNF5, or the legacy yum implementation. The readlink result may be empty if yum is absent.
Then confirm the available operations with dnf --help and man dnf. DNF handles dependency resolution, downloads RPM packages, and records transactions in its history. Plugin options can differ between DNF4 and DNF5, so a command copied from another Australian server fleet may need adjusting.
Preparing a safe update window
Before changing packages, capture uname -r, the enabled repositories with dnf repolist --enabled, and the current package list using rpm -qa --last. Check free space under /var and /boot, and note any failed units with systemctl --failed.
Take a snapshot or tested backup of critical configuration, keeping one copy away from the production host. Where the needs-restarting plugin is available, dnf needs-restarting -r shows services still using the old kernel. Store this evidence in the change record; Hozugawa's Linux notes provide a useful secondary reference for routine maintenance.
Performing the update
Run sudo dnf update for the package upgrade, and read the proposed transaction before approving it. Pay attention to repository sources, major version changes, kernel packages, and services that may restart. On a first pass, omit automatic approval so the output remains available for peer review.
For an existing maintenance script, sudo yum update is suitable where the compatibility command is installed. It reaches the same package manager on those systems, not a separate upgrade engine. The distinction is command compatibility versus package policy; the transaction remains the authority on what changes.
| Command | What it does | Best fit |
|---|---|---|
dnf update |
Resolves dependencies and installs available package updates. | The normal patching path on DNF systems |
yum update |
Uses the compatibility entry point where yum is installed. |
Existing scripts and runbooks on modern RHEL-family hosts |
dnf upgrade |
Acts as an alias for the update operation. | Teams that prefer upgrade terminology |
dnf check-update |
Reports pending updates without changing packages. | Pre-change verification and scripted checks |
Reviewing installed changes
Use dnf history list to confirm which transaction ran, then dnf history info <ID> to inspect package changes. For scripted checks, remember that dnf check-update returns 100 when updates remain available; other non-zero statuses can indicate an error.
After the reboot, compare uname -r with the installed kernel and review systemctl --failed. Validate application endpoints rather than assuming a successful RPM transaction means a healthy service. The Linux interview questions provide useful practice for checking package, process and service state before sign-off.
Handling dependencies and repositories
Repository failures often appear as dependency errors, GPG-key warnings, or metadata timeouts. Inspect /etc/yum.repos.d/*.repo, then run dnf makecache and dnf repolist --enabled before retrying. For a large Australian fleet, an approved local mirror may reduce cross-border download delays, provided its freshness and signatures match policy.
Treat third-party repository setup scripts as production changes. They can replace configuration files, enable extra packages, or install services without warning. Review scripts first, inspect ownership and access bits using the file permissions guide, and avoid --skip-broken as a routine workaround because it can conceal an incomplete upgrade.
Recovering from failed updates
When a transaction fails, read dnf history info last and the DNF logs under /var/log, then check the affected service journal with journalctl -u <service>. Missing dependencies or stale metadata can cause failures; dnf clean all clears cached data, but use it only after diagnosing the error.
Restore from a known-good snapshot when files or services have changed beyond a simple retry. dnf history undo <transaction-ID> reverses supported package transactions, while dnf history rollback <transaction-ID> returns to an earlier point; both require dependency checks. Keep the previous kernel available and confirm the intended boot entry in GRUB before relying on a kernel rollback.
Building a repeatable update routine
Put the approved command, repository policy, maintenance window and rollback owner in the change record. Schedule patching around Australian business hours, with daylight-saving transitions checked rather than assumed. Fedora moves quickly, RHEL follows enterprise lifecycles, and CentOS Stream tracks upstream development, so their update cadences differ.
After each cycle, archive the transaction ID, reboot state and service checks, then compare the installed package set with the baseline. A practical routine uses one tested path, such as sudo dnf update, rather than switching arbitrarily between aliases. The first scheduled action is a 30-minute trial on one non-production host, with its output and package list stored in the change register.