Reboot your system to update the kernel.
-
[root@srv9 ~]# uname -rv 4.18.0-477.27.2.el8_8.x86_64 #1 SMP Fri Sep 29 08:21:01 EDT 2023
That is not CloudLinux kernel, so you better contact support. If you do: ls -la /boot you probably see the CL kernel there, but for some reason it's not booting from it. if you do: grubby --default-kernel you see what kernel will be booted. I've had the same problem and CL support fixed it pretty fast.0 -
[root@srv9 ~]# ls -la /boot total 599336 dr-xr-xr-x. 6 root root 4096 Oct 13 13:29 . dr-xr-xr-x. 18 root root 4096 Oct 13 14:34 .. -rw-r--r--. 1 root root 200352 Aug 10 21:01 config-4.18.0-477.21.1.el8_8.x86_64 -rw-r--r-- 1 root root 200475 Sep 6 02:17 config-4.18.0-477.21.1.lve.1.el8.x86_64 -rw-r--r--. 1 root root 200362 Sep 29 15:29 config-4.18.0-477.27.2.el8_8.x86_64 drwx------ 3 root root 16384 Jan 1 1970 efi drwx------. 4 root root 4096 Oct 13 13:54 grub2 -rw-------. 1 root root 100131765 Sep 10 07:16 initramfs-0-rescue-589c26a5dde74cb6b5f0ddb25389251b.img -rw-------. 1 root root 105512810 Oct 13 13:02 initramfs-0-rescue-6b52f5cfc01940f8b2bfbc64fab11f52.img -rw-------. 1 root root 64336835 Oct 13 12:58 initramfs-4.18.0-477.21.1.el8_8.x86_64.img -rw-------. 1 root root 29967360 Oct 13 13:00 initramfs-4.18.0-477.21.1.el8_8.x86_64kdump.img -rw------- 1 root root 107241190 Oct 13 13:29 initramfs-4.18.0-477.21.1.lve.1.el8.x86_64.img -rw-------. 1 root root 105049467 Oct 13 13:02 initramfs-4.18.0-477.27.2.el8_8.x86_64.img -rw------- 1 root root 32501760 Oct 13 13:11 initramfs-4.18.0-477.27.2.el8_8.x86_64kdump.img drwxr-xr-x. 3 root root 4096 Sep 10 07:14 loader drwx------. 2 root root 16384 Oct 13 12:57 lost+found lrwxrwxrwx. 1 root root 52 Sep 10 07:14 symvers-4.18.0-477.21.1.el8_8.x86_64.gz -> /lib/modules/4.18.0-477.21.1.el8_8.x86_64/symvers.gz lrwxrwxrwx 1 root root 56 Oct 13 13:28 symvers-4.18.0-477.21.1.lve.1.el8.x86_64.gz -> /lib/modules/4.18.0-477.21.1.lve.1.el8.x86_64/symvers.gz lrwxrwxrwx. 1 root root 52 Oct 13 13:01 symvers-4.18.0-477.27.2.el8_8.x86_64.gz -> /lib/modules/4.18.0-477.27.2.el8_8.x86_64/symvers.gz -rw-------. 1 root root 4451107 Aug 10 21:01 System.map-4.18.0-477.21.1.el8_8.x86_64 -rw------- 1 root root 4451335 Sep 6 02:17 System.map-4.18.0-477.21.1.lve.1.el8.x86_64 -rw-------. 1 root root 4450411 Sep 29 15:29 System.map-4.18.0-477.27.2.el8_8.x86_64 -rwxr-xr-x. 1 root root 10843912 Sep 10 07:15 vmlinuz-0-rescue-589c26a5dde74cb6b5f0ddb25389251b -rwxr-xr-x. 1 root root 10848008 Oct 13 13:02 vmlinuz-0-rescue-6b52f5cfc01940f8b2bfbc64fab11f52 -rwxr-xr-x. 1 root root 10843912 Aug 10 21:01 vmlinuz-4.18.0-477.21.1.el8_8.x86_64 -rw-r--r--. 1 root root 173 Aug 10 21:01 .vmlinuz-4.18.0-477.21.1.el8_8.x86_64.hmac -rwxr-xr-x 1 root root 10842752 Sep 6 02:17 vmlinuz-4.18.0-477.21.1.lve.1.el8.x86_64 -rw-r--r-- 1 root root 177 Sep 6 02:16 .vmlinuz-4.18.0-477.21.1.lve.1.el8.x86_64.hmac -rwxr-xr-x. 1 root root 10848008 Sep 29 15:29 vmlinuz-4.18.0-477.27.2.el8_8.x86_64 -rw-r--r--. 1 root root 173 Sep 29 15:29 .vmlinuz-4.18.0-477.27.2.el8_8.x86_64.hmac [root@srv9 ~]# grubby --default-kernel /boot/vmlinuz-4.18.0-477.21.1.lve.1.el8.x86_64 [root@srv9 ~]# 0 -
It should boot kernel vmlinuz-4.18.0-477.21.1.lve.1.el8.x86_64, if it does not then better contact support. 0 -
When setting up a new server and it refuses to boot to the LVE kernel, this will usually fix this issue: yum -y update kernel --enablerepo=cloudlinux-updates-testing reboot
1 -
When setting up a new server and it refuses to boot to the LVE kernel, this will usually fix this issue:
yum -y update kernel --enablerepo=cloudlinux-updates-testing reboot
thank you working fine now But in kernel care Command ('/usr/bin/kcarectl', '--update') returned non-zero code 1, Stdout: None, Stderr: New kernel detected (cloudlinux 4.18.0-477.27.2.lve.el8.x86_64 2100873171871790a6df30948f612ad750cf6a9f). There are no updates for this kernel yet.0 -
mybe this kernel test mode 4.18.0-477.27.2.lve.el8.x86_64 Because I have another server Release kernel-4.18.0-477.21.1.lve.1.el8.x86_64 0 -
[root@srv9 ~]# awk -F\' '$1=="menuentry " {print i++ " = "$2}' /etc/grub2.cfg 0 = System setup Why don't the rest of the options appear? [root@srv9 ~]# yum list kernel This system is receiving updates from CloudLinux Network server. Last metadata expiration check: 0:05:48 ago on Sat 14 Oct 2023 03:07:16 AM GMT. Installed Packages kernel.x86_64 4.18.0-477.21.1.el8_8 @anaconda kernel.x86_64 4.18.0-477.27.2.el8_8 @baseos kernel.x86_64 1:4.18.0-477.21.1.lve.1.el8 @cloudlinux-x86_64-server-8 [root@srv9 ~]# [root@srv9 ~]# rpm -qa |grep -i kernel kernel-core-4.18.0-477.21.1.lve.1.el8.x86_64 kernel-modules-4.18.0-477.27.2.el8_8.x86_64 kernel-tools-4.18.0-477.21.1.lve.1.el8.x86_64 kernel-core-4.18.0-477.21.1.el8_8.x86_64 kernel-core-4.18.0-477.27.2.el8_8.x86_64 kernel-modules-4.18.0-477.21.1.el8_8.x86_64 kernel-tools-libs-4.18.0-477.21.1.lve.1.el8.x86_64 kernel-modules-4.18.0-477.21.1.lve.1.el8.x86_64 kernel-headers-4.18.0-477.21.1.lve.1.el8.x86_64 kernelcare-2.82-2.el8.x86_64 kernel-4.18.0-477.21.1.el8_8.x86_64 kernel-4.18.0-477.27.2.el8_8.x86_64 kernel-4.18.0-477.21.1.lve.1.el8.x86_64 0 -
Can you let me know what other options you're expecting to see there, or what isn't working? I'm not entirely sure what the issue is based on those last posts. 0 -
When running the command I showed earlier, that installs the latest CloudLinux kernel. Since the kernel is so new, KernelCare doesn't recognize it, so there is nothing for it to do. That is not an issue and can be ignored. As for not listing the available kernels, I am going to assume you are using OVH? If so, this is due to how they have the OS image template configured. I don't like it either. 0
Please sign in to leave a comment.
Comments
9 comments