如何在x86虛擬機(jī)上使用ramoops和kdump記錄內(nèi)核crash信息

這篇文章主要介紹“如何在x86虛擬機(jī)上使用ramoops和kdump記錄內(nèi)核crash信息”，在日常操作中，相信很多人在如何在x86虛擬機(jī)上使用ramoops和kdump記錄內(nèi)核crash信息問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”如何在x86虛擬機(jī)上使用ramoops和kdump記錄內(nèi)核crash信息”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

1.ramoops

ramoops是一個(gè)oops/panic記錄器(logger)，它能夠在系統(tǒng)崩潰前將日志信息記錄到RAM中。ramoops需要一個(gè)帶有持久的(persistent)RAM，因此這些內(nèi)存區(qū)域中的內(nèi)容在重啟后能夠保留。

ramoops能夠以模塊的形式編譯，為了方便，我直接編進(jìn)內(nèi)核。需要開(kāi)啟的配置宏如下：

CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_RAM=y
# CONFIG_PSTORE_PMSG is not set 推薦開(kāi)啟
# CONFIG_PSTORE_FTRACE is not set 推薦開(kāi)啟

使用VirtualBox，即使配置正確下，內(nèi)核crash后也不會(huì)在/sys/fs/pstore目錄下生成相應(yīng)的記錄文件（這個(gè)非?？樱?，因此我在VMware上搭建環(huán)境。配置2G的內(nèi)存。根據(jù)官方文檔，有三種使用ramoops的方法：ramoops官方文檔，我們之間使用第一種，即通過(guò)向kernel傳遞啟動(dòng)參數(shù)的方式：修改/boot/grub/grub.cfg文件，增加如下參數(shù)：

mem=1920M ramoops.mem_address=0x78000000 ramoops.mem_size =0x4000000 ramoops.dump_oops=1 ramoops.ecc=1

其中，mem是給內(nèi)核使用的大小，mem_address表示ramoops使用的起始內(nèi)存，mem_size 表示這個(gè)預(yù)留內(nèi)存的大小，dump_oops=1表示oopses和panics均記錄，ecc=1表示ECC-protected，具體可見(jiàn)官方文檔。在配置好啟動(dòng)參數(shù)后，重啟生效。

系統(tǒng)重啟后，我們故意讓內(nèi)核crash，執(zhí)行如下命令：

echo c > /proc/sysrq-trigger

系統(tǒng)就會(huì)crash，之后就會(huì)重啟。進(jìn)入shell下，查看/sys/fs/pstore下，會(huì)有相應(yīng)的記錄文件。當(dāng)前是console-ramoops-0和dmesg-ramoops-1文件，內(nèi)容如下：

console-ramoops-0
[  120.719799] CPU: 0 PID: 7475 Comm: sh Tainted: G           O    4.9.166+ #2
[  120.719942] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[  120.720192] task: ffff96770c862240 task.stack: ffffba30c4a80000
[  120.720324] RIP: 0010:[<ffffffffac832702>]  [<ffffffffac832702>] sysrq_handle_crash+0x12/0x20
[  120.720533] RSP: 0018:ffffba30c4a83e78  EFLAGS: 00010282
[  120.720680] RAX: 000000000000000f RBX: 0000000000000063 RCX: 0000000000000000
[  120.720819] RDX: 0000000000000000 RSI: ffff96771ba10648 RDI: 0000000000000063
[  120.720962] RBP: ffffffffad0bffc0 R08: 0000000000000001 R09: 0000000000059284
[  120.721131] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000004
[  120.721278] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  120.721421] FS:  0000000001ea0880(0000) GS:ffff96771ba00000(0000) knlGS:0000000000000000
[  120.721618] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  120.721745] CR2: 0000000000000000 CR3: 000000004cb84000 CR4: 0000000000360670
[  120.721911] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  120.722108] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  120.722256] Stack:
[  120.722331]  ffffffffac832e31 0000000000000002 fffffffffffffffb ffffba30c4a83f08
[  120.722604]  0000000001ea4f00 ffffffffac83326b ffff9676f3effdd8 ffffffffac67c0dd
[  120.722849]  0000000000000002 ffff96770ffc8880 ffffffffac60cba0 ffff96770ffc8880
[  120.723105] Call Trace:
[  120.723188]  [<ffffffffac832e31>] ? __handle_sysrq+0xf1/0x140
[  120.723316]  [<ffffffffac83326b>] ? write_sysrq_trigger+0x2b/0x30
[  120.723443]  [<ffffffffac67c0dd>] ? proc_reg_write+0x3d/0x60
[  120.723640]  [<ffffffffac60cba0>] ? vfs_write+0xb0/0x190
[  120.723761]  [<ffffffffac60dfe2>] ? SyS_write+0x52/0xc0
[  120.723882]  [<ffffffffac403b67>] ? do_syscall_64+0x87/0xf0
[  120.724002]  [<ffffffffaca36c4e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[  120.724167] Code: 41 5c 41 5d 41 5e 41 5f e9 0c 8a ce ff 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 00 c7 05 c9 45 94 03 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 0f 1f 44 00 00 53 8d
[  120.725651] RIP  [<ffffffffac832702>] sysrq_handle_crash+0x12/0x20
[  120.725801]  RSP <ffffba30c4a83e78>
[  120.725894] CR2: 0000000000000000
[  120.726019] ---[ end trace 9d0e2c84273289ed ]---
[  120.730468] Kernel panic - not syncing: Fatal exception
[  120.730706] Kernel Offset: 0x2b400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  120.735485] Rebooting in 5 seconds..
[  125.739764] ACPI MEMORY or I/O RESET_REG.
 
No errors detected

===============================
dmesg-ramoops-1
<4>[    5.718737] hrtimer: interrupt took 9700 ns
<6>[    6.096115] igb_uio: Use MSIX interrupt by default
<3>[    6.169775] EXT4-fs (sda2): unable to read superblock
<3>[    6.170072] EXT4-fs (sda2): unable to read superblock
<3>[    6.170081] EXT4-fs (sda2): unable to read superblock
<6>[    6.695732] device eth0 entered promiscuous mode
<6>[    6.697183] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
<0>[   12.596101] TIPC: Started in network mode
<0>[   12.596217] TIPC: Own node identity 1001285, cluster identity 4711
<0>[   12.596345] TIPC: 32-bit node address hash set to 1001285
<0>[   12.638127] TIPC: Enabled bearer <eth:eth0>, priority 10
<0>[   18.791882] TIPC: Resetting bearer <eth:eth0>
<6>[   23.124506] ip_tables: (C) 2000-2006 Netfilter Core Team
<6>[   23.623557] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
<6>[   24.067819] Initializing XFRM netlink socket
<6>[   24.087773] Netfilter messages via NETLINK v0.30.
<6>[   24.522481] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
<6>[  120.714716] sysrq: SysRq : Trigger a crash
<1>[  120.714869] BUG: unable to handle kernel NULL pointer dereference at           (null)
<1>[  120.715080] IP: [<ffffffffac832702>] sysrq_handle_crash+0x12/0x20
<7>[  120.715239] PGD 800000004fe74067
<7>[  120.715296] PUD 4fe07067
<7>[  120.715393] PMD 0
<7>[  120.715417]
<7>[  120.715497] Oops: 0002 [#1] SMP
<7>[  120.715587] Modules linked in: 
<7>[  120.718151]  mii mtd sd_mod ata_piix ahci libahci libata scsi_mod sdhci_pci sdhci mmc_block mmc_core squashfs vfat fat ext4 crc16 fscrypto jbd2 mbcache
<7>[  120.719799] CPU: 0 PID: 7475 Comm: sh Tainted: G           O    4.9.166+ #2
<7>[  120.719942] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
<7>[  120.720192] task: ffff96770c862240 task.stack: ffffba30c4a80000
<7>[  120.720324] RIP: 0010:[<ffffffffac832702>]  [<ffffffffac832702>] sysrq_handle_crash+0x12/0x20
<7>[  120.720533] RSP: 0018:ffffba30c4a83e78  EFLAGS: 00010282
<7>[  120.720680] RAX: 000000000000000f RBX: 0000000000000063 RCX: 0000000000000000
<7>[  120.720819] RDX: 0000000000000000 RSI: ffff96771ba10648 RDI: 0000000000000063
<7>[  120.720962] RBP: ffffffffad0bffc0 R08: 0000000000000001 R09: 0000000000059284
<7>[  120.721131] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000004
<7>[  120.721278] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
<7>[  120.721421] FS:  0000000001ea0880(0000) GS:ffff96771ba00000(0000) knlGS:0000000000000000
<7>[  120.721618] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<7>[  120.721745] CR2: 0000000000000000 CR3: 000000004cb84000 CR4: 0000000000360670
<7>[  120.721911] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<7>[  120.722108] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
<7>[  120.722256] Stack:
<7>[  120.722331]  ffffffffac832e31 0000000000000002 fffffffffffffffb ffffba30c4a83f08
<7>[  120.722604]  0000000001ea4f00 ffffffffac83326b ffff9676f3effdd8 ffffffffac67c0dd
<7>[  120.722849]  0000000000000002 ffff96770ffc8880 ffffffffac60cba0 ffff96770ffc8880
<7>[  120.723105] Call Trace:
<7>[  120.723188]  [<ffffffffac832e31>] ? __handle_sysrq+0xf1/0x140
<7>[  120.723316]  [<ffffffffac83326b>] ? write_sysrq_trigger+0x2b/0x30
<7>[  120.723443]  [<ffffffffac67c0dd>] ? proc_reg_write+0x3d/0x60
<7>[  120.723640]  [<ffffffffac60cba0>] ? vfs_write+0xb0/0x190
<7>[  120.723761]  [<ffffffffac60dfe2>] ? SyS_write+0x52/0xc0
<7>[  120.723882]  [<ffffffffac403b67>] ? do_syscall_64+0x87/0xf0
<7>[  120.724002]  [<ffffffffaca36c4e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
<7>[  120.724167] Code: 41 5c 41 5d 41 5e 41 5f e9 0c 8a ce ff 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 00 c7 05 c9 45 94 03 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 0f 1f 44 00 00 53 8d
<1>[  120.725651] RIP  [<ffffffffac832702>] sysrq_handle_crash+0x12/0x20
<7>[  120.725801]  RSP <ffffba30c4a83e78>
<7>[  120.725894] CR2: 0000000000000000
<4>[  120.726019] ---[ end trace 9d0e2c84273289ed ]---
<0>[  120.730468] Kernel panic - not syncing: Fatal exception
<0>[  120.730706] Kernel Offset: 0x2b400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
 
No errors detected

可以看到，這次panic由system request導(dǎo)致。

2.kdump使用

每當(dāng)system kernel(工作內(nèi)核)的內(nèi)存需要dump時(shí)(如系統(tǒng)panic)，kdump便使用kexec快速啟動(dòng)(繞過(guò)BIOS檢查)一個(gè)捕獲dump(dump-capture)的內(nèi)核。在啟動(dòng)第二個(gè)內(nèi)核時(shí)，工作內(nèi)核的所有信息(memory image)被保留，并且能夠被啟動(dòng)的捕獲內(nèi)核獲取。

在x86-64上需要開(kāi)啟的配置宏：(其實(shí)分為system kernel和dump-capture kernel，具體看官方文檔；我們僅用一個(gè)kernel：?jiǎn)?dòng)的捕獲內(nèi)核仍為工作內(nèi)核)

CONFIG_KEXEC=y
CONFIG_SYSFS=y
CONFIG_DEBUG_INFO=Y  #dump分析工具需要帶有vmlinux的符號(hào)表
CONFIG_CRASH_DUMP=y
CONFIG_PROC_VMCORE=y
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_START=0x1000000  #加載內(nèi)核的內(nèi)存區(qū)域起點(diǎn)
CONFIG_SMP=n #該配置為捕獲內(nèi)核配置項(xiàng)，我們?nèi)匀婚_(kāi)啟，修改kernel啟動(dòng)參數(shù)即可

在重新編譯內(nèi)核后，我們需要修改system kernel的起動(dòng)參數(shù)，為捕獲kernel預(yù)留一定的內(nèi)存，當(dāng)前預(yù)留512M，修改/boot/grub/grub.cfg增加如下：

crashkernel=512M@16M

重新啟動(dòng)后生效，此時(shí)我們便需要編譯kexec工具， 我們?cè)趕hell下執(zhí)行如下命令即可：

kexec -p /boot/vmlinux-4.9.xxx --initrd=/boot/initrd-4.9.166.xxx --append="1 irqpoll maxcpus=1 reset_devices noapic recovery" --reuse-cmdline

然后，當(dāng)kernel崩潰后，就會(huì)加載捕獲內(nèi)核，系統(tǒng)啟動(dòng)后，生成/proc/vmcore文件，將其拷貝至其它目錄后重啟，使用kexec-x86/sbin/vmcore-dmesg或者gdb調(diào)試該文件即可。

到此，關(guān)于“如何在x86虛擬機(jī)上使用ramoops和kdump記錄內(nèi)核crash信息”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！