Rocky Linux 9 (Community) to Rocky Linux from CIQ
Overview
This guide covers migrating community Rocky Linux 9 to Rocky Linux from CIQ (RLC)
using the migrate2rlc.sh bash script. Rocky 9 follows the same optimized
"community to RLC" path as Rocky 8: no package swap is needed, just depot
enrollment and distro-sync to pull CIQ packages.
The script detects community Rocky when OS_ID=rocky and no CIQ release packages
are installed, then routes into the tier change path.
Supported Tiers
rlc-pro(Pro)rlc-plus(Plus)rlc-96-lts(Long Term Support, Rocky 9.6 only)
Prerequisites
- Rocky Linux 9.x (community, not already enrolled in CIQ depot)
- Root access
- Network connectivity to CIQ depot servers
- Valid CIQ depot credentials (username and token)
- At least 2 GB free disk space
- For LTS tier: must be running Rocky 9.6 (not 9.7 or later)
Usage
./migrate2rlc.sh -r -t <tier> -u <username> -p <token>
Examples:
./migrate2rlc.sh -r -t rlc-pro -u ciq-portal -p <token>
./migrate2rlc.sh -r -t rlc-96-lts -u ciq-portal -p <token>
The -t argument requires the full tier name. Passing shorthand like pro or
plus triggers a validation error before logging is initialized, producing
misleading "Bad file descriptor" messages.
Migration Path
detect_os()identifiesOS_ID=rocky,OS_MAJOR=9- Script checks for CIQ release packages, finds none, sets
is_community_rocky=true - Routes into the tier change path
- Installs and configures the CIQ depot CLI
- Runs
depot loginanddepot enablefor the selected tier product - Writes depot repo files and runs
distro-sync - Installs CIQ kernel,
rlc-pro-release(Pro tier), orrlc-lts96-release(LTS tier) - Creates post-reboot recovery service
- Reboots into CIQ kernel
Rocky 9 Specific Notes
rlc-pro-release Package
Unlike EL8, Rocky 9 has the rlc-pro-release package available. This RPM sets
/etc/redhat-release and /etc/os-release to reflect the RLC Pro tier. The
content shipped by the RPM is intentional and should not be modified manually.
LTS Tier (rlc-96-lts)
The LTS tier is only available for Rocky 9.6. The script validates the minor
version after detect_os() and rejects 9.7 or later with a clear error message.
For LTS migrations, the script:
- Installs the depot CLI and runs
depot enable lts-9.6beforedistro-sync - Skips
write_depot_reposto avoid unversioned URLs upgrading 9.6 to 9.7 - Rewrites rocky*.repo files to use vault baseurl (Rocky 9.6 mirrors are vaulted)
- Pins releasever via
/etc/dnf/vars/releaseverand/etc/dnf/dnf.conf
CIQ Kernel Naming
CIQ kernel packages use different naming conventions by architecture:
- x86_64:
.ciq.in the version string (e.g.,5.14.0-611.36.1.el9_7.ciq.3) - aarch64:
_ciqsuffix (e.g.,5.14.0-611.36.1+2.1.el9_7_ciq)
Both architectures have CIQ kernels available in depot repos.
Edge Case Handlers
The script runs run_edge_case_handlers() before migration and
run_edge_case_restoration() after, even on the community Rocky path. These
handle immutable repo directory attributes, version-locked packages, and
third-party repo conflicts.
Post-Reboot Recovery
A systemd oneshot service handles post-reboot tasks: depot re-enrollment verification, service status checks (per-service and per-repo, every 60 seconds, 10 minute timeout), and migration summary output.
Verification
After reboot, confirm the migration:
cat /etc/os-release
depot list
rpm -qa | grep ciq
uname -r
The kernel version should contain .ciq. (x86_64) or _ciq (aarch64).
For LTS, also confirm:
cat /etc/dnf/vars/releasever
depot list | grep lts
Troubleshooting
Check /var/log/migrate2rlc.log for details. The script always prints a
migration summary with troubleshooting commands.
Common issues on Rocky 9:
- LTS on 9.7+: script rejects the migration (downgrade to 9.6 first or use Pro/Plus)
- Third-party repos with incompatible packages: disable before migration
- Stale depot repos from prior enrollment: script cleans duplicates automatically
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.