Rocky Linux Still Lacks Major Version Upgrade Support—And That’s a Problem

Rocky Linux delivers stability, but its lack of in-place upgrade support between major versions is a sore spot for users with long-term deployments.

Rocky Linux, an RHEL-based fork created by Gregory Kurtzer—the same guy who birthed CentOS—has built a strong reputation over the past few years as one of the top and most trusted alternatives to Red Hat Enterprise Linux. Just a few days ago, the distro rolled out its brand-new major release—Rocky Linux 10—based on RHEL 10, and it got me thinking about a few things.

As you know, three names primarily come up regarding free RHEL replacements: AlmaLinux, Rocky Linux, and Oracle Linux. While Oracle tends to be less popular among Linux enthusiasts—mostly for historical reasons that I think aren’t entirely fair—both Rocky and Alma have been warmly embraced by everyday Linux users and the business segment.

I’m bringing all this up because the choice often boils down to just two options—Rocky or Alma. You’ll find tons of questions about this on the internet and social media. And whichever way you slice it, both essentially offer the same thing: a free alternative to RHEL.

Sure, there are some (small) technical and (big) ideological differences, but they’re pretty much interchangeable in day-to-day use, except for one huge difference. And that’s why I’m writing this: the ability to upgrade between major versions.

Nope, this isn’t another Rocky vs. Alma piece. Instead, this article is about why—after three major releases (8, 9, and now 10)—Rocky’s official documentation has stuck to the same clear message from day one, written in bold letters:

The answer is always the same: The project does not support in-place upgrades of one major version to another major version. You need to reinstall to move to the next major version.

As you probably know, CIQ (short for Ctrl IQ), a company founded also by Gregory Kurtzer, is the founding sponsor and primary commercial backer of Rocky Linux. While Rocky is governed by the Rocky Enterprise Software Foundation (RESF), CIQ provides significant resources—including infrastructure, engineering, and financial support—to help the project grow.

Plus, they offer paid support for business customers using Rocky. So it’s hard for me to imagine a situation where a company calls up and says, “Hi, we need help upgrading our eighty-six Rocky 9 servers to the latest version, Rocky 10,” and the support team replies, “No problem, folks — we’ll just reinstall them all.” Honestly, that’s beyond anything I can picture.

Rocky is an enterprise Linux distribution—we’re not talking about a small side project built by a few enthusiasts experimenting with the latest trends like immutability by spinning out yet another distro. Honestly, I wouldn’t even mind if there were no upgrade path between major versions in that kind of scenario. Nobody really expects one in those cases.

But this is Rocky we’re talking about—a name that, despite being only about four years old, has already established itself as a dependable RHEL alternative focused on serving businesses. That’s why the absence of a clear, supported path for upgrading between major versions feels unacceptable and difficult to explain.

To be clear and avoid any confusion, here’s how things stack up when compared to the other three leading enterprise Linux distributions from the Red Hat family:

Without diving into the technical weeds, here’s the short version: in all three cases, the solution is built on Red Hat’s Leapp framework, along with the ELevate tool developed by Alma and the broader community. In other words, the wheel’s already been invented. Why Rocky chooses not to make use of it—that’s something I really can’t explain.

However, not all is lost—if you head over to the Rocky Linux Wiki and check out the Upgrade Policy section, here’s what you’ll find:

Upgrades are not generally supported by Release Engineering nor most of the Rocky community. If you wish to perform upgrades between releases, there is a tool called ELevate that may be able to help you. But as a note of caution, this has not been formally tested and we cannot provide official assistance.

In other words, ELevate is available, but we’re not involved with it in any way, so if something goes wrong, it’s not on us. Now, without sounding like I’m picking favorites, I admire Alma for going the extra mile—not just for their user base but for the entire enterprise Linux community—by making in-place upgrades between major versions possible.

But let’s be clear—the tool does not currently support migration from Rocky 9 to 10. So, if you’re using Rocky 9, here’s the simple truth: there’s no direct upgrade path to 10. Your only option is to back up everything from your current setup, do a fresh install of Rocky Linux 10, reinstall your services, and restore your data from the backup. It’s a bit of a hassle, but it’s the only way to move forward.

Sure, if you’re a seasoned DevOps engineer, this might not be a big deal. With well-crafted Ansible playbooks and solid CI/CD pipelines, you can quickly get things back up and running. But that’s not the point—and let’s not forget, not everyone has that kind of experience and knowledge. Most people want to find something like this and just follow the steps.

The real issue is that when you operate at the enterprise level, offering a clear and reliable upgrade path isn’t some kind of bonus—it’s a basic expectation. Saying something like “The project does not support in-place upgrades” sends a pretty bad message to both current users and those considering adoption.

The sooner Rocky fixes this major flaw, the better off they’ll be. But until that happens, it’s hard to recommend a system that tells users to reinstall when others in the same league offer something as basic and expected as seamless in-place upgrades.

Yes, according to Rocky, the technical differences between major versions—like going from 8 to 9 or 9 to 10—are so significant that an in-place upgrade can’t guarantee everything will keep working properly. But that naturally raises the question: if that’s the case, how do RHEL, Alma, or Oracle manage to pull it off?

In conclusion, Rocky gives you all the benefits of the Red Hat ecosystem—stability, reliability, predictability, security, and a solid 10 years of support. But if you want to upgrade your system every 3 to 4 years (when a new major RHEL version is released) to take advantage of the latest tools and improvements, right now, you can’t do that without going through the hassle of setting everything up from scratch.

Hopefully, that’s something the Rocky team will address in the future.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

7 Comments

  1. Esc

    Hi
    as root user
    dnf update
    REPO_URL=”https://download.rockylinux.org/pub/rocky/10/BaseOS/x86_64/os/Packages/r”
    RELEASE_PKG=”rocky-release-10.0-1.6.el10.noarch.rpm”
    REPOS_PKG=”rocky-repos-10.0-1.6.el10.noarch.rpm ”
    GPG_KEYS_PKG=”rocky-gpg-keys-10.0-1.6.el10.noarch.rpm”
    rm -rf /usr/share/redhat-logos
    dnf -y –releasever=10 –allowerasing –setopt=deltarpm=false distro-sync
    rpm –rebuilddb
    reboot
    dnf update

  2. label

    Hello. I lead Release Engineering at Rocky Linux. This is a common question that the project receives and with the most recent Rocky Linux 10 release, the question has come up again. We received this question even on reddit where I gave a fairly lengthy explanation of why we don’t have the support: https://www.reddit.com/r/RockyLinux/comments/1l9gxdh/comment/mxd054a/

    To summarize, it comes down to time. It’s not a simple fix and it’s not something that my team can spend a lot of time on. Our primary focus is on the integrity of our builds and how we get them to our users. We have to be very precise in what we choose to work on as our time is strictly volunteer. This is why we direct users to ELevate not only for upgrades but also for support in issues pertaining to those upgrades. Upgrades can and do work and we’ve likely helped users on upgraded systems. This not a problem, in fact it speaks to the usefulness of the tool and the work that the maintainers have put in to make it function. The line gets drawn at when an upgrade is botched and my team and/or the rest of the community is asked to help on it. This puts everyone in a bind as it is not something we have officially tried nor has a significant amount of time been invested into understanding the tool, the process, and the potential impacts of an upgrade.

    I’ve always expressed that if there are those who wish for the project to support upgrades (via contributing to ELevate or another tool, plus providing support), that it would help everyone involved to form a Special Interest Group for it. The wiki page quoted in the article alludes to this. In the event that the group has proven itself, we will soften our stance. We just haven’t seen anyone step up to the plate for this kind of initiative.

    1. Bobby Borisov

      Thanks so much for taking the time to reply—this really clears things up.

  3. Anonymous

    Competent Enterprise Linux users don’t do in-place major version upgrades.

    1. Ricardo

      I disagree: in-place upgrades can actually be made by “Competent Enterprise Linux users” (whatever that may mean). Not every system will be upgraded that way, for sure, but it’s not rocket science either. Especially if you come from the Ubuntu/Debian world where they have in-place upgrades since almost forever.

      What I do agree is that in-place upgrades was never a sales point of “Enterprise Linux”.
      I think the rise of Ubuntu in the cloud market made some people say “Why can’t we have that?”, but I don’t think the traditional “Enterprise Linux” users really care that much, as the first Anonymous said.

  4. Anonymous

    Thank you, Bobby. Certainly something to consider before deciding which enterprise Linux to go for. SUSE also not a bad choice (although a different “family”).

  5. Anonymous

    The whole point of RHEL, is that it’s stable and has a long life cycle. You get a decade of support and you know that you can count on things to work. There’s no guarantee though that your enterprise software will work from one major version to the next though, because of the nature of Linux. So for an enterprise with a need for RHEL(or derivatives), easy upgrades are just a nice to have.

Leave a Reply

Your email address will not be published. Required fields are marked *