Subscribe to GEN
Login to GEN
Rocky Linux sets out to behave exactly as Red Hat Enterprise Linux does, bug for bug, which makes it the natural home for software certified against RHEL and for the research and HPC clusters where it is now widely used. We rate it highly. We run its close sibling, AlmaLinux, on our own servers, so the engineer who takes your call works on the same family of distribution, with the same tooling, every day.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, from in-house engineers in the UK. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
Rocky Linux was founded in December 2020 by Gregory Kurtzer, a co-founder of CentOS, after the end of CentOS Linux 8 was brought forward and a great many organisations found themselves without the free enterprise platform they had planned around. It is named after the late CentOS co-founder Rocky McGaugh, and it is governed by the Rocky Enterprise Software Foundation (RESF) rather than by a single vendor.
Its defining aim is bug-for-bug compatibility with Red Hat Enterprise Linux. That matters most where software has been certified against RHEL: engineering and scientific packages, databases and line of business applications whose vendors expect the platform to behave exactly as RHEL does, down to its quirks. Many organisations reviewing their RHEL subscriptions choose Rocky for precisely that reason, and research computing has adopted it widely.
Rocky and AlmaLinux are close siblings, both following RHEL, both free and both run by non-profit foundations, and for most workloads either is a sound choice. We chose AlmaLinux for our own servers; the practical differences are at the edges. AlmaLinux aims for application binary compatibility, while Rocky holds to the stricter bug-for-bug aim, which is the better fit where identical RHEL behaviour is the requirement. We support both, and we will tell you honestly which suits a given workload.
Rocky Linux is open source. Whether you support the RESF is entirely your decision, and not one we will make for you. If you do choose to, do it directly with the project, so the money reaches it rather than a reseller.
Rocky Linux faults tend to cluster around the things people choose it for: certified software, conversions from another distribution, and clusters of identical nodes where one fault is repeated a hundred times. These are the cases that arrive most often.
A migrate2rocky run that stopped partway, leaving packages from two vendors, repositories still pointing at the old distribution, or a kernel that will not boot. We establish exactly what state the server is in from the logs and the package database, then finish the job or roll it back, rather than running the script again and hoping.
Installation guides that begin by disabling SELinux, and applications that fail the moment it is enforcing. We write the contexts, booleans or targeted policy module the application actually needs, so it runs as certified without leaving the server weaker than it was.
Module stream conflicts, EPEL and the CRB or PowerTools repository out of step with the base system, third party repositories built for a different minor release, and version locks that quietly stopped a server receiving security updates.
A kernel update that leaves the GPU, InfiniBand or storage driver behind, a dracut emergency shell, or an initramfs without the module the root filesystem needs. We get the system up from the console, then make sure the next kernel update does not do the same.
Compute nodes that will not network boot or pull their image, nodes the scheduler has drained and nobody knows why, and a change to the node image that has broken every node at once. The HPC section below covers this in more depth.
An application vendor who says the fault is the platform, and a platform that looks fine. We reproduce the problem, establish which side of the line it sits on, and give the vendor the evidence in a form their support desk will accept.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. If a system is down now, raise it on the HelpDesk.
From CentOS 7. A great many CentOS 7 servers are still in production after their end of life, receiving no security updates. We take them to Rocky Linux 8 in place with ELevate and Leapp, without rebuilding the server or reinstalling its applications. Where an in-place upgrade is the wrong answer, because the server is simply too far gone, we will say so and rebuild it properly instead. See our CentOS page for the wider picture.
From CentOS, AlmaLinux, RHEL or Oracle Linux. The migrate2rocky script converts any of these to Rocky Linux of the same major version in place. The script is the easy part; the preparation is what decides whether it finishes cleanly, which is why we check third party repositories and out of tree kernel modules before it runs, not after. Where an estate is moving off RHEL, we plan it a few servers at a time rather than all at once.
Between Rocky Linux releases. Moves from 8 to 9 and from 9 to 10 are planned against the software you actually run. For cluster nodes a fresh image is usually cleaner than an upgrade; for a long-lived application server we weigh an in-place route against a rebuild alongside it, and tell you which we would choose.
Older unsupported systems are covered on our legacy system support page.
Rocky Linux is widely used in HPC, research and scientific computing, and some of the tooling those clusters depend on shares its founder: Gregory Kurtzer's open source work includes Warewulf for cluster provisioning and Apptainer, formerly Singularity, for HPC containers. A cluster fails differently from a server. The fault is usually in the join between the parts, and it usually affects every node at once, so it needs somebody who understands the whole stack rather than one layer of it.
Warewulf node images and overlays, network boot, DHCP and TFTP, and the node that boots but comes up without its configuration. Nodes built from one image, so a fix made once reaches all of them.
Slurm controllers and compute daemons, MUNGE authentication, partitions and limits, accounting, and the drained or down nodes that quietly shrink a cluster until someone asks why the queue is so long.
Apptainer images for research software, bind mounts to shared storage, and GPU and interconnect access from inside the container, so users can bring their own software stack without being given root on the cluster.
InfiniBand and high speed Ethernet fabrics, RDMA, subnet management and MTU, and drivers kept in step with the kernel, because a node that has lost its fabric looks healthy to everything except the job that needs it.
Shared home directories, scratch space and parallel filesystems, mount failures across the nodes, and the capacity and quota problems that stop jobs rather than servers.
Security updates rolled through the cluster by draining and rebuilding nodes in turn, so research keeps running while the platform is patched, and the head node, scheduler and storage kept on the same footing.
Standalone Rocky Linux servers are patched and hardened under a maintenance plan driven by our asset register, and watched by Oversight.
Yes. GEN provide 24/7 enterprise support for Rocky Linux across the UK, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. Support covers Rocky Linux 8, 9 and 10 on single servers and on HPC clusters, and is delivered by in-house UK engineers with no contract.
Rocky Linux aims for bug-for-bug compatibility with Red Hat Enterprise Linux, so software built and certified for RHEL should behave on Rocky exactly as it does on RHEL, including its quirks. Where an application vendor insists on RHEL itself for their certification or support, GEN will say so before a migration rather than after it.
Very little, for most workloads. Both are free, community governed rebuilds that follow Red Hat Enterprise Linux and have the same lifecycles. The practical differences are at the edges: Rocky aims for bug-for-bug compatibility with RHEL, while AlmaLinux aims for application binary compatibility. GEN run AlmaLinux on their own servers, rate Rocky highly, and support both.
Yes. GEN take CentOS 7 servers to Rocky Linux 8 in place using ELevate and Leapp, after a pre-upgrade assessment and with an image or snapshot taken first, so there is always a way back. Where an in-place upgrade is the wrong answer for a particular server, GEN will say so and rebuild it instead.
With the migrate2rocky script, which converts CentOS, AlmaLinux, RHEL and Oracle Linux to Rocky Linux of the same major version in place, without reinstalling the server or its applications. GEN check the repositories, third party packages and kernel modules first, because those are what cause a conversion to stop halfway.
Rocky Linux 8 is supported to 2029, Rocky Linux 9 to 2032 and Rocky Linux 10 to 2035. GEN support all three, and servers that have run past the end of their release can be kept running safely while a move is planned.
Yes. GEN support Rocky Linux clusters used for HPC, research and scientific computing, including node provisioning with Warewulf, scheduling with Slurm, containers with Apptainer, high speed interconnects and the shared and parallel storage behind them.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at published rates and use them as they need them, or take a fixed price annual maintenance plan if they prefer a predictable cost. Nothing has to be bought from the Rocky Linux project either.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
