# kURL: Rocky Linux Packages on RHEL Systems

**URL:** <https://community.replicated.com/t/kurl-rocky-linux-packages-on-rhel-systems/1562>\
**Category:** Uncategorized\
**Tags:** kurl\
**Created:** [August 1, 2025, 4:50pm UTC](https://community.replicated.com/t/kurl-rocky-linux-packages-on-rhel-systems/1562 "2025-08-01T16:50:39Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Evans\_Mungai](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.replicated.com/evans_mungai/32/546_2.png) [@Evans\_Mungai](https://community.replicated.com/u/Evans_Mungai)\
**Post date:** [August 1, 2025, 4:50pm UTC](https://community.replicated.com/t/kurl-rocky-linux-packages-on-rhel-systems/1562/1 "2025-08-01T16:50:39Z")

</div>

## Overview

If you’re using the kURL installer on Red Hat Enterprise Linux (RHEL) systems, there’s an important consideration you should be aware of: kURL installs Rocky Linux packages instead of native RHEL packages. This post explains why this happens, potential implications, and available solutions.

**Note:** This issue only affects RHEL 8 and earlier versions. Starting with RHEL 9, kURL no longer ships system packages at all, eliminating this concern entirely.

## Background: Why Rocky Linux Packages?

The kURL installer ([https://kurl.sh/](https://kurl.sh/)) is designed to install system packages required for Kubernetes deployments. However, due to Red Hat’s End User License Agreement (EULA), we cannot redistribute RHEL packages directly. To maintain compatibility while respecting licensing requirements, kURL ships Rocky Linux packages, which are binary-compatible with RHEL.

## The Issue

When kURL runs on RHEL systems, it installs these Rocky Linux packages. This can lead to two potential concerns:

1. **Package Origin** : Some organizations have policies requiring only vendor-approved packages on their RHEL systems

2. **OS Identification Changes** : In some cases, after installation completes, the system may begin reporting itself as Rocky Linux instead of RHEL. This occurs because certain Rocky packages can reconfigure OS identification files during installation

## Solutions Available

If Rocky Linux packages are not acceptable in a customer’s environment, you have two options:

### Option 1: Pre-install Required Packages

1. Install all required system packages before running kURL

2. Use the `skip-system-package-install` flag when running the installer

**Example:**

bash

```auto
# Pre-install packages (adjust for your specific requirements)
sudo yum install -y [required packages]

# Run kURL with skip flag
curl -sSL https://k8s.kurl.sh/[your-installer] | sudo bash -s skip-system-package-install

```

### Option 2: Migrate to Embedded Cluster

Consider migrating to Embedded Cluster ([https://docs.replicated.com/vendor/embedded-overview](https://docs.replicated.com/vendor/embedded-overview)), which:

- Uses the k0s Kubernetes distribution

- Doesn’t install any system packages

- Includes everything statically compiled into k0s and EC binaries

- Eliminates package compatibility concerns entirely

## Action Items for Vendors

1. **Communicate with your customers** about Rocky Linux packages being installed on their RHEL systems

2. **Assess** if this poses any compliance or policy issues for their environments

3. **Implement** one of the solutions above if needed

4. **Document** your chosen approach for your support team and in your install instructions for customers

## Technical Details

The OS identification change occurs because some Rocky Linux packages modify system configuration files such as:

- `/etc/os-release`

- `/etc/redhat-release`

- `/etc/system-release`

This is standard behavior for distribution packages but can cause confusion in RHEL environments where OS consistency is expected.