Linux kexec Fast Reboot: kexec-tools vs Alternatives — Self-Hosted Kernel Live Boot Management

Rebooting a Linux server traditionally involves a full hardware reset cycle — the BIOS/UEFI firmware reinitializes, the bootloader loads the kernel, and the kernel performs its complete hardware discovery and driver initialization sequence. On large servers with extensive hardware, this process can take several minutes. The kexec system call bypasses this entire sequence by loading a new kernel directly into memory and jumping to it from the running kernel — achieving a “fast reboot” in seconds instead of minutes. Three approaches to kexec management exist: kexec-tools (the standard userspace utility), kexec-fastboot (systemd integration), and manual kexec invocation with custom scripts. For self-hosted server administrators managing kernel updates, crash recovery, and high-availability systems, understanding kexec is essential for minimizing downtime.

How kexec Works

The kexec mechanism operates in two phases:

1. Load phase — The new kernel image and its initramfs are loaded into unused regions of physical memory. The kernel verifies the image, sets up boot parameters, and prepares the transition.
2. Execute phase — The running kernel shuts down devices, unmounts filesystems (optionally), and jumps to the entry point of the loaded kernel. The new kernel boots as if the system had just started, but without going through firmware initialization.

The key insight is that kexec skips the firmware POST (Power-On Self Test), bootloader execution, and early kernel hardware discovery — steps that dominate boot time on servers with complex hardware configurations. A server that takes 3 minutes to fully reboot might complete a kexec reboot in 15-30 seconds.

Why Use kexec for Fast Reboots?

Minimize maintenance windows. Kernel updates traditionally require a full reboot. With kexec, the downtime for a kernel update drops from minutes to seconds. For servers with strict SLA requirements or those in maintenance windows measured in minutes, this difference is operationally significant.

Faster crash recovery. When configured with kdump (the crash dump mechanism), kexec loads a secondary “crash kernel” into reserved memory. When the primary kernel panics, kexec immediately jumps to the crash kernel, which captures memory state and reboots — all without firmware reinitialization. For crash dump analysis workflows, see our Linux crash dump analysis guide.

Automated kernel testing. Developers and QA teams use kexec to rapidly test kernel configurations. Loading and booting different kernels in sequence is dramatically faster than full reboots, enabling dozens of kernel test iterations in the time it would take for a handful of traditional reboots.

High-availability clusters. In clustered environments, the time a node spends rebooting affects cluster quorum and failover behavior. Faster reboots mean nodes rejoin the cluster more quickly, reducing the window where the cluster operates in degraded mode.

Remote server management. For servers managed remotely (cloud instances, colocation, branch offices), a failed reboot can mean a physical trip to the data center. kexec’s fast and reliable reboot process reduces the risk of a node failing to come back online after a firmware-level boot issue.

kexec-tools — The Standard kexec Utility

kexec-tools is the standard userspace package for managing kexec on Linux. It provides the kexec command-line utility and integrates with system shutdown procedures to automatically use kexec when a compatible kernel is loaded.

Core kexec Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# Load a kernel for fast reboot
sudo kexec -l /boot/vmlinuz-6.8.0-45-generic \
  --initrd=/boot/initrd.img-6.8.0-45-generic \
  --reuse-cmdline

# Execute the loaded kernel (fast reboot)
sudo kexec -e

# Load and execute in one command
sudo kexec -l /boot/vmlinuz --initrd=/boot/initrd.img --reuse-cmdline -e

# Unload a previously loaded kernel
sudo kexec -u

# Check if a kernel is loaded
sudo kexec --load-purge

# Specify custom kernel command line
sudo kexec -l /boot/vmlinuz \
  --initrd=/boot/initrd.img \
  --append="root=/dev/sda1 ro quiet splash"

The –reuse-cmdline Flag

The --reuse-cmdline flag tells kexec to use the same kernel command line parameters as the currently running kernel. This is almost always what you want — it ensures the new kernel boots with the same root filesystem, console settings, and other parameters. Without it, you must manually specify all boot parameters with --append.

Installation and Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Debian/Ubuntu
sudo apt install kexec-tools

# During installation, you'll be asked:
# "Should kexec-tools handle reboots?" — answer Yes to enable automatic kexec on reboot

# RHEL/CentOS/Fedora
sudo dnf install kexec-tools

# Enable kexec in systemd
sudo systemctl enable kexec.target

How kexec-tools Integrates with Reboot

When kexec-tools is configured to handle reboots (set during package installation), the standard reboot command automatically uses kexec if a kernel is loaded. The flow is:

1. You run sudo reboot
2. systemd’s kexec.target is activated
3. kexec-tools loads the newest kernel from /boot
4. The system performs the kexec transition instead of a hardware reset

This means you get fast reboots transparently — no change to your existing reboot workflow.

Docker Deployment

kexec requires kernel-level access and cannot run inside a standard container. However, you can build a kexec-enabled container image for deployment scripts:

1
2
3
4
5
6
7
8
9

version: "3.8"
services:
  kexec-loader:
    image: ubuntu:24.04
    command: ["bash", "-c", "apt-get update && apt-get install -y kexec-tools && echo 'kexec ready'"]
    privileged: true
    volumes:
      - /boot:/boot:ro
      - /proc:/proc:ro

In practice, kexec is managed directly on the host system, not through containers.

kexec-fastboot — Systemd Integration

kexec-fastboot is not a separate tool but rather a configuration pattern that integrates kexec with systemd’s reboot mechanism. On Debian-based systems, this is handled by the kexec-tools package’s systemd integration:

Configuration via /etc/default/kexec

1
2
3
4
5

# /etc/default/kexec
LOAD_KEXEC=true
KERNEL_IMAGE="/vmlinuz"
INITRD="/initrd.img"
APPEND_LINE=""

Setting LOAD_KEXEC=true enables automatic kexec loading during system shutdown. The KERNEL_IMAGE and INITRD paths point to symlinks that follow the default kernel selection.

systemd kexec.target

Modern systemd includes a kexec.target that coordinates the kexec reboot process:

1
2
3
4
5
6
7
8

# Reboot using kexec (if kernel is loaded)
sudo systemctl kexec

# Check kexec target status
systemctl status kexec.target

# Load kernel via systemd
sudo systemctl start kexec-load

Automated Kernel Update Reboots

For unattended kernel updates, combine unattended-upgrades with kexec:

1
2
3
4

# Create a hook script for kernel updates
cat > /etc/apt/apt.conf.d/99kexec-reboot << 'EOF'
DPkg::Post-Invoke { "if [ -f /boot/vmlinuz-$(uname -r) ] && [ $(dpkg -l linux-image-$(uname -r) 2>/dev/null | grep -c '^ii') -eq 0 ]; then kexec -l /boot/vmlinuz-$(ls /boot/vmlinuz-* | sort -V | tail -1) --initrd=/boot/initrd.img-$(ls /boot/initrd.img-* | sort -V | tail -1) --reuse-cmdline; fi"; };
EOF

This loads the new kernel automatically after a kernel package upgrade, so the next reboot uses kexec.

Manual kexec Scripting

For fine-grained control, you can write custom scripts that manage kexec loading and execution:

Basic kexec Reboot Script

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

#!/bin/bash
# /usr/local/bin/fast-reboot.sh

set -e

# Find the latest kernel
KERNEL=$(ls -t /boot/vmlinuz-* | head -1)
INITRD=$(ls -t /boot/initrd.img-* | head -1)

if [ -z "$KERNEL" ] || [ -z "$INITRD" ]; then
    echo "Error: No kernel or initrd found in /boot"
    exit 1
fi

echo "Loading kernel: $KERNEL"
kexec -l "$KERNEL" --initrd="$INITRD" --reuse-cmdline

echo "Executing kexec reboot..."
kexec -e

kexec with Verification

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/bin/bash
# /usr/local/bin/safe-kexec.sh

set -e

KERNEL="/boot/vmlinuz-$(uname -r)"
INITRD="/boot/initrd.img-$(uname -r)"

# Verify kernel and initrd exist
if [ ! -f "$KERNEL" ]; then
    echo "Error: Kernel $KERNEL not found"
    exit 1
fi

if [ ! -f "$INITRD" ]; then
    echo "Error: Initrd $INITRD not found"
    exit 1
fi

# Unload any existing kexec kernel first
kexec -u 2>/dev/null || true

# Load the new kernel
kexec -l "$KERNEL" --initrd="$INITRD" --reuse-cmdline

# Verify the kernel is loaded
if kexec --load-purge 2>/dev/null; then
    echo "Kernel loaded successfully"
    echo "Run 'kexec -e' to reboot, or 'kexec -u' to cancel"
else
    echo "Error: Failed to load kernel"
    exit 1
fi

Automated kexec for Kernel Updates

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/bin/bash
# /etc/kernel/postinst.d/kexec-load
# Hook script called after kernel package installation

NEW_KERNEL="/boot/vmlinuz-$1"
NEW_INITRD="/boot/initrd.img-$1"

if [ -f "$NEW_KERNEL" ] && [ -f "$NEW_INITRD" ]; then
    kexec -u 2>/dev/null || true
    kexec -l "$NEW_KERNEL" --initrd="$NEW_INITRD" --reuse-cmdline
    echo "kexec: Loaded $NEW_KERNEL for next reboot"
fi

Place this in /etc/kernel/postinst.d/ on Debian-based systems to automatically load new kernels after package installation.

kexec with kdump — Crash Recovery

kexec is the foundation of kdump, the Linux kernel crash dump mechanism. When kdump is configured:

1. A small “crash kernel” is reserved in memory at boot (via crashkernel=256M kernel parameter)
2. The crash kernel is loaded but not executed
3. When the primary kernel panics, kexec jumps to the crash kernel
4. The crash kernel captures the primary kernel’s memory to disk
5. The system reboots normally

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Enable kdump
sudo apt install kdump-tools
sudo dpkg-reconfigure kdump-tools  # Answer Yes

# Or configure manually
echo "crashkernel=256M" >> /etc/default/grub
sudo update-grub
sudo reboot

# Test kdump (WARNING: this will crash your system!)
# echo c > /proc/sysrq-trigger

For crash dump analysis after kdump captures a vmcore file, see our Linux crash dump analysis comparison covering the crash utility and makedumpfile.

Comparison: kexec Approaches

Choosing the Right Approach

Use kexec-tools with default configuration for most server environments. The package handles kernel selection, loading, and systemd integration automatically. The only configuration needed is answering “Yes” during installation to enable kexec-based reboots.

Use kexec-fastboot configuration when you need to specify a particular kernel path or custom boot parameters. The /etc/default/kexec file provides a simple way to override defaults without writing scripts.

Use manual scripting when you need custom logic — loading specific kernels based on conditions, integrating with configuration management tools (Ansible, Puppet), or building automated kernel update pipelines with verification and rollback.

Why Self-Host Your Reboot Management?

Managing kexec on your own Linux servers gives you control over kernel update downtime without depending on cloud provider features or commercial high-availability solutions:

Reduce maintenance window impact. For self-hosted services with user-facing SLAs, every minute of downtime matters. kexec reduces kernel update reboots from 2-5 minutes to 10-30 seconds — a 10x improvement that keeps services available during critical periods. For managing automated updates safely, see our Linux system update management guide which covers unattended-upgrades and update notification tools.

Improve crash recovery time. When servers crash, kdump’s kexec-based recovery captures diagnostic information and reboots in seconds rather than minutes. This minimizes the time services are unavailable while still preserving crash data for post-incident analysis.

Enable rapid kernel testing. Development and QA environments benefit dramatically from kexec’s fast reboot cycle. Testing multiple kernel configurations, validating patches, or running kernel regression suites becomes practical when each test iteration takes 30 seconds instead of 3 minutes. If you’re managing server services that need restart detection after kernel updates, our service restart detection tools comparison covers complementary tools for verifying service health after reboots.

No vendor lock-in. kexec is a standard Linux kernel feature — it works on any Linux distribution, any hardware platform that supports kexec (virtually all x86_64, ARM64, and PowerPC systems), and requires no proprietary software or cloud-specific features.

FAQ

Does kexec work with all Linux kernels?

kexec is supported on most modern Linux kernels (2.6.13+) for x86_64, ARM64, PowerPC, s390, and RISC-V architectures. Some embedded or minimal kernels may have kexec disabled in their configuration (CONFIG_KEXEC=y must be set). Check with grep CONFIG_KEXEC /boot/config-$(uname -r).

Can kexec cause data loss?

kexec itself doesn’t cause data loss — it performs a clean kernel transition. However, it does skip the normal shutdown sequence that syncs filesystems and stops services. Before running kexec -e, ensure all critical data is written to disk (sync) and services are gracefully stopped. The kexec-tools package handles this automatically when integrated with systemd.

How much memory does kexec need for the new kernel?

The new kernel and initramfs are loaded into unused RAM, so you need enough free memory to hold both. A typical kernel is 10-15MB and an initramfs is 30-100MB, so you need approximately 150MB of free RAM. If memory is tight, kexec can reuse pages that will be freed during the transition.

What is the difference between kexec reboot and normal reboot?

A normal reboot goes through the full hardware reset cycle: firmware POST, bootloader, kernel initialization, and hardware discovery. A kexec reboot loads a new kernel into memory while the current kernel is running, then jumps directly to the new kernel’s entry point — skipping firmware and bootloader entirely. The new kernel still performs its own hardware initialization, but this is much faster than a cold boot.

Can I use kexec to boot a different kernel version?

Yes. You can load any kernel image that is compatible with your hardware. Simply specify the path to the desired kernel and its matching initramfs: kexec -l /boot/vmlinuz-6.8.0-xx-generic --initrd=/boot/initrd.img-6.8.0-xx-generic --reuse-cmdline -e. This is useful for testing new kernels or booting into a known-good kernel after a bad update.

How do I verify that kexec was used for a reboot?

After a kexec reboot, check the kernel log: dmesg | grep -i kexec. You should see “kexec: rebooting” or similar messages. Additionally, the kernel boot time will be significantly shorter than a normal reboot — typically 10-30 seconds vs. 2-5 minutes on servers.