kernel-ml

Kernel-ml for Enterprise Linux 7.

The kernel-ml packages are built from the sources available from the "mainline stable" branch of The Linux Kernel Archives. The kernel configuration is based upon the default RHEL-7 configuration with added functionality enabled as appropriate. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-7 kernels and, as such, they may be installed and updated alongside the regular kernel.

To install kernel-ml you will need to first install the elrepo-release package and then run:

yum --enablerepo=elrepo-kernel install kernel-ml

You can also Download manually from http://elrepo.org/linux/kernel/el7/
(Or from one of our mirror sites, if one is more conveniently located closer to you.)

There is no need to install the kernel-ml-headers package. It is only necessary if you intend to rebuild glibc and, thus, the entire operating system. If there is a need to have the kernel headers installed, you should use the current distributed kernel-headers package as that is related to the current version of glibc.

When you see a message like "your kernel headers for kernel xxx cannot be found ...", you most likely need the kernel-ml-devel package, not the kernel-ml-headers package.

Notes

These packages are provided 'As-Is' with no implied warranty or support. Using the kernel-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. These packages are not signed for SecureBoot.

If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker and, for our reference, to the ELRepo bug tracker. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole.

Kernel-ml for Enterprise Linux 6.

The kernel-ml packages are built from the sources available from the "mainline stable" branch of The Linux Kernel Archives. The kernel configuration is based upon the default RHEL-6 configuration with added functionality enabled as appropriate. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-6 kernels and, as such, they may be installed and updated alongside the regular kernel.

To install kernel-ml you will need to first install the elrepo-release package and then run:

yum --enablerepo=elrepo-kernel install kernel-ml

You can also Download manually from http://elrepo.org/linux/kernel/el6/
(Or from one of our mirror sites, if one is more conveniently located closer to you.)

There is no need to install the kernel-ml-headers package. It is only necessary if you intend to rebuild glibc and, thus, the entire operating system. If there is a need to have the kernel headers installed, you should use the current distributed kernel-headers package as that is related to the current version of glibc.

When you see a message like "your kernel headers for kernel xxx cannot be found ...", you most likely need the kernel-ml-devel package, not the kernel-ml-headers package.

Notes

These packages are provided 'As-Is' with no implied warranty or support. Using the kernel-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. These packages are not signed for SecureBoot.

If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker and, for our reference, to the ELRepo bug tracker. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole.

Known Issues

(1) As of kernel-ml-3.10.5-1.el6.elrepo, kernel-ml installed as a KVM guest will panic upon booting (FATAL: Module scsi_wait_scan not found error). This is because virtio_blk is not in the initramfs. More details can be found in:

http://elrepo.org/bugs/view.php?id=401
https://bugzilla.kernel.org/show_bug.cgi?id=60758

A workaround is to rebuild initramfs with a "--add-drivers virtio_blk" option. For example:

dracut --add-drivers virtio_blk -f /boot/initramfs-3.10.5-1.el6.elrepo.x86_64.img 3.10.5-1.el6.elrepo.x86_64

Note that This issue was resolved in dracut-004-356.el6 which was included in RHEL 6.6.

(2) As of kernel-ml-3.12.2-1.el6.elrepo, the userland process acpid will fail. This was caused by a change in the upstream kernel source which dropped support for the acpid-1 interface, as used by RHEL-6. See the following links for more details:

http://elrepo.org/bugs/view.php?id=435
https://bugzilla.kernel.org/show_bug.cgi?id=66681

Users of the kernel-ml package are encouraged to install the acpid-2 package to restore system acpi functionality. (The acpid-2 package will also work with the distribution kernel.)

(3) It has been reported that XFS with kernel >= 4.4 fails to mount if repaired by xfsprogs < 4.3.0. XFS on a v4.4 kernel requires xfsprogs v4.3. Elrepo provides xfsprogs-4.3.0 in the elrepo-testing repository.

(4) As the kernel-ml/lt packages are built from the source tarfiles provided by kernel.org without any modifications to the code, they can contain some differences when compared to the distribution kernels. One such example is found in ELRepo's bug #672. In mainline kernels (therefore ELRepo kernels), the default of sysctl kernel.sched_autogroup_enabled is set to 1 whereas that of RHEL kernels is set to 0. The bug report also lists other parameters that may differ (thanks to brad4).

---