Kernelcare CentOS 7 regression?

[scott]

Any particular reason why the kernel version of the CentOS 7 Kernelcare kernel regressed?

Prior to running kcarectl --update:

# kcarectl --uname

3.10.0-1062.4.1.el7

After running kcarectl --update:

# kcarectl --uname

3.10.0-1062.1.2.el7

Did a wire get crossed some where?

[skhristich]

Hello Scott! Thank you for reaching out!
We were unable to reproduce this. Heres what we got:

# kcare-uname -r

3.10.0-1062.4.1.el7.x86_64

# kcarectl --update

Downloading updates

Patch level 2 applied. Effective kernel version 3.10.0-1062.4.1.el7

Updates already downloaded

Kernel is safe

# kcare-uname -r

3.10.0-1062.4.1.el7.x86_64

# kcarectl --uname

3.10.0-1062.4.1.el7

# kcarectl --uname^C

# uname -r

3.10.0-1062.4.1.el7.x86_64

Try unloading the patch and try again. Or can you open a support ticket https://cloudlinux.zendesk.com/hc/en-us/requests/new so we can take a closer look at your system? You can post the ticket number here and well link this thread to it. Thank you.

[scott]

Might this be because your base kernel is already 3.10.0-1062.4.1.el7.x86_64?

The two servers I have tried this on thus far are using older base kernels:

# uname -r

3.10.0-957.27.2.el7.x86_64

# uname -r

3.10.0-957.27.2.el7.x86_64

[skhristich]

Hello Scott! To help you with this question we need a little bit more information, please create a ticket here https://cloudlinux.zendesk.com/hc/en-us/requests/new and technical experts will help you asap. Thank you.

[scott]

The latest version of Kernelcare for the 3.10.0-957.27.2.el7.x86_64 CentOS kernel:

# curl -s -k [URL]https://patches.kernelcare.com[/URL]/$(echo "Linux version 3.10.0-957.27.2.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Mon Jul 29 17:46:05 UTC 2019" | sha1sum | cut -d " " -f 1)/8/kpatch.info | grep ^uname: | cut -d " " -f 2

3.10.0-1062.1.2.el7

The previous version of Kernelcare for the 3.10.0-957.27.2.el7.x86_64 CentOS kernel:

# curl -s -k [URL]https://patches.kernelcare.com[/URL]/$(echo "Linux version 3.10.0-957.27.2.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Mon Jul 29 17:46:05 UTC 2019" | sha1sum | cut -d " " -f 1)/7/kpatch.info | grep ^uname: | cut -d " " -f 2

3.10.0-1062.4.1.el7

[skhristich]

Hello Scott! Happy to hear it and thanks for following up!

[scott]

Actually the point was to show where the problem is.

If you are running the 3.10.0-957.27.2.el7.x86_64 stock CentOS 7 kernel...

Then the current Kernelcare kpatch.info has the uname as:

3.10.0-1062.1.2.el7

The previous Kernelcare (previous meaning the one before the current) kpatch.info has the uname as:

3.10.0-1062.4.1.el7

Note the differences:

3.10.0-1062.1.2.el7
3.10.0-1062.4.1.el7

This means that the previous Kernelcare (again... the one before the current Kernelcare) was showing:

3.10.0-1062.4.1.el7

Now the current Kernelcare (current as in the one thats available right now) is showing:

3.10.0-1062.1.2.el7

In my reality... 1.2 is less than 4.1.

In my reality... kernel versions go up... as in increase in number as time goes forward.

In my reality... going from 4.1 to 1.2... is a regression... its deviating from the expected behavior.

Is this suppose to be the expected behavior? Are kernel versions for Kernelcare patches suppose to fluctuate from a higher number to a lower number to a higher number to a lower number...

It just seems to me that something was overlooked here.

If somethings been overlooked in one area... kind of makes me question if something has been overlooked in other areas.

[skhristich]

Hello Scott,
Thank you for reaching out! Once again, were really sorry for the issues you were facing with, accept our apologies. We are working on this issue. This will be fixed in future releases. Please let us know if you have any questions. Thanks in advance!

[scott]

Thanks!

The main issue I have with this is:

1) Was the kernel system patched correctly? Since the kernel version seems to regress, it makes me wonder if the current Kernelcare patch for this kernel is actually patching everything that it needs to. Was it built against an old kernel?

2) How often does this happen? I caught this one just because the kernel version number regressed. But what about patches where the kernel version doesnt change? How can we be sure that all the necessary patches are being implemented or are some being skipped over during some of the patching?

Just kind of plants a little seed of doubt that all of this is being patched properly.

[skhristich]

Hello Scott,
1. No, this does not mean that the kernel version has been rolled back and no old kernel has been built. This is just the wrong line, and everything that is in patch-info is really patched.
2. Yes, indeed this rarely happens, and we will take additional measures to prevent this from happening at all.
We are really sorry about your experience. Should you need any further information, please do not hesitate to contact me.
Thank you.