此外,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 #
>但现在,我被困住了.
