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:
- RHEL officially supports upgrades between major versions
- AlmaLinux also provides an official upgrade path between its major versions
- Oracle Linux supports upgrading between major versions
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?
Source link
