Tuesday, August 27, 2019

RHEL 8.0 and support for removed adapters

In RHEL 8.0, support for a good number of hardware devices has been removed. A list of removed adapters with their device IDs can be found in this RHEL documentation. We provide support for some of those that are still fairly commonly used today. You can check your devices's IDs (as shown by lspci -nn) against our list of supported devices.

(1) Installation of the OS requires a driver for your hardware. We offer driver update disks (DUD). You can download them from here or the corresponding directory of our mirror sites. Each DUD image contains a driver in the form of a kmod package. The installer is supposed to find the driver. If this does not happen, you need to append the inst.dd option to the boot command line. For details please see Performing an assisted driver update. Also, a tutorial video that demonstrates how to use ELRepo's DUD is available.

(2) The installation process installs the kmod package for your adapter. Normally, because of the kABI-tracking nature of kmod, there is no need to reinstall the driver upon each new kernel update. However, it was found that the current version of dracut in RHEL 8.0 has a bug and the initramfs image of a new kernel does not contain the kernel module from the installed kmod package. As a result, the new kernel fails to boot.

As an interim solution for the problem in (2), we provide a dracut package with a patch that fixes the bug here:


Install this version of dracut and then update the kernel. The system now should boot normally.

[UPDATE]  dracut-049-10.git20190115.el8_0.1 released on Oct 29, 2019 has the patch that fixes the issue.

[UPDATE2]  When updating the OS from 8.0 to 8.1, ELRepo's kmod packages must be updated to their .el8_1 version for the system to boot the 8.1 kernel.

[Note for CentOS-8 users]  If you have switched to the centosplus kernel (kernel-plus) while on 8.0, you may want to uninstall the kmod package and no further action is required when updating to 8.1.

Monday, November 19, 2018


With almost every new RHEL point release, we hear from users that yum fails with errors. In most cases, this is because the kernel of their distribution has not been updated to the updated version in RHEL. Our yum-plugin-elrepo package takes care of this issue. The details are in our release announcement copied below


yum-plugin-elrepo provides a yum plugin to exclude kmod packages from the yum transaction set which require kernels that are not yet available.

Elrepo.org provide kmod packages for RHEL and compatible distros. RHEL point releases sometimes break kABI compatibility requiring a rebuild of the kmod package against the latest RHEL kernel.

When this occurs at a RHEL point release, compatible distros such as CentOS and Scientific Linux often have yet to release their corresponding kernels which causes unresolved dependency errors in yum.

This plugin seeks to determine the kernel version that any given kmod package is built against and then determine if the corresponding kernel is available. If the corresponding kernel is not available, the kmod
package will be excluded from the yum transaction set until the required kernel becomes available.

Note: CentOS users will need to enable the CentOS Vault repositories to make previous kernels available to yum otherwise older kmod packages may be excluded.

Tuesday, January 3, 2017

ELRepo statistics 2017

Happy New Year!

It's been almost 8 years since we established The ELRepo Project. And 3 years since we last showed the statistics of our site.

As you can see below, the number of ELRepo users have continuously grown. We now have over 1 million users (1,146,783 IPs) using the repositories. EL5 will be EOL'd in 3 months. We would expect EL7 to catch and ultimately surpass EL6, although EL7's growth is not as fast as that of EL6's.

Our kernels, kernel-ml and kernel-lt, are popular. They are doubling every year the past 2 years. We have seen 187,785 users (IPs) in the last year, and ~18% of ELRepo's userbase have installed one duing the last 12 months.

Although not shown in the graphs, we see that the most popular download in all EL5, 6 and 7 was the Nvidia package which is followed by DRBD.

Wednesday, February 10, 2016

kABI-tracking kmod packages

Our kmod packages are "kABI-tracking". The drivers they provide will work across all Enterprise Linux (EL) kernel releases, meaning there is no need to reinstall them upon each kernel update. But what is the kABI?

The Kernel Application Binary Interface (kABI) is a set of in-kernel symbols used by drivers and other kernel modules. Each major and minor RHEL kernel release has a set of in-kernel symbols that are whitelisted. A kABI-tracking kmod package contains a kernel module that is compatible with a given kABI, that is, for a given major and minor release of the EL kernel.

However, in some cases the drivers use symbols that are not whitelisted in the RHEL kernel and these kernel symbols can change between releases. If a driver uses such kernel symbols, then the driver will not be backward compatible with older, previously released kernels.

How can we check if a kmod package uses non-whitelisted kABI symbols? In EL-6 and EL-7, install the following two packages:

yum install kernel-abi-whitelists ksc

Locate the module file (*.ko) and run the command:

ksc -k <module_name>.ko

For example:

$ ksc -k /lib/modules/2.6.32-358.el6.x86_64/extra/it87/it87.ko
Checking against architecture x86_64
Total symbol usage: 45 Total Non white list symbol usage: 4
Score: 91.11%

A copy of the report is saved in /home/bob/ksc-result.txt

In the above example, user "bob" has performed the check.

[Note] Due to a bug in the ksc package, it will not work for EL 6.7. More details and an easy fix can be found in Red Hat bug #1272348.

Thursday, September 24, 2015

Kernel-lt and RHEL6

A recent posting [1] to our general mailing list [2] reminded us that the
linux-3.10.X branch of the kernel source code will soon be reaching end-of-life status upstream, at the Linux Kernel Archives website. [3]

As a consequence, we now have to decide which source code branch should be used to build our kernel-lt package set for RHEL6 (and its clones, CentOS 6 & Scientific Linux 6).

Remembering that our slogan is "For the community, by the community.", you are invited to take part in the discussion [4] to select the new linux source code branch that will be used to build our EL6 kernel-lt package set. That discussion has now begun on our development mailing list [5].

[1] http://lists.elrepo.org/pipermail/elrepo/2015-September/002746.html
[2] http://lists.elrepo.org/mailman/listinfo/elrepo
[3] https://www.kernel.org/
[4] http://lists.elrepo.org/pipermail/elrepo-devel/2015-September/000613.html
[5] http://lists.elrepo.org/mailman/listinfo/elrepo-devel

Wednesday, February 12, 2014

kernel-ml and Nvidia driver

As you know, ELRepo provides the Nvidia driver for EL kernels but not for kernel-ml or kernel-lt. People running kernel-ml/lt can install the driver by downloading it directly from the Nvidia site. However, kernel version 3.13, as currently offered by kernel-ml, is known to have a problem with the latest Nvidia drivers. Fortunately, there is a fix for this issue. The detailed instructions are posted by CentOS developer Johnny Hughes on his blog.

Thanks, Johnny!

Thursday, October 24, 2013

Kernel-lt Package Sets -- What to Expect for EL5 and EL6

We have recently released [1] the latest update to the kernel-lt
package sets, for both EL5 and EL6.

Those of you who regularly monitor the front page of the Linux Kernel
Archives website [2] will have observed that the linux-3.0.X branch
has now been transitioned to EOL status following the release of the
linux-3.0.101 sources [3]. This action is in full accord with the
information contained within the 'Longterm release kernels' table, as
shown on the 'Active kernel releases' page [4].

As a preparation for this event, the ELRepo Project previously asked
for comments [5] as to which Linux source branch should then be used
for the basis of the kernel-lt package sets. The final decision [6]
was that kernel-lt for EL5 will be built using the linux-3.2.X branch
and kernel-lt for EL6 will be built using the linux-3.10.X branch.

All users who make regular use the kernel-lt packages should be
prepared for the transition that will thus occur with the next update
to the kernel-lt package sets.
[1] http://lists.elrepo.org/pipermail/elrepo/2013-October/002014.html 
[2] https://www.kernel.org/
[3] https://lkml.org/lkml/2013/10/22/125
[4] https://www.kernel.org/category/releases.html
[5] http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html
[6] http://lists.elrepo.org/pipermail/elrepo/2013-August/001890.html

Monday, August 5, 2013

Kernel-lt and the Future.

The ELRepo Project has regularly released a kernel-lt (long term supported)
package set for both enterprise Linux 5 & 6. These kernels have been based
on the linux-3.0.X stable branch.

The linux-3.0.X stable branch will be reaching end of life this coming
October [1][2] and a decision will have to be made with regards to the
future of the kernel-lt package sets that we provide.

There are a number of options available, the most radical being to stop
building and providing such kernel-lt package sets. However no decision
has yet been made.

A thread has been started on the ELRepo users' mailing list [3] where
subscribers have been asked to assist the Project's administrators in
making a decision.

If you would like to be part of the decision making process, please
contribute to that mailing list thread.

[1] https://www.kernel.org/category/releases.html 
[2] http://en.wikipedia.org/wiki/Linux_kernel#Maintenance 
[3] http://lists.elrepo.org/pipermail/elrepo/2013-August/001863.html

Tuesday, July 16, 2013

RHEL 5.10 Beta released

Red Hat has just announced the Beta release of Red Hat Enterprise Linux 5.10.  At ELRepo, we should get busy testing our packages against this release.

Saturday, April 13, 2013

Where Are The Kernel-lt-3.0.73-1.el6.elrepo Packages?

A week ago, we reported that the kernel-lt-3.0.72-1.elX.elrepo package sets (both el5 & el6) could not be built due to a bug introduced into the then just released linux-3.0.72 source tarball.

A week on and the linux-3.0.73 source tarball has been released. The appropriate files were submitted to the build systems and the expected kernel-lt-3.0.73-1.el5.elrepo packages were created. They have been signed, uploaded to the main mirror and their availability announced.

But what about the kernel-lt-3.0.73-1.el6.elrepo packages, you ask? Unfortunately the inability to test the patches so submitted has resulted in the presence of a different bug in the linux-3.0.73 source tarball. That bug only affects the 32-bit build of the kernel with the el6 configuration.

arch/x86/mm/numa_32.c:107: error: redefinition of 'alloc_remap'
include/linux/bootmem.h:144: note: previous definition of 'alloc_remap' was here
make[2]: *** [arch/x86/mm/numa_32.o] Error 1
make[1]: *** [arch/x86/mm] Error 2
make: *** [arch/x86] Error 2

Two successive buggy tarballs have now been released . . . We wonder what the next tarball (linux-3.0.74) will bring? A kick up the rear for the creators, applied by Linus Torvalds, perhaps?

Update (2013-04-15). By making a change to the configuration for the el6 kernel (namely CONFIG_NUMA disabled for 32-bit), we have been able to build and release the package set. If you are inconvenienced by this configuration change, please let us know and -- most importantly -- refer to this bug at bugzilla.kernel.org  Hopefully you will not be ignored.

Saturday, April 6, 2013

Where Are The Kernel-lt-3.0.72-1.elX.elrepo Packages?

Question: The long-term support linux-3.0.72 source tarball was released on 2013-04-05. When will the kernel-lt-3.0.72-1.elX.elrepo packages, built for both EL5 and EL6, be available please?

Answer (short): Never.

Answer (longer): Never, because the source tarball is defective. A freshly introduced bug brings the 32-bit build to an abrupt halt during the module building phase.

ERROR: "__udivdi3" [fs/ext4/ext4.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Wednesday, February 27, 2013

RHEL 6.4 and ELRepo

RHEL 6.4 was released on February 21th, 2013. We have tested our packages against this release and identified a couple of issues. Below is a digest of our note sent to the ELRepo mailing list.  

1. The current OpenAFS kmod package in elrepo (kmod-openafs-1.6.1-2.el6.elrepo) does not weak-link against the new 6.4 kernel. Jack Neely rebuilt the kmod against the new 6.4 kernel (kmod-openafs-1.6.1-5.el6.elrepo) but that package does not in turn weak-link against earlier kernels. So users of 6.3 should continue to use the package in the main repository (kmod-openafs-1.6.1-2.el6.elrepo). When you are ready to update to 6.4, also update kmod-openafs (kmod-openafs-1.6.1-5.el6.elrepo) from the elrepo testing repository at the same time.   

2. Red Hat updated the wireless stack in RHEL 6.4. As a result, there now exists a file level conflict between the kernel-firmware package and the rt2860-firmware and rt2870-firmware packages from elrepo, both providing the same file(s). Users of these devices are advised to uninstall the elrepo drivers and firmware for these devices and revert to the kernel drivers now these devices are supported by the distro.

Tuesday, February 19, 2013


Having received a system-generated message that the mainline linux-3.8 tarball was available at the Linux Kernel Archives, it was downloaded and fed into the ELRepo Project's build system.

After the dispatch of one e-mail in-box full of messages and an evening meal, the build status was checked. The expected message was duly seen --
All packages have been built.
 So just three steps remained -- package signing, uploading to the elrepo-kernel repository and announcing the release of this package set to our mailing-list.

By now our mirror-sites will be synchronising with this latest kernel-ml release and so it is all over -- until the next tarball is released.

Saturday, January 5, 2013