diff options
author | Daniel Golle <daniel@makrotopia.org> | 2017-03-21 15:58:13 -0600 |
---|---|---|
committer | Daniel Golle <daniel@makrotopia.org> | 2017-06-09 22:21:25 +0200 |
commit | 5e4bb476c0cc46dedc020a802f045d479e483857 (patch) | |
tree | 21fa856ca68582dd0225e6c700a4867661117fc3 /target/linux/generic/patches-4.9/271-uapi-libc-compat.h-do-not-rely-on-__GLIBC__.patch | |
parent | 8b486ec2b52056b737a4ce64a2040a9a27a6bd60 (diff) | |
download | upstream-5e4bb476c0cc46dedc020a802f045d479e483857.tar.gz upstream-5e4bb476c0cc46dedc020a802f045d479e483857.tar.bz2 upstream-5e4bb476c0cc46dedc020a802f045d479e483857.zip |
kexec-tools: bump version and add support for crashdump kernel
split kexec-tools into two packages, kexec and kdump.
* kexec to simply execute a new kernel
* kdump is for loading and collecting debris of a crashed kernel with
support for kdump forensics.
In order to properly support booting into a crashkernel, an init script
as well as UCI configuration has been added.
As modifying the kernel cmdline is required for this to work in x86
platforms use an uci-defaults script to modify /boot/grub/grub.cfg.
To test collecting crash information, use the 'c' sysrq-trigger, ie.
echo c > /proc/sysrq-trigger
This should result in the crash kernel being executed and (depending
on the configution) dmesg and/or vmcore getting saved.
To check if the crash kernel was loaded properly, use the 'status'
command of the kdump init script.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Diffstat (limited to 'target/linux/generic/patches-4.9/271-uapi-libc-compat.h-do-not-rely-on-__GLIBC__.patch')
0 files changed, 0 insertions, 0 deletions