Why Does CloudLinux Say Reboot to Update the Kernel?

CloudLinux Manager shows "Reboot your system to update the kernel" when the LVE kernel module, kmodlve, is not loaded, according to CloudLinux's own knowledge base. The simplest cause is a server that has not been rebooted since CloudLinux was installed or a kernel was updated, and one graceful reboot clears that. If the message survives a reboot, suspect an outdated kmod-lve package, the wrong boot kernel or Secure Boot.

The earlier version of this guide called the message a plain reminder that a newer kernel was waiting on disk, and said KernelCare would make it disappear. I could not confirm either claim. Every CloudLinux knowledge base article I found about this exact message, read on 10 October 2026, traces it to the LVE module, so this rewrite follows them.

What does "Reboot your system to update the kernel" mean in CloudLinux Manager?

It means the kernel that is running has no LVE module loaded, so the LVE functionality you installed CloudLinux for is not active. The main CloudLinux knowledge base article on the message lists four causes:

• The server was not rebooted after a kernel update.
• The kmod-lve package is outdated.
• Secure Boot is enabled and stops the module from loading.
• The GRUB or cgroup configuration is wrong.

Only the first is fixed by a reboot alone. The kernel's name also means different things on different releases. The CloudLinux installation documentation says that CloudLinux OS 8 and earlier use a CloudLinux kernel with LVE in its name, while CloudLinux OS 9 and later use an AlmaLinux kernel and "do not require LVE in the kernel name". In the knowledge base articles for both 8 and 9, the module comes from the kmod-lve package, which has to match the kernel that booted.

How do you check the running kernel, the installed kernels and the LVE module?

Run five read-only commands as root and compare the output. None of them changes anything.

uname -r                # the kernel that is running now
rpm -q kernel           # the kernel packages installed on disk
rpm -q kmod-lve         # the LVE module package
lsmod | grep kmodlve    # is the LVE module loaded?
grub2-editenv list      # the saved default boot entry

If lsmod prints a kmodlve line, the module is loaded, which is the condition CloudLinux's articles test for. If it prints nothing, run modprobe kmodlve, which tries to load it, and read the error. The error text tells you which row of the next table you are in. If uname -r shows an older version than the newest package from rpm -q kernel, the server has an installed kernel it has not booted yet.

Why is the message still there after a reboot?

Because the module still cannot load, and a second reboot will not change that. These are the cases CloudLinux documents, with the fix each article gives.

If the wrong kernel is the default, CloudLinux's article on choosing the kernel to boot uses grub2-set-default, and the CloudLinux 9 article uses grubby --set-default=/boot/vmlinuz-VERSION. Confirm either with grub2-editenv list before you reboot.

What does KernelCare live patching change?

KernelCare applies security patches to the kernel that is already running, so a kernel security fix does not have to wait for a reboot. It does not load a missing LVE module or change which kernel boots, so I do not expect it to clear this message.

The TuxCare documentation, which is where docs.kernelcare.com now redirects, describes KernelCare as live patching that installs kernel security patches "without rebooting the system". The agent checks for new patches every 4 hours. These commands show its state:

kcarectl --info         # patches applied to the running kernel
kcarectl --uname        # the effective kernel version after patching
kcarectl --patch-info   # the list of applied patches
kcarectl --status       # exit code 0 means the latest patch level is applied

Two things follow. First, uname -r keeps showing the booted kernel after live patching, so compare it with kcarectl --uname before you decide a server is behind. Security scanners can read the same value from /proc/kcare/effective_version. Second, TuxCare says live patching lets you plan maintenance windows on your own schedule. It does not say you never reboot again. KernelCare is a licensed product, registered by IP address or with kcarectl --register and a key.

How do you reboot a production cPanel server safely?

Use the Graceful Server Reboot interface in WHM, or the reboot command, inside a planned window and after you know what the server will boot. The cPanel System Reboot documentation says the graceful method closes user processes and stores their data first, and that a Forceful Server Reboot "can cause data loss" and is only for when the graceful one does not work.

1. Pick the window. Choose a low-traffic hour and tell customers. If billing runs on the same server, stay clear of its daily cron run. My guide on how to set up WHMCS explains that schedule.
2. Check the backup. Confirm that last night's backup finished and that you know how to restore from it.
3. Check console access. Log in to the provider's KVM, IPMI or VNC console before the reboot. If the boot fails, SSH is gone.
4. Check what will boot. Run grub2-editenv list and rpm -q kernel kmod-lve. Update kmod-lve first if it is behind.
5. Keep a way back. Leave at least one older kernel installed. CloudLinux's own workaround for a bad kernel build is to boot the previous one.
6. Reboot gracefully. One reboot, then wait. Do not reach for the forceful option because the server is slow to return.

How do you confirm the reboot worked?

The reboot worked when the expected kernel is running, kmodlve is loaded, no service failed and the message is gone.

uname -r
lsmod | grep kmodlve
systemctl --failed
kcarectl --info         # only where KernelCare is installed

Then check what customers see. CloudLinux's installation documentation says to check hosted websites and their database connections before you end the maintenance window, and WHM has a Service Status interface for the cPanel services. For monitoring afterwards, alert when lsmod | grep -q kmodlve fails, or when kcarectl --status exits with 2 (new patches not applied) or 3 (kernel unsupported).

If the module is loaded and the message is still shown, press Refresh on the Dashboard. The CloudLinux Manager documentation says dashboard data is collected once per day. I could not confirm whether this message is part of that daily data, so if it stays, open a ticket with CloudLinux support.

When should you not reboot yet?

Do not reboot yet if you have no console access, no tested backup, or checks that show the server would boot the wrong kernel. A reboot is the right fix for one cause and a risk for the others.

• An outdated module is not fixed by rebooting. Update kmod-lve and try modprobe kmodlve first.
• Do not edit GRUB by guesswork. The documented changes differ by release and by BIOS or UEFI boot, and a wrong line can leave a server that does not start.
• Do not switch off Secure Boot blind. CloudLinux notes that it usually means reaching the BIOS, which depends on your provider.
• Do not buy KernelCare to remove this message. It solves a different problem.
• If the boot fails, pick the previous kernel in the GRUB menu at the console, get services back, and send CloudLinux support the kernel and kmod-lve versions.

If you want someone else to own this, kernel and patch policy is part of my server hardening work and the alerts belong to hosting infrastructure consulting; the scoping call is free and takes about 30 minutes.

Last reviewed 10 October 2026. Disclosure: I manage Linux and cPanel servers for hosting companies and I sell that service, so I am not neutral. I am CTO at ElySpace, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI. Commands and package versions change between CloudLinux releases, so read the linked pages for your release before you run anything.