capture kernel：捕捉內核
production kernel：生產內核
crash：崩潰
kexec_load：內核空間的系統調用，負責在生產內核啓動時將捕獲內核加載到指定地址。
kexec-tools：用戶空間的工具，將捕獲內核的地址傳遞給生產內核，從而在系統崩潰的時候找到捕獲內核的地址並運行。
kexec：內核崩潰轉儲機制
ramdisk：虛擬內存盤，是通過軟件將一部分內存(RAM)模擬爲硬盤來使用的一種技術。所謂的RAM驅動器，實際上是把系統內存劃出一部分當作硬盤使用。對於操作系統來講內存的存取速度遠遠大於機械磁盤，所以RAM驅動器肯定要比機械的硬盤快得多。
system pancis :系統宕機
grub :多操作系統啓動程序
grub.conf是grub的主配置文件，通過這個配置文件，grub才能找到kernel，系統才能正常啓動,其中關鍵字：
kernel：用於指定系統的內核文件的位置
initrd：幫助kernel完成系統的啓動，例如加載根文件系統所在分區的驅動等。如果kernel本身有相應強大的功能，則不需要initrd
crashkernel=Y@X，Y是爲kdump捕獲內核保留的內存，X是保留部分內存的起始位置。
默認爲crashkernel=auto，可自行設定如crashkernel=256M
/etc/grub.conf (一般爲/boot/grub/grub.conf的軟鏈接)
安裝kexec-tools 時會修改grub(/boot/grub/grub.cfg),增加以下參數
crashker nel=384M-2G:64M,2G-:128M
crashkernel用來指定保留內存的大小，我們可以知道crashkernel幫我們設定的保留區域的大小是：如果內存小於384M，不保留內存；如果內存大於等於384M但小於2G，保留64M；如果內存大於2G，保留128M。
我的電腦自動添加：
crashkernel=384M-:128M
kdump簡介
kdump是系統崩潰的時候，用來轉儲運行內存的一個工具。
kdump是RHEL5之後才支持的，2006被主線接收爲內核的一部分，是迄今爲止最可靠的內核轉存機制，已經被主要的 linux 廠商選用。kdump 是一種先進的基於 kexec 的內核崩潰轉儲機制。當系統崩潰時，kdump 使用 kexec 啓動到第二個內核。第二個內核通常叫做捕獲內核，以很小內存啓動以捕獲轉儲鏡像。第一個內核保留了內存的一部分給第二內核啓動用。由於 kdump 利用 kexec 啓動捕獲內核，繞過了 BIOS，所以第一個內核的內存得以保留。這是內核崩潰轉儲的本質。
kdump 需要兩個不同目的的內核，生產內核和捕獲內核。生產內核是捕獲內核服務的對像。捕獲內核會在生產內核崩潰時通過kexec啓動起來，負責把產品內核的完整信息 - 包括CPU寄存器、堆棧數據等轉儲到指定位置的文件,與相應的 ramdisk 一起組建一個微環境，用以對生產內核下的內存進行收集和轉存。
kdump機制主要包括兩個組件：kdump和kexec
kexec是一個快速啓動機制，允許通過已經運行的內核的上下文啓動一個Linux內核，不需要經過BIOS。BIOS可能會消耗很多時間，特別是帶有衆多數量的外設的大型服務器。這種辦法可以爲經常啓動機器的開發者節省很多時間。Kexec是實現kdump機制的關鍵，它包括2個組成部分：一是內核空間的系統調用kexec_load，負責在生產內核（production kernel 或 first kernel）啓動時將捕獲內核（capture kernel或sencond kernel）加載到指定地址。二是用戶空間的工具kexec-tools，他將捕獲內核的地址傳遞給生產內核，從而在系統崩潰的時候能夠找到捕獲內核的地址並運行。沒有kexec就沒有kdump。先有kexec實現了在一個內核中可以啓動另一個內核，才讓kdump有了用武之地。
kdump是一種先進的基於kexec的內核崩潰轉儲機制。當系統崩潰時，kdump使用kexec 啓動到第二個內核。第二個內核通常叫做捕獲內核，以很小內存啓動以捕獲轉儲鏡像。第一個內核保留了內存的一部分給第二內核啓動用。由於kdump利用kexec啓動捕獲內核，繞過了 BIOS，所以第一個內核的內存得以保留。這是內核崩潰轉儲的本質。kdump需要兩個不同目的的內核，生產內核和捕獲內核。生產內核是捕獲內核服務的對像。捕獲內核會在生產內核崩潰時啓動起來，與相應的ramdisk一起組建一個微環境，用以對生產內核下的內存進行收集和轉存。注意，在啓動時，kdump保留了一定數量的重要的內存，爲了計算系統需要的真正最小內存，加上kdump使用的內存數量，以決定真正的最小內存的需求。
kexec和kdump的設計區別：
Kexec的設計是用新內核去覆蓋原內核位置；而KDUMP是預留一塊內存來加載第二個內核(和相關數據)，Crash後第二個內核在原位置運行(不然就達不到相關目的了)，收集第一個內核的相關內存信息
如何使用 kdump
構建系統和 dump-capture 內核，此操作有 2 種方式可選：
1）構建一個單獨的自定義轉儲捕獲內核以捕獲內核轉儲；
2）將系統內核本身作爲轉儲捕獲內核，這就不需要構建一個單獨的轉儲捕獲內核。
方法（2）只能用於可支持可重定位內核的體系結構上；目前 i386，x86_64，ppc64 和 ia64 體系結構支持可重定位內核。構建一個可重定位內核使得不需要構建第二個內核就可以捕獲轉儲。但是可能有時想構建一個自定義轉儲捕獲內核以滿足特定要求。
捕獲內核啓動後，會像一般內核一樣，去運行爲它創建的ramdisk上的init程序。而各種轉儲機制都可以事先在init中實現。
爲了在生產內核崩潰時能順利啓動捕獲內核，捕獲內核以及它的ramdisk是事先放到生產內核的內存中的。
生產內核的內存是通過/proc/vmcore這個文件交給捕獲內核的。爲了生成它，用戶工具在生產內核中分析出內存的使用和
分佈等情況，然後把這些信息綜合起來生成一個ELF頭文件保存起來。捕獲內核被引導時會被同時傳遞這個ELF文件頭的
地址，通過分析它，捕獲內核就可以生成出/proc/vmcore。有了/proc/vmcore這個文件，捕獲內核的ramdisk中的腳本就
可以通過通常的文件讀寫和網絡來實現各種策略了
kdump優勢：
崩潰轉儲數據可從一個新啓動的捕獲內核的上下文中獲取，而不是從已經崩潰內核的上下文。但是如何具體實現在生產內核中獲取。
如何訪問捕獲內存
在內核崩潰之前所有關於核心映像的必要信息都用 ELF 格式編碼並存儲在保留的內存區域中。ELF 頭所在的物理地址被作爲命令行參數（fcorehdr=）傳遞給新啓動的轉儲內核。
在 i386 體系結構上，啓動的時候需要使用物理內存開始的 640K，而不管操作系統內核轉載在何處。因此，這個 640K 的區域在重新啓動第二個內核的時候由 kexec 備份。
在第二個內核中，“前一個系統的內存”可以通過兩種方式訪問：
1. 通過 /dev/oldmem 這個設備接口。
一個“捕捉”設備可以使用“raw”（裸的）方式 “讀”這個設備文件並寫出到文件。這是關於內存的 “裸”的數據轉儲，同時這些分析 / 捕捉工具應該足夠“智能”從而可以知道從哪裏可以得到正確的信息。ELF 文件頭（通過命令行參數傳遞過來的 elfcorehdr）可能會有幫助。
2. 通過 /proc/vmcore。
kdump原理圖：待補
Ubuntu實踐：
sudo apt-get install linux-crashdump kexec-tools crash # uname -r 3.13.0-32-generic 下載dbgsym，用來調試內核信息 wagt 'http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-3.13.0-32-generic-dbgsym_3.13.0-32.57_amd64.ddeb' dpkg -i linux-image-3.13.0-32-generic-dbgsym_3.13.0-32.57_amd64.ddeb vim /etc/init.d/kdump-tools:可見 VMCORE_FILE=/proc/vmcore KDUMP_SCRIPT=/usr/sbin/kdump-config KDUMP_DEFAULTS=/etc/default/kdump-tools 修改kdump配置文件(/etc/default/kdump-tools)： USE_KDUMP=1
心態爆炸，ubuntu下完全啓動不了。
開機panic：Gave up waiting for root device.
嘗試修改rootdelay時間和將root=UUID改爲root=/dev/sda1還是不行，後天在fedora上嘗試一下，去年的時候fedora上是成功的，不行的話看來又是一場苦戰。
明天去南京看漫站，舒服，順便帶一個卡卡西的手辦給老姐。
難受，fedora下4.15.16內核下可以通過shell命令生成vmcore文件，但是我之前在編譯內核的時候沒有選擇kdump，網上對應的debuginfo包又找不到。
4.15.7內核編譯的時候有選擇kdump，所以有現成的vmlinux，但是通過echo 1 > ..., echo c >..這種方式生不成vmcore文件，嘗試了好幾次，已經分配crashkernel內存,kdump也跑起來了，但是就是崩潰沒有轉儲文件。。