aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/brcm63xx/dts/vr-3026e.dts
diff options
context:
space:
mode:
authorDaniel Golle <daniel@makrotopia.org>2017-03-21 15:58:13 -0600
committerDaniel Golle <daniel@makrotopia.org>2017-06-09 22:21:25 +0200
commit5e4bb476c0cc46dedc020a802f045d479e483857 (patch)
tree21fa856ca68582dd0225e6c700a4867661117fc3 /target/linux/brcm63xx/dts/vr-3026e.dts
parent8b486ec2b52056b737a4ce64a2040a9a27a6bd60 (diff)
downloadupstream-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/brcm63xx/dts/vr-3026e.dts')
0 files changed, 0 insertions, 0 deletions