Skip to Content
Bash Script GuidesCentOS Stream 9 to Rocky Linux from CIQ

CentOS Stream 9 to Rocky Linux from CIQ

Overview

This guide covers migrating CentOS Stream 9 to Rocky Linux from CIQ (RLC) using the migrate2rlc.sh bash script. Unlike CentOS Stream 8, Stream 9 is an active distribution with working mirrors, so dead mirror issues do not apply here. The migration follows the standard EL9 path with Stream-specific repo and module handling.

Supported Tiers

  • rlc-pro (Pro)
  • rlc-plus (Plus)
  • rlc-96-lts (Long Term Support, requires Rocky 9.6 base after swap)

Prerequisites

  • CentOS Stream 9
  • Root access
  • Network connectivity to CIQ depot servers
  • Valid CIQ depot credentials (username and token)
  • At least 2 GB free disk space

Usage

./migrate2rlc.sh -r -t <tier> -u <username> -p <token>

Example:

./migrate2rlc.sh -r -t rlc-pro -u ciq-portal -p <token>

Migration Path

  1. detect_os() identifies OS_ID=centos, detects Stream variant, OS_MAJOR=9
  2. Script validates system requirements
  3. Disables third-party repos, takes pre-migration snapshots
  4. Handles Stream-specific repo disabling and module removal
  5. Swaps CentOS Stream packages for Rocky Linux equivalents
  6. Installs CIQ depot CLI, authenticates, enables the selected tier
  7. Runs distro-sync to pull RLC packages
  8. Installs CIQ kernel and rlc-pro-release (Pro tier) or rlc-lts96-release (LTS)
  9. Creates post-reboot recovery service
  10. Reboots into CIQ kernel

CentOS Stream 9 Specific Notes

Active Mirrors

CentOS Stream 9 mirrors are fully operational. No vault redirect or manual repo rewriting is needed before running the script.

Stream-Specific Repo Handling

The script disables CentOS Stream 9 repositories before the package swap and replaces them with Rocky Linux repos. Stream-specific repo names and paths differ from standard CentOS, and the script's pattern-based detection handles them without hardcoded repo names.

Stream-Specific Module Removal

Similar to Stream 8, the script resets DNF module streams that may conflict with Rocky Linux package versions. Stream 9 typically has fewer module conflicts than Stream 8, but the script handles them uniformly.

Standard EL9 Path

After the Stream-specific repo and module handling, the migration follows the same EL9 path as RHEL 9, Alma 9, or Oracle Linux 9:

  • Depot enrollment and tier product enablement
  • distro-sync to RLC packages
  • CIQ kernel installation
  • Post-reboot recovery service

rlc-pro-release Package

EL9 supports the rlc-pro-release package, which sets /etc/redhat-release and /etc/os-release to reflect the RLC Pro tier. The RPM content is intentional and should not be modified.

CIQ Kernel Naming

CIQ kernel packages differ by architecture:

  • x86_64: .ciq. in the version (e.g., 5.14.0-611.36.1.el9_7.ciq.3)
  • aarch64: _ciq suffix (e.g., 5.14.0-611.36.1+2.1.el9_7_ciq)

Post-Reboot Recovery

A systemd oneshot service handles post-reboot tasks: depot verification, live service monitoring (per-service and per-repo every 60 seconds, 10 minute timeout), and migration summary.

Verification

After reboot:

cat /etc/os-release depot list rpm -qa | grep ciq uname -r rpm -qa | grep centos dnf module list --enabled

All CentOS Stream packages should be replaced. No Stream-specific modules should remain. The kernel should show a CIQ version string.

Troubleshooting

Check /var/log/migrate2rlc.log for details. The script prints a migration summary with troubleshooting commands.

Common issues on CentOS Stream 9:

  • Module stream conflicts: script resets them, but check log if distro-sync fails
  • Third-party repos with Stream-specific builds: disable before migration
  • Packages built against Stream-only APIs: rare, but may need manual resolution

DISCLAIMER

The migrate2rlc script and playbook are provided "as is" without warranty of any kind, express or implied. Use of these tools is entirely at your own risk. CIQ, Inc. assumes no responsibility or liability for any data loss, system downtime, service disruption, or other damage resulting from the use or misuse of these tools. It is the user's responsibility to ensure adequate backups and testing in a non-production environment before performing any migration on production systems.