Yes, you can do a linux update without reboot, but only if you're honest about what "update" means. Live patching (kpatch on RHEL, Canonical Livepatch on Ubuntu, Ksplice on Oracle Linux) redirects function calls in memory to close security holes on a running kernel. It does not move you from one kernel version to another. For a real version jump you need kexec or an actual reboot.

Last updated: 2026-07-21

Anyone selling you a full kernel upgrade with zero interruption through live patching is misunderstanding the tool. Live patching swaps individual functions, not whole kernels. Here is what that gets you, what it doesn't, and how to prove a patch actually took.

What does it actually mean to update a kernel without rebooting?

Two different things hide under the same phrase, and mixing them up wastes an afternoon. A live patch fixes a specific bug, usually a CVE, in a kernel that is already running. A kernel upgrade replaces version 5.15 with 6.1 and touches thousands of files. No live patching tool does the second one.

So decide which you actually need before you install anything. If a scanner flagged one vulnerability and you need it gone before the next maintenance window, that is a live patch job. If you want new features or a newer long-term-support kernel, that is a version upgrade, and it needs kexec or a restart.

Live patching keeps file descriptors and sockets open because nothing restarts. That is the whole point for latency-sensitive workloads and tight uptime SLAs. You'll get clear verification steps, expected pauses (often sub-millisecond), and a straight answer on why some changes still require a planned maintenance window.

How does live patching redirect kernel functions under the hood?

Live patching uses ftrace and kprobes to reroute calls from the old function to a fixed one. The tooling extracts only the functions that changed, builds them into a signed kernel module, and inserts that module at runtime. The old function stays in memory; new calls just land on the replacement.

That is why kernel source literacy matters more than a copy-pasted command. When a patch fails to apply, the reason is almost always in the changed function's shape: it changed a data structure, or a call is still in flight on another CPU. You need to read what the tool reports, not guess.

Understand the redirection and the failures make sense. Trust it blindly and you'll ship a module that silently didn't take. The kernel treats vendor-signed live patch modules as a security feature for exactly this reason: correct symbol resolution and integrity checks are not optional.

Here is the split I keep in my head:

How do you set up kpatch on RHEL or CentOS?

Run this first: confirm your kernel was built with live patching support. Check cat /boot/config-$(uname -r) | grep LIVEPATCH and look for CONFIG_HAVE_LIVEPATCH=y. No support compiled in means kpatch has nothing to hook into, and you stop here.

Install the kpatch tooling from your Red Hat repos, then enable the service so patches survive across the current uptime. For an official patch, kpatch install <module> loads it and kpatch list shows what is currently applied. On RHEL the web console and Red Hat Insights let you target and track CVEs across a fleet instead of ssh-ing into each box.

The catch nobody mentions: kpatch modules are built against one exact kernel version. If you're building your own with kpatch-build, you need the matching kernel-devel package and the debug symbols. A patch built for the wrong kernel will refuse to load, and dmesg will tell you exactly why. Best for RHEL and CentOS shops already paying for support.

How do you enable and verify Canonical Livepatch on Ubuntu?

On Ubuntu, Livepatch is the easy win, and it comes with an Ubuntu Pro subscription. There is also a free tier for a small number of personal machines, which is enough to learn the workflow before you commit a server fleet.

Enable it in two steps. Attach the machine with your Ubuntu Pro token, then turn the service on:

1. sudo pro attach <token> to register the machine.
2. sudo canonical-livepatch enable <key> to start patching.
3. canonical-livepatch status to see which patches are live.

That last command is the one that matters. It lists the applied fixes and the current patch state, which is how you prove the work happened. Because uname -r will not change after a live patch, the status output is your only honest signal that anything took. This covers the common "ubuntu kernel update without reboot" question, with one caveat: Livepatch ships security fixes only, never version upgrades. Best default for Ubuntu LTS servers.

Can Debian systems live patch the kernel?

Debian has no first-party live patching service, so stop looking for a canonical-livepatch equivalent in the repos. It isn't there. Debian's kernel is upstream, and upstream ships the livepatch core, but nobody packages ready-made patch modules for stable the way Canonical and Red Hat do.

Your two real options both take more work. You can build your own modules with kpatch-build, which means pulling matching kernel sources and debug symbols for the exact running kernel, then testing hard. Or you buy into Oracle Ksplice, which supports some non-Oracle distributions under contract.

For most Debian admins the honest answer is: schedule the reboot. If uptime genuinely can't take it, kexec gets you a fast version swap without a full boot cycle, and I'd reach for that before hand-rolling patch modules on production. If you're planning around this, my notes on how to schedule kernel updates cover the window side.

How does Oracle Ksplice compare for zero-downtime patching?

Ksplice patches at the object-code level and pulls only the changed functions, which keeps the change-set very small. It's included in Oracle Linux Premier Support for Oracle Linux and runs on Oracle Cloud Infrastructure. Historically it also supported CentOS, Ubuntu, and Red Hat Enterprise Linux under contract, which is its main selling point over kpatch.

You manage it with the uptrack commands. After registering, uptrack-upgrade applies available patches and uptrack-show lists what is on the running kernel. The mechanism differs from kpatch in scope: Ksplice tends to carry broader historical patch coverage, so an older kernel can be brought current on fixes without a rebuild-per-version dance.

The trade-off is the contract. Ksplice is tied to Oracle support, so it only makes sense if you're already in that world or specifically want its cross-distribution reach. Best for Oracle Linux environments, or mixed fleets already paying Oracle.

For the record, SUSE's own tool, kGraft, shipped in SUSE Linux Enterprise Server 12 SP5. Its work, along with Red Hat's, fed the upstream livepatch core that every tool above now stands on.

What is kexec and how does it let you swap kernels without a full restart?

kexec is the answer when you actually need a new kernel version, not just a patch. It loads a second kernel into memory and jumps straight into it, skipping the firmware and BIOS power-on self test. On big servers that POST can take minutes, so kexec turns a slow reboot into a fast one.

Load the target kernel and its initramfs, then execute:

1. sudo kexec -l /boot/vmlinuz-<version> --initrd=/boot/initrd.img-<version> --reuse-cmdline
2. sudo kexec -e to boot into it.

Be clear-eyed about what this is. kexec restarts userspace. Every process dies, sockets drop, and services come back up on the new kernel. It is not reboot-free; it is reboot-fast. So it's the right tool for a genuine linux kernel upgrade without reboot when you can tolerate a brief service blip but can't afford the full firmware cycle. If the new kernel misbehaves, my guide on rolling back a kernel update is the fallback.

When do live patches fail or require a real reboot anyway?

A live patch fails the moment the fix touches more than a function body. Changes to data structures, changes to how functions are laid out, or a major-version jump all break the ftrace redirect model. There is nowhere clean to hook, so the vendor won't even ship a live patch for it.

When a load fails, read the output instead of retrying. dmesg | tail and journalctl -k -b show why the module refused: a version mismatch, a symbol it couldn't resolve, or modules_disabled set to 1. Check cat /proc/sys/kernel/modules_disabled early; a 1 there means the kernel blocks all module loading and live patching is dead on arrival.

The other trap is patch stacking. Load enough individual patches and eventually two conflict, or you drift far enough from the base kernel that a reboot onto a properly updated kernel is simpler and safer. Live patching buys you time to schedule that reboot. It does not cancel it forever.

Is live patching worth it for enterprise uptime SLAs?

For a fleet where an unplanned reboot means lost transactions or a missed SLA, yes, easily. The math is simple: weigh the licensing cost against what a minute of downtime costs the business, multiplied by how often a critical CVE lands. For payment systems and latency-sensitive services, the subscription pays for itself the first time you close a serious hole without a maintenance window.

For a handful of internal boxes that reboot fine at 2 a.m., it's overkill. You'd spend more time managing entitlements and repo access than you'd ever save. Just patch and reboot on a schedule.

The real value is remediation speed under compliance pressure. Security says "fix this CVE now," the change calendar says "not until next month," and live patching resolves the standoff. Pair it with a plan to prevent kernel exploits rather than treating it as your only defense.

How do you confirm a kernel update actually applied without rebooting?

Do not trust uname -r here. After a live patch it shows the same version it did before, because the version string never changes. That command answers "which kernel booted," not "which fixes are live." Reaching for it is the most common way people fool themselves into thinking a patch took.

Use the tool that applied the patch. On RHEL, kpatch list shows loaded patch modules. On Ubuntu, canonical-livepatch status lists applied fixes and their state. On Oracle, uptrack-show reports what's on the running kernel.

Then confirm the plumbing directly. List /sys/kernel/livepatch to see active patches at the kernel level, and check for a taint flag in dmesg that marks a live-patched kernel. If the sysfs directory has entries and the tool agrees, the fix is real. If you want the full version story for context, this kernel version history timeline is worth a look.

FAQ

Does live patching survive a reboot?

No, and it isn't supposed to. Live patches live in memory on the running kernel. When you reboot, you should be booting a fully updated kernel that already contains those fixes on disk. If your boot kernel is still vulnerable after a restart, your package updates never happened. Fix that separately.

Will a live patch change my kernel version number?

Never. The version string reported by uname -r is baked in at boot and a live patch doesn't touch it. Two identical version strings can carry completely different sets of applied fixes. That's exactly why you verify with the patch tool's own status command instead of reading the version.

Can I remove a live patch if it causes trouble?

Yes. Each tool supports unloading. kpatch remove <module> drops a kpatch, canonical-livepatch disable turns off the Ubuntu service, and uptrack-remove reverses Ksplice patches. The redirect simply points calls back at the original function. Test the removal path before you need it in an incident, not during one.

Is kexec safe for production upgrades?

It's safe for the kernel itself, but treat it like a controlled restart. Userspace stops and restarts, so drain traffic and quiesce services first, exactly as you would for a normal reboot. Filesystems must be sync'd. Its win is skipping the firmware POST, not skipping the process restart.

Which distributions have first-party live patching?

Red Hat ships kpatch, Ubuntu ships Canonical Livepatch, SUSE built kGraft, and Oracle ships Ksplice. Debian has none of its own; you build modules with kpatch-build or buy Ksplice coverage. All four first-party options are subscription-gated, so confirm entitlements and outbound repo access before you plan a rollout.