Confirm the release, enabled repositories, control-panel compatibility and available space. Back up configuration and application data, keep console access available, and reserve a reboot window for kernel changes. Major-release migration is a separate procedure.

1. Inspect dnf repolist and refresh metadata through the normal DNF workflow. Investigate unavailable or unexpected repositories before updating.
2. Review available updates and the proposed transaction, including removals, replacements and third-party packages. Keep vendor-supported module streams and application versions consistent.
3. Run the approved dnf upgrade transaction without blindly accepting unexpected dependency changes. Preserve its result and history entry.
4. Check which running services require restart and whether the installed kernel or core libraries require a reboot. Use the distribution-supported needs-restarting tooling when available, with its documented limitations.
5. Reboot during the agreed window if needed, inspect the console and verify the active kernel. Test production services and relevant panel functions before declaring completion.

On an AlmaLinux or Rocky Linux server, an administrator can list available package updates before the maintenance window. This may refresh package metadata but does not install the listed updates. Record the current kernel so you can compare it after a planned reboot.

uname -r
sudo dnf check-update
sudo dnf history list

Read the result: For dnf check-update, exit status 100 normally means updates are available; it is not the same as a failed update installation. Review kernel, database, control-panel and third-party packages against their supported update process. The history list provides context for recent transactions, not a guarantee that every application change was recorded.

Schedule application checks and any required restart before installing the reviewed set. Do not add automatic approval flags to an unfamiliar package transaction. A repository error should be resolved at its source instead of bypassing GPG checks or removing dependencies.

Ordinary configured-release updates do not replace the planning required for a major migration. Follow the distribution and control-panel supported migration path or rebuild on a fresh supported server.

Confirm the package transaction finished cleanly and the enabled repositories remain appropriate to this major release. Test database access, web requests and scheduled work. Keep the previous supported kernel available under the distribution's normal retention policy until the new one is validated.

For dependency conflicts, identify the package/repository mismatch rather than using broad removal flags automatically. A DNF history undo is not a complete server rollback and may depend on old package availability. Restore a known-good application/server backup or use a tested corrective plan when an update changes persistent data.

• Diagnosing a Linux package repository signature failure
• Investigating a failed systemd service
• Reading logs from the previous Linux boot
• Changing an AlmaLinux or Rocky Linux address with NetworkManager

• docs.rockylinux.org: Dnf Package Manager
• dnf.readthedocs.io: Command Ref