As Phil says, the kernels are provided 'as-is', but I'd like to give you a 
quick sample of how we've found it in production.

We run anywhere between 250-2000 CentOS 7 VMs each year.
We have been using elrepo kernel-ml on both our VMs and our physical SANs / 
storage servers and our physical backup servers for the past 3~ years.
We install the latest kernel-ml package as soon as it's available (we automate 
everything, the kernel package is ensured that it is the latest available every 
20 minutes~).

In those 3~ years we have had (from memory) two problems:

1. Only affected our storage servers, it was some odd kernel bug that caused 
some DRBD issues, when we noticed a pattern we just booted into the previous 
kernel and the bug was fixed (upstream, in the kernel itself) about 5 releases 
later (it wasn't very well reported to the kernel devel team or it would have 
been quicker, at any rate - nothing to do with elrepo or kernel-ml).

2. A problem that may have affected intel 7xx series NICs that was again an 
upstream kernel bug, saw the problem straight after rebooting into the new 
kernel, rebooted into the last kernel - it was fine, left it for a couple of 
days until the next build was out - tried it and it was fine.

Other than that - kernel-ml has do nothing but provide us with much better 
performance and new features (we use a lot of 'newish' things like NVMe, 
containers before they were cool, new hardware, self design software defined 
storage / SANs etc....).

For me and my engineering team it's an absolute no-brainer to use kernel-ml and 
there's no way we'd be seen dead running the stock centos 3.x kernels to be 

note: we don't use any weird 'black box' oracle / ibm or the likes hardware 
that require special kernel drivers to be installed etc... but I haven't seen 
people do that much on x86 these days anyway.

Sam McLeod

> On 11 Jul 2018, at 08:39, Phil Perry <> wrote:
> On 10/07/18 18:57, Pedro Flores wrote:
>> We recently started using ELRepo’s kernel repositories in a subset of our 
>> production infrastructure to deal with some issues we were experiencing with 
>> CentOS 7.5 latest kernels.  Our security team has some concerns about how 
>> quickly ElRepo releases new kernel packages that address either major bug 
>> fixes or CVE exploits after the kernels containing these updates have been 
>> released by the Linux Kernel Main archives.    Is there a certain amount of 
>> time that we should expect new kernels to make it to ELREpo yum repositories 
>> after they have been released by the Linux Kernel Archives folks?
>> Thanks in advance.
>> *--*
>> **
>> *Pedro Flores*
> Hi Pedro,
> Did you read the release announcement(s)? The relevant part to your question 
> is here:
>  These packages are provided "As-Is" with no implied warranty or
>  support. Using the kernel-lt/-ml may expose your system to security,
>  performance and/or data corruption issues. Since timely updates may
>  not be available from the ELRepo Project, the end user has the
>  ultimate responsibility for deciding whether to continue using the
>  kernel-ml packages in regular service.
> Your security team are free to review our previous performance to get an 
> indication for how quickly kernel packages are typically released, but past 
> performance should not be taken as a guarantee for future release time scales.
> If you have issues with the EL7.5 kernel in a production environment and do 
> not have the expertise to fix it in house, I would highly recommend you 
> purchase RHEL subscriptions and raise a support case directly with Red Hat to 
> have your issues resolved. As stated in our release announcement(s), our 
> kernel packages are not intended for production use. Elrepo is a voluntary 
> project and Alan handles all kernel builds single-handedly on donated limited 
> build hardware. As such, we are unable to offer you any guaranteed level of 
> service, hence my recommendation to purchase RHEL subscriptions if that is 
> what you require.
> Hope that helps,
> Phil
> _______________________________________________
> elrepo mailing list

elrepo mailing list

Reply via email to