Project 8: Introduction to Kernel Panics
Trigger and capture a kernel crash—the ultimate system failure—and prepare it for analysis.
Quick Reference
| Attribute | Value |
|---|---|
| Difficulty | Expert |
| Time Estimate | 2-3 weeks |
| Language | C (kernel module), Bash |
| Prerequisites | Strong Linux admin skills, C programming |
| Key Topics | Kernel modules, kdump, kexec, vmcore, kernel crash capture |
1. Learning Objectives
By completing this project, you will:
- Understand the difference between user-space crashes and kernel panics
- Learn to write and load Linux kernel modules
- Configure kdump for automatic kernel crash capture
- Generate and capture a vmcore (kernel crash dump)
- Understand the kexec mechanism for crash kernel booting
- Set up a safe development environment for kernel work
2. Theoretical Foundation
2.1 Core Concepts
What is a Kernel Panic?
A kernel panic is a fatal error in the Linux kernel from which recovery is impossible. Unlike user-space crashes (which only affect one process), a kernel panic means:
┌─────────────────────────────────────────────────────────────────┐
│ USER-SPACE CRASH vs KERNEL PANIC │
├─────────────────────────────────────────────────────────────────┤
│ │
│ User-Space Crash Kernel Panic │
│ ────────────────────── ────────────────────── │
│ │
│ • One process dies • Entire system dies │
│ • Other processes unaffected • All processes terminated │
│ • System continues running • System must reboot │
│ • Core dump: process state • vmcore: entire system state │
│ • Easy to trigger safely • Dangerous—needs VM │
│ • Handled by signal handler • Handled by panic() function │
│ │
│ Examples: Examples: │
│ • Segmentation fault • NULL pointer in kernel │
│ • Division by zero • Deadlock in interrupt handler │
│ • Stack overflow • Corrupt kernel data structure │
│ │
└─────────────────────────────────────────────────────────────────┘
Why Kernels Panic
The kernel panics when it detects a condition from which it cannot safely recover:
┌─────────────────────────────────────────────────────────────────┐
│ KERNEL PANIC TRIGGERS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. NULL POINTER DEREFERENCE │
│ Accessing address 0x0 in kernel space │
│ BUG: kernel NULL pointer dereference │
│ │
│ 2. DIVIDE BY ZERO │
│ Division by zero in kernel code │
│ divide error: 0000 [#1] SMP │
│ │
│ 3. DEADLOCK DETECTION │
│ Circular lock dependency detected │
│ soft lockup - CPU#0 stuck for 22s! │
│ │
│ 4. CORRUPT DATA STRUCTURES │
│ Invalid pointer in linked list │
│ list_add corruption. prev->next should be... │
│ │
│ 5. OUT OF MEMORY (OOM) PANIC │
│ System runs out of memory, panic_on_oom enabled │
│ Out of memory: Kill process or sacrifice child │
│ │
│ 6. EXPLICIT BUG/WARN │
│ Code calls BUG() or BUG_ON(condition) │
│ kernel BUG at mm/slub.c:1234! │
│ │
└─────────────────────────────────────────────────────────────────┘
The kdump Mechanism
kdump is the Linux kernel crash dump mechanism. It works by having a second kernel ready to boot:
┌─────────────────────────────────────────────────────────────────┐
│ KDUMP ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ NORMAL OPERATION │
│ ════════════════ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ MAIN MEMORY │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Production Kernel │ │ │
│ │ │ (Running your apps) │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Reserved Memory (crashkernel=256M) │ │ │
│ │ │ (Crash kernel preloaded here) │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ │ │
│ ▼ PANIC OCCURS │
│ │
│ CRASH CAPTURE │
│ ═════════════ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ MAIN MEMORY │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Production Kernel MEMORY │ │ │
│ │ │ (Now frozen - being saved as dump) │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Crash Kernel (NOW RUNNING) │ │ │
│ │ │ makedumpfile -> /var/crash/vmcore │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ │ │
│ ▼ REBOOT │
│ │
│ POST-CRASH │
│ ══════════ │
│ │
│ $ ls /var/crash/ │
│ 127.0.0.1-2025-12-20-15:00:00/ │
│ vmcore <- Full kernel memory dump │
│ vmcore-dmesg.txt <- Kernel log at crash time │
│ │
└─────────────────────────────────────────────────────────────────┘
Linux Kernel Modules
Kernel modules are pieces of code that can be loaded and unloaded into the kernel at runtime:
// Minimal kernel module structure
#include <linux/module.h>
#include <linux/kernel.h>
static int __init my_init(void)
{
printk(KERN_INFO "Module loaded\n");
return 0; // 0 = success
}
static void __exit my_exit(void)
{
printk(KERN_INFO "Module unloaded\n");
}
module_init(my_init);
module_exit(my_exit);
MODULE_LICENSE("GPL");
2.2 Why This Matters
Kernel crash analysis is essential for:
- Kernel developers: Debugging kernel code and drivers
- System administrators: Diagnosing production server crashes
- Security researchers: Analyzing kernel vulnerabilities
- Storage/Network vendors: Debugging driver issues
- Cloud providers: Understanding host-level failures
2.3 Historical Context
- 1991: Linux 0.01 had basic panic handling
- 2003: kexec added to Linux 2.6, enabling crash kernel booting
- 2005: kdump mechanism formalized
- 2007: makedumpfile for compressed dumps
- Today: kdump is standard on enterprise Linux distributions
2.4 Common Misconceptions
Misconception 1: “You can analyze a kernel panic like a user-space crash”
- Reality: Kernel panics need different tools (crash utility, not GDB)
Misconception 2: “kdump always captures the crash”
- Reality: If the panic is severe enough, even kdump might not work
Misconception 3: “You need to recompile the kernel to debug it”
- Reality: Debug symbols come in separate packages (kernel-debuginfo)
Misconception 4: “Kernel modules are dangerous to write”
- Reality: In a VM, they’re safe to experiment with
3. Project Specification
3.1 What You Will Build
- A simple Linux kernel module that intentionally causes a panic
- A properly configured VM with kdump enabled
- A captured vmcore file from your triggered panic
- Documentation of the entire process
3.2 Functional Requirements
- Set up a VM with kdump
- Configure crashkernel boot parameter
- Install and enable kdump service
- Verify kdump is operational
- Write a buggy kernel module
- Create a loadable kernel module
- Include a function that dereferences NULL
- Trigger the panic on module load
- Capture the crash
- Load the buggy module
- Verify system panics
- Confirm vmcore is saved after reboot
- Verify the capture
- Locate the vmcore file
- Verify it’s a valid crash dump
- Extract dmesg from vmcore
3.3 Non-Functional Requirements
- All work done in a virtual machine (never on host)
- VM snapshots before any risky operations
- Clear documentation for reproducibility
- Ability to restore VM to known good state
3.4 Example Usage / Output
Loading the buggy module:
# In the VM
$ sudo insmod buggy_module.ko
[ 123.456] buggy_module: loading out-of-tree module taints kernel.
[ 123.457] buggy_module: module loaded, about to crash...
[ 123.458] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 123.459] #PF: supervisor write access in kernel mode
[ 123.460] #PF: error_code(0x0002) - not-present page
[ 123.461] PGD 0 P4D 0
[ 123.462] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 123.463] CPU: 0 PID: 1234 Comm: insmod Tainted: G OE 6.1.0
[ 123.464] Hardware name: QEMU Standard PC...
[ 123.465] RIP: 0010:buggy_init+0x15/0x20 [buggy_module]
[ 123.466] ...
[ 123.470] Call Trace:
[ 123.471] do_one_initcall+0x46/0x1c0
[ 123.472] do_init_module+0x52/0x230
[ 123.473] ...
[ 123.480] Kernel panic - not syncing: Fatal exception
[ 123.481] Kernel Offset: 0x1e00000 from 0xffffffff81000000
[ 123.482] ---[ end Kernel panic - not syncing: Fatal exception ]---
# System kexecs into crash kernel
# Saves memory to /var/crash/
# Reboots
# After reboot:
$ ls -la /var/crash/
total 156004
drwxr-xr-x 3 root root 4096 Dec 20 15:00 .
drwxr-xr-x 23 root root 4096 Dec 20 14:30 ..
drwxr-x--- 2 root root 4096 Dec 20 15:00 127.0.0.1-2025-12-20-15:00:00
$ ls -la /var/crash/127.0.0.1-2025-12-20-15:00:00/
total 152340
-rw------- 1 root root 155987456 Dec 20 15:00 vmcore
-rw-r--r-- 1 root root 54321 Dec 20 15:00 vmcore-dmesg.txt
$ head /var/crash/127.0.0.1-2025-12-20-15:00:00/vmcore-dmesg.txt
[ 123.456] buggy_module: loading out-of-tree module taints kernel.
[ 123.457] buggy_module: module loaded, about to crash...
[ 123.458] BUG: kernel NULL pointer dereference, address: 0000000000000000
...
3.5 Real World Outcome
After this project, you’ll be able to:
- Set up kernel crash capture on any Linux system
- Safely develop and test kernel modules
- Capture crash dumps for analysis (Project 9)
- Understand the kernel panic process from start to finish
4. Solution Architecture
4.1 High-Level Design
┌─────────────────────────────────────────────────────────────────┐
│ PROJECT ARCHITECTURE │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ HOST MACHINE │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ VIRTUAL MACHINE (QEMU/VirtualBox) │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ LINUX KERNEL │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────┐ ┌────────────────────┐ │ │ │
│ │ │ │ kdump service │ │ Your buggy module │ │ │ │
│ │ │ │ (kexec preload) │ │ (triggers panic) │ │ │ │
│ │ │ └─────────────────┘ └────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ crashkernel reserved memory │ │ │ │
│ │ │ │ (crash kernel preloaded) │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ /var/crash/ │ │ │
│ │ │ vmcore files saved here after panic │ │ │
│ │ └──────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.2 Key Components
- Virtual Machine: Isolated environment for safe crashes
- kdump Service: Pre-loads crash kernel into reserved memory
- Buggy Module: Deliberately triggers kernel panic
- vmcore: Resulting crash dump file
4.3 Data Structures
The kernel module consists of:
struct module_structure {
// Module metadata
char *name;
struct module_init *init_func; // Called on insmod
struct module_exit *exit_func; // Called on rmmod
// License, author, description
char *license;
// Dependencies
struct list_head dependencies;
};
4.4 Algorithm Overview
kdump Boot Process:
- Main kernel boots with
crashkernel=256Mparameter - Memory is reserved at boot time for crash kernel
- kdump service uses kexec to preload crash kernel into reserved memory
- Normal operation continues
- On panic:
- Kernel jumps to crash kernel using kexec
- Crash kernel boots in reserved memory
- Original memory is preserved (not overwritten)
- makedumpfile copies memory to /var/crash/
- System reboots normally
5. Implementation Guide
5.1 Development Environment Setup
Step 1: Create a Virtual Machine
# Option A: VirtualBox
VBoxManage createvm --name "crash_lab" --ostype "Linux_64" --register
VBoxManage modifyvm "crash_lab" --memory 4096 --cpus 2
# Option B: QEMU/KVM
virt-install \
--name crash_lab \
--ram 4096 \
--vcpus 2 \
--disk size=20 \
--os-variant debian11 \
--cdrom debian-11.iso
# Install a Linux distribution (Debian, Ubuntu, or Fedora recommended)
Step 2: Install Kernel Development Tools (in VM)
# Debian/Ubuntu
sudo apt-get update
sudo apt-get install build-essential linux-headers-$(uname -r)
sudo apt-get install kdump-tools crash makedumpfile
# RHEL/CentOS/Fedora
sudo dnf install kernel-devel kernel-headers
sudo dnf install kexec-tools crash
Step 3: Take a VM Snapshot
# VirtualBox
VBoxManage snapshot "crash_lab" take "clean_state" --description "Before any kernel work"
# libvirt/QEMU
virsh snapshot-create-as crash_lab clean_state "Before any kernel work"
5.2 Project Structure
kernel_panic_project/
├── module/
│ ├── buggy_module.c # The panic-triggering module
│ └── Makefile # Kernel module makefile
├── scripts/
│ ├── setup_kdump.sh # Configure kdump
│ └── trigger_crash.sh # Load module and crash
├── docs/
│ └── procedure.md # Step-by-step documentation
└── analysis/
└── vmcore/ # Will contain vmcore after crash
5.3 The Core Question You’re Answering
“How does Linux capture the complete system state when the operating system itself has failed?”
The answer involves:
- Pre-reserving memory that survives the crash
- Having a second kernel ready to boot
- Using kexec to “jump” to the crash kernel without rebooting hardware
- Reading the original kernel’s memory while the crash kernel runs
5.4 Concepts You Must Understand First
- Kernel vs User Space
- Reference: “Linux Kernel Development” by Robert Love, Ch. 1
- How kernel modules work
- Reference: “Linux Device Drivers” by Corbet et al., Ch. 2
- What happens during a panic
- Reference: Linux kernel source:
kernel/panic.c
- Reference: Linux kernel source:
- kexec system call
- Reference:
man kexec, kernel documentation
- Reference:
- Memory layout during boot
- Reference: “Understanding the Linux Kernel” by Bovet & Cesati, Ch. 2
5.5 Questions to Guide Your Design
About the module:
- What’s the simplest way to cause a NULL pointer dereference?
- Should the panic happen immediately or after a delay?
- How will you know the module loaded before it panicked?
About kdump:
- How much memory should you reserve? (depends on total RAM)
- What happens if kdump isn’t properly configured?
- How do you verify kdump is ready before triggering a panic?
About safety:
- How will you recover if something goes wrong?
- What VM snapshot strategy will you use?
- How do you avoid accidentally running on the host?
5.6 Thinking Exercise
Before writing any code, draw a diagram showing:
- Memory layout at boot time showing reserved crashkernel area
- What happens to each memory region when panic occurs
- How the crash kernel reads the original kernel’s memory
- Where the vmcore data comes from
Also answer:
- Why can’t the panicked kernel save its own memory?
- Why does the crash kernel need its own reserved memory?
- What would happen if the crash kernel tried to use the same memory?
5.7 Hints in Layers
Hint 1 - Basic Module Structure:
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
static int __init buggy_init(void)
{
pr_info("buggy_module: Module loaded, about to crash...\n");
// TODO: Add panic trigger here
return 0;
}
static void __exit buggy_exit(void)
{
pr_info("buggy_module: Unloaded (you shouldn't see this)\n");
}
module_init(buggy_init);
module_exit(buggy_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("Deliberately buggy module for testing kdump");
Hint 2 - Triggering the Panic:
// Method 1: NULL pointer dereference
int *ptr = NULL;
*ptr = 42; // This will panic
// Method 2: Explicit panic
panic("Intentional panic for testing");
// Method 3: BUG macro
BUG(); // Unconditional panic with location info
Hint 3 - Makefile:
obj-m := buggy_module.o
KDIR := /lib/modules/$(shell uname -r)/build
all:
make -C $(KDIR) M=$(PWD) modules
clean:
make -C $(KDIR) M=$(PWD) clean
Hint 4 - kdump Configuration:
# Check crashkernel parameter
cat /proc/cmdline | grep crashkernel
# If not present, edit GRUB
sudo vim /etc/default/grub
# Add: GRUB_CMDLINE_LINUX="crashkernel=256M"
sudo update-grub
sudo reboot
# After reboot, enable kdump
sudo systemctl enable kdump
sudo systemctl start kdump
# Verify kdump is ready
sudo kdumpctl showmem # RHEL/Fedora
# or
sudo kdump-config show # Debian/Ubuntu
5.8 The Interview Questions They’ll Ask
- “Explain how kdump works”
- Expected: Describe reserved memory, kexec, crash kernel, memory preservation
- “Why can’t the crashed kernel save its own memory?”
- Expected: Crashed kernel is in unknown state, can’t trust its code paths
- “What is the difference between soft lockup and hard lockup?”
- Expected: Soft = process stuck, Hard = CPU stuck (no interrupts)
- “How does kexec differ from a normal reboot?”
- Expected: kexec jumps to new kernel without hardware reset
- “What happens if kdump fails to capture?”
- Expected: Discuss fallback mechanisms, dmesg buffer, serial console
- “Why might a kernel panic not trigger kdump?”
- Expected: Crash in NMI context, kdump not loaded, memory corruption
5.9 Books That Will Help
| Topic | Book | Chapter(s) |
|---|---|---|
| Kernel Modules | “Linux Device Drivers, 3rd Ed” - Corbet et al. | Ch. 2 |
| Kernel Panics | “Understanding the Linux Kernel” - Bovet & Cesati | Ch. 4 |
| Kernel Development | “Linux Kernel Development” - Robert Love | Ch. 1-5 |
| Debug Techniques | “Linux Kernel Debugging” - Liang & Prabhakar | All |
5.10 Implementation Phases
Phase 1: VM Setup (Days 1-3)
- Install VM with Linux
- Configure memory (at least 4GB)
- Install kernel development tools
- Take baseline snapshot
Phase 2: kdump Configuration (Days 4-6)
- Configure crashkernel parameter
- Install kdump tools
- Enable and test kdump service
- Verify crash kernel is loaded
Phase 3: Module Development (Days 7-10)
- Write minimal kernel module
- Test loading/unloading without crash
- Add panic trigger
- Document the module
Phase 4: Crash and Capture (Days 11-14)
- Take snapshot before crash
- Load the buggy module
- Verify panic and kdump capture
- Locate and verify vmcore
Phase 5: Documentation (Days 15-17)
- Document entire process
- Create reproducible scripts
- Prepare for Project 9 (analysis)
5.11 Key Implementation Decisions
-
Distro Choice: Use a distro you’re comfortable with (Debian/Ubuntu for beginners, Fedora for newer features)
-
Panic Method: NULL pointer dereference is most realistic;
panic()is most controlled -
Memory Reserve: 256M is usually enough; increase if capture fails
-
Serial Console: Consider enabling for debugging kdump issues
6. Testing Strategy
Pre-Crash Verification
# Verify kdump is loaded
kdumpctl status # Should show "Kdump is operational"
# Verify crashkernel memory is reserved
cat /proc/iomem | grep "Crash kernel"
# Should show something like:
# 2c000000-3bffffff : Crash kernel
# Verify crash kernel is loaded
cat /sys/kernel/kexec_crash_loaded
# Should output: 1
# Verify module compiles
cd /path/to/module
make
ls *.ko # Should show buggy_module.ko
Post-Crash Verification
# After reboot, check for vmcore
ls -la /var/crash/
# Verify vmcore is valid
file /var/crash/*/vmcore
# Should output: ELF 64-bit LSB core file, x86-64...
# Extract dmesg from vmcore
makedumpfile --dump-dmesg /var/crash/*/vmcore dmesg.txt
cat dmesg.txt | grep -i panic
Verification Checklist
- VM boots successfully with crashkernel parameter
- kdump service is active and operational
- Module compiles without errors
- Module loads (briefly) before crashing
- System kexecs to crash kernel
- vmcore is saved to /var/crash/
- vmcore-dmesg.txt shows panic message
- System reboots to normal state
7. Common Pitfalls & Debugging
Pitfall 1: kdump Not Operational
Problem: kdumpctl status shows “Kdump is not operational”
Causes:
- crashkernel not configured
- Not enough memory reserved
- kdump service not started
Solution:
# Check crashkernel
grep crashkernel /proc/cmdline
# If missing, configure it
sudo grubby --args="crashkernel=256M" --update-kernel=ALL
sudo reboot
# After reboot
sudo systemctl enable kdump
sudo systemctl start kdump
Pitfall 2: Module Won’t Compile
Problem: make fails with missing headers
Solution:
# Install matching kernel headers
sudo apt-get install linux-headers-$(uname -r)
# Verify headers exist
ls /lib/modules/$(uname -r)/build
Pitfall 3: No vmcore After Reboot
Problem: System panicked and rebooted but no vmcore file
Causes:
- kdump wasn’t fully loaded
- Crash kernel failed to boot
- makedumpfile failed
- Disk full
Solution:
- Check serial console output (if available)
- Verify /var/crash has enough space
- Try with SysRq magic key:
echo c > /proc/sysrq-trigger
Pitfall 4: Running on Host by Mistake
Problem: Commands executed on host instead of VM
CRITICAL Solution:
# ALWAYS verify you're in the VM before any kernel work
hostname # Should show VM name
df -h # Check disk size matches VM
cat /etc/hostname
# Add a distinctive prompt in VM
echo 'PS1="[VM] $PS1"' >> ~/.bashrc
8. Extensions & Challenges
Extension 1: Different Panic Types
Trigger different types of kernel errors:
- Stack overflow
- Deadlock (spinlock held too long)
- Use-after-free
- Memory corruption
Extension 2: Remote Crash Capture
Configure kdump to save vmcore to:
- NFS share
- SSH server
- Network block device
Extension 3: Minimal Crash Kernel
Build a custom minimal kernel for faster crash capture:
- Disable unnecessary drivers
- Reduce size
- Faster boot time
Extension 4: Panic Notifier
Write a module that registers a panic notifier:
static int my_panic_handler(struct notifier_block *nb,
unsigned long action, void *data)
{
pr_emerg("Custom panic handler called!\n");
return NOTIFY_DONE;
}
9. Real-World Connections
Enterprise Linux
Red Hat, SUSE, and Ubuntu all ship with kdump:
- Pre-configured in enterprise editions
- Required for kernel support cases
- Automated crash upload in some cases
Cloud Providers
AWS, Azure, GCP use kernel crash analysis:
- Host-level debugging for hypervisors
- Customer VM crash analysis (with consent)
- Automated crash classification
Kernel Development
Kernel developers rely on crash dumps:
- Reproducing hard-to-trigger bugs
- CI systems with crash testing
- Regression testing for patches
10. Resources
Official Documentation
Distribution-Specific Guides
Kernel Source References
kernel/panic.c- Panic implementationkernel/kexec.c- kexec implementationinclude/linux/crash_dump.h- Crash dump structures
11. Self-Assessment Checklist
Before You Start
- Comfortable with Linux system administration
- Understand basics of kernel vs user space
- Can compile and run C programs
- Have VM software installed and working
- Understand what a kernel module is
After Completion
- Can configure kdump on a Linux system
- Can write and load a simple kernel module
- Understand the kdump/kexec mechanism
- Can trigger a kernel panic safely
- Can locate and verify vmcore files
- Can extract dmesg from vmcore
- Ready for Project 9 (crash utility analysis)
12. Submission / Completion Criteria
Your project is complete when you can demonstrate:
- Configured kdump
- Show
kdumpctl statusoutput showing operational - Show crashkernel memory reservation
- Show
- Working Module
- Show module source code
- Demonstrate compilation
- Explain the panic trigger
- Captured vmcore
- Show vmcore file in /var/crash/
- Show vmcore-dmesg.txt with panic message
- Verify vmcore is valid ELF file
- Documentation
- Step-by-step procedure documented
- All commands recorded
- Troubleshooting notes from your experience
- Understanding
- Can explain how kdump works
- Can describe the kexec mechanism
- Ready to analyze vmcore in Project 9
Next: Project 9: Analyzing a Kernel Panic with crash - Dissect your vmcore