The most common failures are version mismatches, missing subscription access, disabled repositories, and package constraints that block the upgrade. Firewalld settings can also interfere if they are not adjusted, and the pre-upgrade report may surface invalid files or other issues that must be fixed first. Skipping preparation usually turns a routine upgrade into a lengthy recovery exercise.
What tends to break first in an unprepared RHEL 8 to RHEL 9 upgrade?
The first failures are usually not the operating system itself but the upgrade dependencies around it: mismatched package versions, disabled or unavailable repositories, subscription and entitlement gaps, and package conflicts that block resolution. If the system state is already inconsistent, the pre-upgrade tooling will expose those problems before the upgrade can safely proceed.
Why the pre-upgrade checks matter more than the upgrade command
RHEL 9 upgrades depend on the system being in a clean, supportable state before the process starts. The pre-upgrade report is designed to catch blockers such as unsupported packages, invalid files, repo access problems, and configuration drift that would otherwise surface mid-upgrade and leave the machine partially changed. That is why preparation is not optional housekeeping, it is part of the control path that makes the upgrade predictable.
Firewalld and related network controls can also become a hidden dependency if the environment changes during the upgrade window. Even when the package transaction is valid, local policy can interfere with package retrieval, remote management, or post-upgrade validation, so teams need to treat access and connectivity as part of the upgrade readiness check rather than an afterthought.
The practical lesson is that a successful major-version upgrade is mostly a systems hygiene exercise: confirm supportability, reconcile repositories, and remove anything that will force the resolver into a dead end. When those checks are skipped, the upgrade often fails on a narrow technical detail that is expensive to unwind once the system is already in transition.
What kinds of blockers usually surface in the pre-upgrade report?
Most blocker reports cluster into a few repeatable categories. Repository access issues mean the upgrade cannot pull the correct packages. Version mismatches mean installed components no longer line up with what the target release expects. Invalid or stray files can indicate local modifications that conflict with package ownership. Package constraints appear when the dependency graph cannot be satisfied without removing or replacing something the system still depends on.
These are not random warnings. They indicate that the current system state is not a clean base for a major-release transition. The report is valuable because it converts hidden risk into a concrete fix list, which is far better than discovering the same issue after packages have already been replaced or the system has rebooted into an incomplete state.
Preparation also matters because the upgrade process is selective, not magical. It will not fix inconsistent entitlement, broken mirrors, or unsupported customizations on your behalf. The more divergence exists between the installed state and the supported baseline, the more likely the upgrade is to stop early or require manual recovery.
How to think about the failure mode before you start the upgrade
Think of the upgrade as a controlled dependency resolution exercise, not a version jump. The system must be able to prove that it can reach the right repositories, satisfy package dependencies, and preserve a supportable configuration across the transition. If any of those assumptions are false, the upgrade will fail for reasons that are usually avoidable with pre-checks and cleanup.
That framing helps teams distinguish true blockers from cosmetic warnings. A warning about an unused package is different from a warning about a package the system still needs at boot or for remote access. Likewise, a repository notice is more serious when it affects the source of the target-release packages than when it only affects an optional channel. The right response is to classify each issue by whether it threatens package resolution, system reachability, or post-upgrade stability.
Successful upgrades usually happen when the team validates the environment first, then upgrades, then verifies services, rather than trying to discover missing prerequisites during the change window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Upgrade blockers often come from configuration drift and unsupported local changes. |
| CIS-2 — Inventory and Control of Software Assets | Version mismatches and stray packages are software asset control problems. | |
| Recommendation — Validate and standardize system configuration before attempting the major release upgrade. Inventory installed packages and remove unsupported software before the upgrade. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | A clean baseline is required to avoid upgrade drift and dependency conflicts. |
| CM-3 — Configuration Change Control | Major-version upgrades are controlled changes that need pre-change validation. | |
| SI-2 — Flaw Remediation | Package conflicts and invalid components must be remediated before proceeding. | |
| Recommendation — Compare the host against a known-good baseline before changing major OS versions. Require change review and pre-upgrade validation for all RHEL release transitions. Remediate known package and dependency issues before launching the upgrade. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The answer centers on configuration readiness and drift control before upgrade. |
| Recommendation — Ensure the target host configuration is controlled and verified before the release change. | ||
Practitioner Guidance
What to prioritise: Fix anything that prevents package resolution or supportability before you touch the upgrade command. If the pre-upgrade report shows repository, entitlement, or package-conflict issues, treat those as hard blockers rather than advisory noise.
What to verify: Confirm that the system is fully subscribed, the required repositories are enabled, and no local package or configuration drift will block dependency resolution. Also verify that firewalld or other access controls will not interfere with the validation and recovery steps you need during the maintenance window.
Practitioner takeaway: The upgrade usually fails where the system was already unhealthy, so the real work is to make the current RHEL 8 host boring before you ask it to become RHEL 9.
Related resources from NHI Mgmt Group
- What breaks when security teams try to investigate Azure alerts without collecting system behaviour and network context first?
- What breaks when teams try to enumerate Active Directory infrastructure without first identifying the domain?
- What breaks when teams rotate secrets without mapping dependencies first?
- What breaks when identity teams try to clean up Active Directory without dependency mapping?
