我有一个 Ubuntu 桌面系统，它经常崩溃（可能每 2-3 天一次？）。它最初运行的是 17.10（并且在此系统上崩溃），当 18.04 出来时，我以为升级可能会修复频繁崩溃的问题，但事实并非如此。
所以我想我会尝试按照本 Ubuntu 指南启用 kdump/linux-crashdump。按照指南中的步骤操作，一切似乎都正确无误（kdump-config show显示准备 kdump、dmesg | grep -i crash显示为崩溃转储保留内存等）。但是，当涉及到指南的“测试崩溃转储机制”部分时，崩溃成功触发，echo c > /proc/sysrq-trigger但该行Saving vmcore from kernel crash从未出现，系统也从未重新启动。即使我手动重新启动机器，也没有转储文件/var/crash（我确认这是崩溃文件应该所在的位置）。
我尝试将crashkernel大小从 128M（默认值）增加到 256M，这是我在某些 wiki/博客文章/其他内容上看到的建议，但这似乎也没有任何作用。
关于如何深入了解这些内核崩溃，您有什么想法吗？
作为参考，以下是指南中三个验证命令的输出：
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
$ dmesg | grep -i crash
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
[ 0.000000] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 65468MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-20-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-20-generic
current state: ready to kdump
kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash vt.handoff=1 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz