此外,Linux kdump service没有将核心转储写入/ var / crash的默认位置.

>你能帮我搞清楚为什么吗？
>我的根文件系统是LVM卷是否重要？

这是我尝试过的.

>我的系统是带有最新内核的Scientific Linux 6.5.

[root@host1 ~]# uname -r
2.6.32-431.11.2.el6.x86_64
[root@host1 ~]# cat /etc/issue
Scientific Linux release 6.5 (Carbon)

>文件/etc/kdump.conf是包含默认设置的vanilla文件.大多数行都被注释掉了,path和core_collector只有两个活动行.

#net my.server.com:/export/tmp
#net user@my.server.com
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31
#core_collector scp

>我确保kdump服务正在运行,并且kdump不需要重建我的initrd.

[root@host1 ~]# chkconfig --list kdump
kdump           0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@host1 ~]# /etc/init.d/kdump restart
Stopping kdump:                                            [  OK  ]
Starting kdump:                                            [  OK  ]
[root@host1 ~]#

>然后,我使用从RHEL6 Deployment Guide: Chapter 29. The kdump Crash Recovery Service借来的这些命令强制内核崩溃：

Then type the following commands at a shell prompt:

06003

This will force the Linux kernel to crash

>系统崩溃.我可以在串口控制台上查看进度.我看到消息保存到本地文件系统UUID = e7abcdeb-1987-4c69-a867-fabdceffghi2,但在此之后我立刻看到了一条奇怪的用法消息：fsck.ext4,这看起来像是在意外调用fsck而不是任何东西应该这样做.我没有提到内存不足或任何错误.

host1.example.org login: SysRq : Trigger a crash
BUG: unable to handle kernel NULL pointer dereference at (null)
...
... skipping 50 lines of output
...
Creating block device ram8
Creating block device ram9
Creating Remain Block Devices
Making device-mapper control node
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  No volume groups found
  No volume groups found
Activating logical volumes
  No volume groups found
  No volume groups found
Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2
Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
        [-I inode_buffer_blocks] [-P process_inode_size]
        [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
        [-E extended-options] device
 
Emergency help:
 -p                   Autom

>然后系统重新启动(这是默认设置).
>当系统重新联机时,/ var / crash中没有任何内容.我假设没有写入崩溃转储.

[root@host1 ~]# ls -lA /var/crash/
total 0
[root@host1 ~]#

>我知道崩溃转储可以正常工作.如果我告诉kdump将核心转储复制到具有以下配置的另一个系统,kdump将成功将核心转储写入另一个主机：

path vmcore
ssh user@hostb.example.org
sshkey /root/.ssh/kdump_id_rsa

>如果我在/etc/kdump.conf中设置默认shell并重建initrd,然后再次崩溃系统我得到一个关于mount的更多信息错误：在/ etc / fstab中找不到/ mnt

Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
Saving to the local filesystem UUID=e720481b-1987-4c69-a867-f2b4cba3b312
Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device
 
Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external_journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list
mount: can't find /mnt in /etc/fstab
dropping to initramfs shell
exiting this shell will reboot your system
/sys/block #

>但现在,我被困住了.