Module Stream Persistence Across Rocky Linux 8→9 Upgrade: Uncertain Behavior

Short answer

No — you should not assume an enabled module stream persists meaningfully across an in-place Rocky Linux 8 to 9 upgrade. The record of the enabled stream (files under /etc/dnf/modules.d/ and DNF history) physically survives the upgrade, but the stream itself usually does not, because Rocky Linux 9 repositories define a different, much smaller set of module streams. The result is stale enablement state pointing at streams that no longer exist, not a migrated configuration.

Likely explanation vs. confirmed facts

Confirmed: DNF module enablement is per-system state stored on disk, and nothing in a leapp/ELevate-style upgrade is documented to translate an EL8 stream (for example nodejs:16) into an equivalent EL9 stream. Rocky 9 also converted many formerly modular components into plain versioned packages, so a large share of EL8 streams simply have no EL9 counterpart.

Likely, but version-sensitive: leftover enablement is what causes post-upgrade dnf errors of the "module does not exist" or broken-dependency type. Exact behavior depends on the ELevate/leapp release and the specific streams in use, so treat this as the probable mechanism, not a guaranteed one — the official documentation does not specify stream-state handling across a major release, which is the core of your uncertainty.

Answers to your three questions

1. Persistence: the state file persists; the stream's meaning does not. Packages installed from the EL8 stream are replaced during the upgrade transaction by whatever the EL9 repos provide — often non-modular packages — without any explicit admin action.
2. Default stream: there is no automatic fallback selection. If the enabled stream is absent from EL9 repos, DNF keeps the stale enablement and may error until you reset it. Only after a reset does DNF fall back to the module's default stream (if the module still exists) or to plain packages.
3. Documented automatic method: none that is reliable across versions. The practical approach is manual: snapshot state before, reset and re-enable after.

Recommended procedure

Before upgrading, record the current state:

dnf module list --enabled > /root/modules-enabled-el8.txt
dnf module list --installed > /root/modules-installed-el8.txt

After the upgrade, compare and clean up:

dnf module list --enabled
dnf repolist
# for each enabled stream with no EL9 counterpart:
dnf module reset <name>
# re-enable only where an EL9 stream actually exists:
dnf module enable <name>:<stream> -y

Then surface any remaining breakage:

dnf check
dnf distro-sync

Also inspect /etc/dnf/modules.d/ for leftover enablement files, especially if you use third-party repos that define their own modules — orphaned state from those is a common source of confusing dependency errors.

Verification and caveats

Because leapp actor logic changes between ELevate releases and outcomes differ by minor version, test the full path on a clone or snapshot of the actual system first. For reproducible builds, do not rely on stream state surviving at all: pin the exact package versions you need post-upgrade (via /root/modules-enabled-el8.txt as a reference) and re-establish streams explicitly. If you can share the output of dnf module list --enabled from the EL8 system, the reset/re-enable plan can be made stream-specific rather than generic.