Maintained LTS Linux kernels for distributions the vendor walked away from
Free. Maintained by GetPageSpeed. No vendor lock-in.
EL7 (CentOS 7 / RHEL 7) is first in line. CoreCare ships the current 6.18.x LTS line from kernel.org, packaged and signed by GetPageSpeed. More distributions follow as upstream support gaps appear.
The gap
Red Hat killed CentOS Linux. EL7 (CentOS 7 / RHEL 7) went end-of-life in June 2024. ELRepo's kernel-lt channel for EL7 stopped getting updates in early 2025. The only ongoing alternative for staying on EL7 with a modern, maintained kernel is commercial: TuxCare KernelCare. Their parent company also sells the ELS userspace bundle. Both are paid.
CoreCare exists because a large slice of real production infrastructure is still running EL7, and that infrastructure should not have to start paying rent to keep running an OS that should keep working for free.
Install
sudo yum install -y https://extras.getpagespeed.com/release-latest.rpm sudo yum-config-manager --enable getpagespeed-extras-corecare sudo yum install -y kernel-lt sudo grub2-reboot 0 sudo reboot
The CoreCare sub-channel ships disabled by default in the GetPageSpeed extras release RPM. The yum-config-manager --enable line flips the opt-in. After reboot, uname -r should report a 6.18.x kernel.
Want to try it in a container first? Use getpagespeed/lts:el7 as your base image. It ships with the vault.centos.org repository pointers already fixed (stock centos:7 on Docker Hub is broken since CentOS 7 EOL) and the GetPageSpeed extras release pre-integrated. The install snippet above works inside it without the usual vault.centos.org sed dance.
Compared to ELRepo and TuxCare
| CoreCare | ELRepo kernel-lt (EL7) | TuxCare KernelCare + ELS | |
|---|---|---|---|
| Cost per server | $0 | $0 (channel abandoned) | ~$8 to $12 / month |
| Maintenance status | Active | Abandoned since early 2025 | Active (commercial) |
| License | GPLv2 | GPLv2 | Proprietary live patches, GPL ELS rebuilds |
kdump on stock crashkernel=auto |
Works out of the box (our %posttrans fixes it) |
Silently broken on last releases | Works (Red Hat semantics inherited) |
| Vendor lock-in | None | None | CloudLinux account, per-server license file |
| Paid support / SLA | No | No | Yes (the whole point) |
What's included
- Current 6.18.x LTS micro from kernel.org (6.18.x has long-term support through December 2028). The older 6.6.x LTS line is also kept in the channel as a fallback.
- Full kernel package set:
kernel-lt,kernel-lt-devel,kernel-lt-headers,kernel-lt-tools,kernel-lt-tools-libs. - Signed by
RPM-GPG-KEY-GETPAGESPEED, the same key as the rest of the GetPageSpeed extras channel. - kdump works out of the box. A
%posttransscriptlet rewritescrashkernel=autoto a concrete range (192 MB on most systems). Upstream kernels lack RHEL'sCONFIG_KEXEC_AUTO_RESERVEpatch and the stock CentOS 7 GRUB config silently fails to reserve crash memory on them. We patch around it. - Three small EL7-only build shims for old-glibc toolchain artifacts (modpost, gen_init_cpio, turbostat). Documented in the spec changelog.
- Forked from ELRepo's
kernel-lt-5.4.specunder GPLv2. Their changelog history is preserved at the bottom of our spec. Credit where due: ELRepo did the original packaging work that made this distribution shape possible. - Side-by-side install. Your stock 3.10 kernel stays on disk.
grub2-rebootany time to switch back.
What's not included (yet)
- perf is disabled in the first release.
perfis the Linux kernel profiling tool used by sysadmins and SREs to measure where CPU time goes inside the kernel and userspace. Most servers never run it. If you have never typedperf toporperf record, you will not notice it is missing. It is disabled here because buildingperfon EL7 requires a newer Python toolchain than EL7 ships by default (python3 ≥ 3.6 plus python3-setuptools), and wiring that into the kernel build pipeline cleanly is a yak-shave that should not block the first release. It comes back later. - No live patching. A reboot is required to switch kernels, the same as every other RPM kernel update for the last 25 years. If you have a strict maintenance-window problem and reboot-free kernel updates are a hard requirement, that is what TuxCare KernelCare sells.
What's coming
Signal of direction, not a roadmap with dates. CoreCare is intentionally low-promise and high-deliver.
- More distributions. EL7 is the first one in line because the gap is biggest there. As other LTS lines hit their EOL cliff and lose vendor maintenance, CoreCare will step in.
- Free userspace security packages. Extending CoreCare to ship free security updates for the rest of the userspace stack (openssl, glibc, curl, and the other usual CVE magnets) where upstream fixes can be cleanly backported. No timeline. The intent stays free.
- aarch64. x86_64 first, arm64 next if there is demand. Email us if you need it.
- Automatic upstream tracking. Fresh kernel.org LTS micros lands in the channel without a human starting the build.
One thing we will not do: start charging for the kernel itself. If a managed-services product is ever built around CoreCare, the underlying packages stay free.
We test it on real hardware
Every CoreCare release boots on real EL7 hosts running the kinds of workloads we care about (nginx, MySQL, PHP-FPM, the usual cast) before it ships. If a kernel breaks the stack we care about, it gets fixed before it ships, not after.
No SLA, no paid tier
If you need a contractual SLA, an account manager, and reboot-free live patching for kernel updates, TuxCare exists for exactly that and they will gladly sell it to you. CoreCare's pitch is the opposite: pay nothing, run signed packages from a maintained channel, take responsibility for your own reboots.
Frequently asked questions
Who maintains CoreCare?
GetPageSpeed. Best-effort cadence, no SLA. Questions go to info@getpagespeed.com.
Will you keep up with 6.18.x micro releases?
We track kernel.org's 6.18.x LTS line. Cadence is best-effort. Automatic upstream tracking is in the roadmap so fresh micros flow into the channel without a human starting the build.
Does kdump work?
Yes, out of the box. We ship a %posttrans scriptlet that rewrites the stock crashkernel=auto kernel command line to a concrete range. Upstream kernels lack RHEL's CONFIG_KEXEC_AUTO_RESERVE patch, so a stock CentOS 7 GRUB config silently fails to reserve crash memory on non-RHEL kernels. ELRepo's last EL7 builds had this broken; we fixed it.
Why not just use ELRepo?
ELRepo's kernel-lt channel for EL7 has not shipped updates since early 2025. The packaging is the same shape (we preserved their changelog history in our spec), but the channel itself has stopped moving. kdump was silently broken on the last few releases before they stopped, which is a hint at the level of EL7 attention available there.
Can I roll back to the stock 3.10 kernel?
Yes. grub2-reboot <index> back to the stock kernel and reboot. CoreCare RPMs do not displace the stock kernel; they install side by side. Worst case you boot the old kernel and uninstall kernel-lt.
Is the package signed?
Yes, by RPM-GPG-KEY-GETPAGESPEED. Same key as every other package on extras.getpagespeed.com. The getpagespeed-extras-release RPM installs the public key into /etc/pki/rpm-gpg/.
Can I get paid support?
No. CoreCare is intentionally free. If you need a contractual SLA, an account manager, and procurement-friendly paperwork for kernel updates, TuxCare KernelCare is the established commercial option and their pricing is on their site.
Are you going to start charging for it later?
No. The whole point of CoreCare is that staying on a long-supported kernel should not be a recurring bill. If a future managed-services offering is built around CoreCare, the kernel packages themselves stay free.
Are you competing with TuxCare?
Not really. TuxCare sells live kernel patching, account managers, and contractual SLAs to enterprises with maintenance-window problems. CoreCare ships signed RPMs and a reboot command. Different audience, different price point ($0 vs $8-12 per server per month).
What about aarch64 or other architectures?
First release is x86_64 only. aarch64 may follow once there is demand. Email info@getpagespeed.com if you need it.
What about EL8, EL9, or other distributions?
EL7 is the first release because the EOL gap is biggest there. Other LTS lines will follow as their own vendor-maintenance cliffs arrive. If your distribution is approaching EOL and you would like CoreCare coverage, email info@getpagespeed.com.
Will CoreCare expand to userspace security updates?
We are looking at extending CoreCare to ship free security updates for the rest of the userspace stack (openssl, glibc, curl, and the usual CVE-magnet packages) where upstream fixes can be cleanly backported. No timeline. The intent is to keep it free.