在Linux-PC上建立kdump调试环境

della0887

　　kdump就是kernel dump的简称，它是从DDR中直接获取的linux内核数据（系统代码／数据）。分析kdump是定位内核panic问题的有效手段之一，同时，通过kdump研究内核数据结构，也是学习和理解linux原理的好方法。本文将介绍如果在PC机上，针对当前运行的linux系统，建立起kdump调试环境。本文基于Ubuntu系统讲解。
1.系统符号表的获取
　　解析内核dump，首先需要符号表，也就是未经过压缩的内核镜像，通常我们也叫它vmlinux。通常系统默认并没有自带vmlinux，不过我们可以通过安装系统版本对应的debug包来获取它。
　　网上搜索了一下vmliux的安装方法，大部分文章都说要安装kernel-debug以及kernel-debug-info，不过后来发现这是redhat对应的安装包，需要手动下载rpm包安装。而在ubuntu下，对应的包名是dbgsym，同样需要手动下载deb包安装：
　　http://ddebs.ubuntu.com/pool/main/l/linux/
　　这里需要下载和当前内核版本对应的dbgsym包，使用uname -r可查看当前linux内核版本，本文使用的是4.4.0-87-generic版本的内核。下载对应的deb包后，使用“dpkg -I package.deb” 即可安装，安装完成后，如下路径即是vmlinux符号表：
　　/usr/lib/debug/boot/vmlinux-4.4.0-87-generic
2.Crash调试工具
　　kernel dump调试工具主要有Trace32和crash两个，trace32是商业软件，图形化界面，功能强大，但是收费。而crash则是开源工具，且基于命令行模式，但是功能并不逊于Trace32，本文选择crash。
　　安装方法：sudo apt-get install crash
　　详细的crash用法：
　　https://www.dedoimedo.com/computers/crash.html
3.直接调试当前运行内核
　　通常我们会在内核panic的时候，通过某种机制从内存中抓取内核数据，也就是kdump，然后通过trace32或crash工具来分析它。不过在介绍kdump的获取方法之前，我们先看看如何直接调试内存中的内核，也就是说分析对象不是导出来的kdump文件，而是当前的物理内存。其实很简单，crash工具启动时如果不给它传递kdump文件，那么它默认就是调试当前内存中的内核。su root，然后直接在命令行输入：crash vmlinux-4.4.0-87-generic



现在就可以使用crash来探索内核世界了，常用的crash命令：
help -- 打印第一级帮助信息
help cmd -- 打印cmd命令的具体帮助信息
ps -- 打印当前进程列表，类似shell下单ps
runq -- 打印当前cpu的运行队列信息
task pid -- 显示任务pid的task_struct结构体信息
在我们阅读linux内核书籍的时候，如果结合crash工具直接查看内核数据结构，是不是很酷？笔者一直认为，从数据结构出发，才是学习linux的正道！


4.生成kdump文件
　　很多时候，尤其是定位内核panic问题的时候，我们需要在内核崩溃时，保存DDR中的内核数据到文件，用于事后分析，这就是所谓的kdump文件。
　　在ubuntu系统中，通过安装linux-crashdump工具，我们可以捕捉kdump。Kdump是一个Linux内核崩溃转储机制，这个机制的原理是在内存中保留一块区域，这块区域用来存放capture kernel，当前的内核发生crash后，通过kexec把保留区域的capture kernel运行起来，由capture kernel负责把crash kernel的完整信息--包括CPU寄存器、堆栈数据等--转储到文件中，文件的存放位置可以是本地磁盘，也可以是网络。具体kdump的使用方法可参考如下链接：http://blog.csdn.net/maokexu123/article/details/40829459
　　配置完kdump后，我们需要做的就是在当前系统中主动触发一次panic，以获取kdump文件。方法是使用sysrq-trigger节点：
　　echo c > /proc/sysrq-trigger

在ubuntu以及debian上尝试，发现触发后系统一直刮死，并没有重启
网上找到的设置是：
vi /etc/sysctl.conf
#增加此行,以保证此设置持续有效;
#含义是当系统遇到kernel panic时,系统在30秒后reboot;
kernel.panic = 30

#修改此参数,,以保证下一次当系统遇到kernel panic后有效;
#以后无需再修改,默认从上面的设置中加载;
vi /proc/sys/kernel/panic
echo 30 > panic

设置后貌似可以重启了，但是，重启的时候好像卡住了
会不会是captrue内核有问题？
我们把kdump服务停掉：
service kdump-tools stop
再次触发panic，发现成功重启了
说明是真capture内核捕获kernel dump的时候卡死了

等这个问题解决了，再继续更新本文