Installation of new kernel on CentOS server

[matt3r]

This is my first experience with CentOS server.

I have installed CentOS 7.6.1810 as server with gui and later also as basic server on a Dell Poweredge r730.
In both cases I was not able to update the kernel to the latest lt version.
My workflow as root in both cases was:
- install and configure CentOS from iso image centos/7.6.1810/isos/x86_64/CentOS-7-x86_64-DVD-1810.iso
- update the system: yum update
- enable elrepo:
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
yum install https://www.elrepo.org/elrepo-release-7 ... noarch.rpm
- install kernel: yum --enablerepo=elrepo-kernel install kernel-lt
Yum installs the kernel 4.4.190-1.el7.el.repo, but it seems incomplete.
The kernel is with all files present in /boot folder except for the hidden hmac file
grub.cfg has new "menuentry" for new kernel
But yum list kernel only shows 3.10.0-957.el7 and 3.10.0-957.27.2.el7
and
rebooting into the new kernel was unsuccessful, while rebooting into the old kernels on the server with gui was possible

I tried to rebuild the initramfs with dracut for the new kernel, but the kernel still is not booting.

Can someone tell me what is wrong?
Is it because of the hmac file? If so, why does the installation process miss this file?
Or is it related to module dependencies?
Or is something wrong with my workflow? Do I miss something?

[TrevorH]

Why are you trying to update the kernel anyway? The distro kernel is the one we recommend and gets the best support. The ELRepo kernels are intended for people that need the latest kernel for hardware support.

[matt3r]

I need a kernel with statx support to install a docker container.
As per container creator it therefore requires a kernel higher than 4.11.

Quote:
To be able to run Fedora containers you need Docker >= 18.04 with seccomp support for the statx syscall required by Qt 5.10+. This is generally included in libseccomp >= 2.3.3; a kernel with statx support is also required; any kernel newer than 4.11 should be ok.

[TrevorH]

Docker works with the distro kernel. Redhat regularly backport functionality from the mainline kernels to the distro one.

[matt3r]

Yes, docker itself is working well for me on the current CentOS 7. I tried that for other applications.
Now this particular docker container, which is a fedora based container has some additional requirements regarding the kernel which I posted earlier.

Anyhow I found a workaround. It is the second best solution and it avoids a new kernel.
With your statement that I already have the best supported kernel installed, it becomes now the solution to go with.

Thanks for the support.

[TrevorH]

Requirements stated by other products do not cater for the fact that Redhat backport massive changes to the distro kernel on a regular basis. When they say it wants a 4.11 kernel, that does not mean that the CentOS/RHEL 3.10 kernel does not have that functionality. Please see https://access.redhat.com/security/updates/backporting/ for information on backporting of security fixes and features in CentOS and RHEL. Additionally https://access.redhat.com/solutions/2074 may also be of use.

[hunter86_bg]

Genral rule of thumb is:
Always test with latest distro kerrnel before considering going with other sources.

Edit:
If in doubt, always ask in the forum.

[jlehtone]

this particular docker container, which is a fedora based container has some additional requirements

Conceptually, that is really bad.

The idea of a container, AFAIK, is to pack necessary bits with application so that it can run. More than mere chroot, less than full virtual machine. If I cannot hand out my image to everyone regardless of their host OS, then the image is worthless.

[pjwelsh]

Just for the record, the current kernel-lt is too OLD for usage on recent systems... You will often be better off using the stock kernel or just bite the bullet and go kernel-ml. I have run into this exact situation before.

I can say, however, that the kernel-ml is WAYYYY faster in disk I/O! I was testing with NVME and other drive types and wow what a difference. So much of a difference that I've changed all of the server from stock and kernel-lt to kernel-ml that are high I/O systems.