Kernelcare CentOS 7 регрессия?
Форум
  1. Forums
  2. KernelCare
  3. KernelCare General Discussion
  1. Scott Mutter
  2. Friday, 08 November 2019
  3.  Subscribe via email
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?
Rate this post:
  1. 08.11.2019 19:11:50
  2. # 1
Sergey Khristich Accepted Answer
Posts: 137
Joined: 20.05.2019
0
Votes
Undo
Hello Scott! Thank you for reaching out!
We were unable to reproduce this. Here's 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 we'll link this thread to it. Thank you.
Marketing Manager
  1. 08.11.2019 19:11:01
  2. # 2
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
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
  1. 09.11.2019 18:11:06
  2. # 3
Sergey Khristich Accepted Answer
Posts: 137
Joined: 20.05.2019
0
Votes
Undo
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.
Marketing Manager
  1. 15.11.2019 01:11:39
  2. # 4
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
The latest version of Kernelcare for the 3.10.0-957.27.2.el7.x86_64 CentOS kernel:


# curl -s -k https://patches.kernelcare.com/$(echo "Linux version 3.10.0-957.27.2.el7.x86_64 ([email protected]) (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 https://patches.kernelcare.com/$(echo "Linux version 3.10.0-957.27.2.el7.x86_64 ([email protected]) (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
  1. 15.11.2019 16:11:00
  2. # 5
Sergey Khristich Accepted Answer
Posts: 137
Joined: 20.05.2019
0
Votes
Undo
Hello Scott! Happy to hear it and thanks for following up!
Marketing Manager
  1. 15.11.2019 19:11:15
  2. # 6
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
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 that's 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... it's 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 something's been overlooked in one area... kind of makes me question if something has been overlooked in other areas.
  1. 18.11.2019 09:11:32
  2. # 7
Sergey Khristich Accepted Answer
Posts: 137
Joined: 20.05.2019
0
Votes
Undo
Hello Scott,
Thank you for reaching out! Once again, we're 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!
Marketing Manager
  1. 18.11.2019 17:11:18
  2. # 8
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
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 doesn't 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.
  1. 19.11.2019 11:11:16
  2. # 9
Sergey Khristich Accepted Answer
Posts: 137
Joined: 20.05.2019
0
Votes
Undo
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.
Marketing Manager
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
гость
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.