# Kmorph: a standby Linux kernel takes over after a crash in about one second, no reboot

- Published: 2026-11-12 07:43 UTC
- Section: Digital & Computing › Software & services
- Tags: Kmorph, Linux kernel takeover, multikernel, standby kernel, kdump, Cong Wang, Fedora bootc, kernel update without reboot
- URL: https://realtech.media/news/rt-2e4c5b6206e7e37eb34954f7_kmorph_a_standby/

**Linux developer Cong Wang presented the experimental Kmorph tool: a pre-started second kernel takes over after a crash without a reboot and also applies planned kernel updates.**

![Kmorph: a standby Linux kernel takes over after a crash in about one second, no reboot](https://realtech.media/media/2026/11/7d9f206df89649ec.png)
*lomazoma.com*

Linux developer Cong Wang has presented Kmorph, an experimental tool in which a second kernel, started in advance, takes over the system after a crash without rebooting the machine, as reported by lomazoma.com. [1] Wang states about one second from fault detection to a running successor. In tests, a prepared Nginx service answered requests again within two seconds after the kernel crash. [1] Kmorph requires a kernel with multikernel extensions and currently supports x86-64 and ARM64. [1]

## How the kernel takeover works

The multikernel extensions let several Linux kernels run in parallel on one machine, each with its own CPUs, memory regions and devices, without a hypervisor. Kmorph starts the reserve kernel in advance on a few freely configurable CPUs and part of the memory. A daemon there watches the previous kernel over vsock. [1]

If responses are repeatedly missing, the takeover begins. The successor first stops the CPUs of the previous kernel and confirms that they are actually stopped, so that both kernels never use the same resources. If it cannot stop a CPU reliably, it does not continue. It then takes over the devices, resets them as far as possible, restores the network configuration and attaches the remaining CPUs and memory by hotplug. [1]

Optionally, Kmorph writes a kdump-compatible vmcore with the memory contents, CPU registers and VMCOREINFO of the crashed kernel. Unlike the usual kdump process, no capture kernel has to be booted after the crash. [1]

Processes of the old kernel are not continued, so userspace normally restarts. Selected services can instead be started in the reserve kernel, for example with standby = nginx.service. Such a service binds its ports before the failure; at takeover the reserve kernel receives the network card, restores the MAC address, IP addresses and routes, and switches to the regular root file system with pivot_root. systemd starts the remaining services. Wang names fully uninterrupted operation as a development goal. [1]

## Limits and planned upgrades

Standby services must at first work without disks and network access and must not write state that has to persist. Services with their own mount namespaces, for example through PrivateTmp= or ProtectSystem=, must restart after the switch unless a drop-in relaxes their sandbox. [1]

The command kmorph upgrade triggers the takeover deliberately while the old kernel still works: it resends the network configuration, synchronizes the file systems, freezes writable file systems on block devices and asks the successor to take over. A newer kernel version can run this way, and no crash dump is produced. [1]

Clement Verna published a further test in the Fedora project forum: a Fedora 45 bootc image with a multikernel kernel and Kmorph. Terminal recordings show a takeover after a crash triggered via SysRq and a switch to a new image with a new kernel version. The test ran in a KVM VM with two vCPUs and 16 GB RAM on a Graviton3 machine with SELinux disabled. This setup allows only one switch per boot. Verna calls it a proof of concept and warns against production use. [1]

## Sources

1. [lomazoma.com](https://lomazoma.com/kernel-panik-aber-kein-neustart-kmorph-haelt-linux-am-laufen)

---

Source: RealTech, realtech.media — https://realtech.media/news/rt-2e4c5b6206e7e37eb34954f7_kmorph_a_standby/