I have setup kdump to help me diagnose a kernel crash (per redhat docs). I've gotten as far as creating the dump file, and now want to examine the crash dump file. The instructions say to execute (for example): crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore But I don't have a vmlinux file. I looked int the directory matching my kernel **( /usr/lib/modules/5.14.0-427.37.1.el9_4.x86_64+debug)** and it contains the content shown below. But no vmlinux file! I have a vmlinuz but the crash program didn't like it. Where do I find this vmlinux file, or do I have to create it? lrwxrwxrwx. 1 root root 51 Sep 24 17:25 build -> /usr/src/kernels/5.14.0-427.37.1.el9_4.x86_64+debug -rw-r--r--. 1 root root 224287 Sep 24 17:25 config drwxr-xr-x. 14 root root 156 Oct 5 08:18 kernel -rw-r--r--. 1 root root 879087 Oct 5 08:19 modules.alias -rw-r--r--. 1 root root 834103 Oct 5 08:19 modules.alias.bin -rw-r--r--. 1 root root 461 Sep 24 17:25 modules.block -rw-r--r--. 1 root root 9236 Sep 24 17:25 modules.builtin -rw-r--r--. 1 root root 0 Oct 5 08:19 modules.builtin.alias.bin -rw-r--r--. 1 root root 11585 Oct 5 08:19 modules.builtin.bin -rw-r--r--. 1 root root 75121 Sep 24 17:25 modules.builtin.modinfo -rw-r--r--. 1 root root 307245 Oct 5 08:19 modules.dep -rw-r--r--. 1 root root 400740 Oct 5 08:19 modules.dep.bin -rw-r--r--. 1 root root 387 Oct 5 08:19 modules.devname -rw-r--r--. 1 root root 155 Sep 24 17:25 modules.drm -rw-r--r--. 1 root root 20 Sep 24 17:25 modules.modesetting -rw-r--r--. 1 root root 1648 Sep 24 17:25 modules.networking -rw-r--r--. 1 root root 93145 Sep 24 17:25 modules.order -rw-r--r--. 1 root root 862 Oct 5 08:19 modules.softdep -rw-r--r--. 1 root root 499371 Oct 5 08:19 modules.symbols -rw-r--r--. 1 root root 591632 Oct 5 08:19 modules.symbols.bin lrwxrwxrwx. 1 root root 5 Sep 24 17:25 source -> build -rw-r--r--. 1 root root 404401 Sep 24 17:25 symvers.gz -rw-------. 1 root root 9446409 Sep 24 17:25 System.map drwxr-xr-x. 2 root root 6 Sep 24 17:24 systemtap drwxr-xr-x. 2 root root 6 Sep 24 17:25 updates drwxr-xr-x. 2 root root 40 Oct 5 08:18 vdso -rwxr-xr-x. 1 root root 27304248 Sep 24 17:25 vmlinuz drwxr-xr-x. 2 root root 6 Oct 5 08:19 weak-updates

I want to understand is the UN and D process state is the same? During the analysis of vmcore (crash dump) I have found lots of UN state processes. And when I googled it I hardly found any document on the UN state but found D state document. Can someone please let me know if UN and D state is the same? OS is Redhat 7 104 2 6 ffff8817ee65a400 **UN** 0.0 0 0 [sync_supers] 14678 1 9 ffff8810854d8440 **UN** 0.1 535472 157188 ohasd.bin 14803 1 20 ffff8828b6ebe5c0 **UN** 0.0 372100 34420 evmd.bin

I'm using kexec-tools to get a crash dump of kernel on kernel panic. However, when I trigger the panic using sysrq-trigger, the system freezes. I have to power off and then power on to restore the system. There is no automatic reboot and no crash dump is available in /var/crash. The following are the configurations and details: - Linux Distro - Debian Buster arm64 - Linux Kernel - 4.19.35 - kexec-tools v2.0.22 (Built from source) - All Kernel Configs specifed here for arm64 enabled: https://www.kernel.org/doc/Documentation/kdump/kdump.txt Both the main kernel and crash kernel are exactly the same. (Although using uncompressed Image as crash kernel) /proc/cmdline = crashkernel=512M nokaslr # Along with other arguments The crash kernel space gets reserved (verified by dmesg) Loading crashkernel to kick-in on a kernel panic: $ sudo kexec -p ./Image --append=" root=/dev/sda1 console=same_as_main_kernel earlycon=same_as_main_kernel rootwait rw 1 max_cpus=1 reset_devices The root fs is same as that used for main kernel. Trigerring Kernel Panic: $ echo c | sudo tee /proc/sysrq-triggger The serial console freezes with standard kernel panic stacktrace. One of the logs specific to Kdump is: [14645.1099571] CPU: 2 PID: 20518 Comm: tee Kdump: loaded Not tainted 4.19.35-g9e41bb234b42 #2 The system however does not reboot. One thing to note is that I can boot into the crash kernel if I want to explicitly: $ sudo kexec -l ./Image --append=" root=/dev/sda1 console=same_as_main_kernel earlycon=same_as_main_kernel rootwait rw 1 max_cpus=1 reset_devices $ sudo kexec -e This boots into the specified kernel. How can I resolve/debug this issue further in which the crash kernel does not seem to kick-in in the event of a kernel panic.

I am trying to collect a core dump in result of kernel panic. Installed and configured kdump, but when executing echo c > /proc/sysrq-trigger, everything just hangs and the reboot doesn't happen. I don't even get any output in the result of running the command. RAM size is 4GB. The following is the output of `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.9.0-dev kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.9.0-dev current state: ready to kdump kexec command: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.9.0-dev root=UUID=b395d695-7bb2-408b-a61b-b5188fc5b900 ro resume=UUID=19e8dc56-ff6d-40de-84ec-b9abd7399591 debug net.ifnames=0 biosdevname=0 ignore_loglevel intel_iommu=on,igfx_off intremap=no_x2apic_optout irqpoll noirqdistrib nr_cpus=1 nousb systemd.unit=kdump-tools.service" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz Ubuntu 16.04. Kernel 4.9.0

I have changed the path in kdump.conf from

/var/crash

to

/home/crash/kdump

. System is AlmaLinux 8. After triggering a crash with

c > /proc/sysrq-trigger

, the crash dump in still placed in the

/var/crash

folder. When I checked the kdump.conf file, everything has been cleared from the file. It becomes a blank file.

I have generated a vmcore file using kdump and are now supposed to analyze it. First would be getting the dmesg logs from the core dump. This should be done with: vmcore-dmesg vmcore This however does not seem to work as there is the error: Missing the log_buf symbol Could someone know how to get around this error? Any help would be much appreciated.

I wanted to migrate to CentOS 7.5 from CentOS 6.9. during installation I saw an option kdump that i could enable or disable. I wonder what is kdump and disabling it has any bad effect on server? I want to install database on my server later I just want to make sure that kdump cause no problem.

## Issue kdump.service fails to start on CentOS 8 virtual machine on Google Cloud. Restarting the service keeps reproducing the same error. It seems the secure boot is causing the issue or is at least related to it. Required key cannot be loaded. The [solution](https://unix.stackexchange.com/a/267975/438103) for CentOS 7 does not solve the issue. Packages kexec-tools, crash , and kernel-debug are installed. How do I solve this issue? Thank you. Below are technical details. *** ## Environment - CentOS 8 virtual machine instance on Google Cloud - OS version: CentOS Linux release 8.2.2004 (Core) - Kernel version: 4.18.0-193.19.1.el8_2.x86_64 ## Details systemctl status kdump.service outputs:

kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2020-10-19 23:18:32 UTC; 2min 2s ago
  Process: 131082 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
 Main PID: 131082 (code=exited, status=1/FAILURE)

Oct 19 23:18:28 my_hostname systemd: Starting Crash recovery kernel arming...
Oct 19 23:18:32 my_hostname kdumpctl: Secure Boot is enabled. Using kexec file based syscall.
Oct 19 23:18:32 my_hostname kdumpctl: kexec_file_load failed: Required key not available
Oct 19 23:18:32 my_hostname kdumpctl: kexec: failed to load kdump kernel
Oct 19 23:18:32 my_hostname kdumpctl: Starting kdump: [FAILED]
Oct 19 23:18:32 my_hostname systemd: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 23:18:32 my_hostname systemd: kdump.service: Failed with result 'exit-code'.
Oct 19 23:18:32 my_hostname systemd: Failed to start Crash recovery kernel arming.

journalctl -xe outputs:

Oct 19 23:18:32 my_hostname kdumpctl: Secure Boot is enabled. Using kexec file based syscall.
Oct 19 23:18:32 my_hostname kdumpctl: kexec_file_load failed: Required key not available
Oct 19 23:18:32 my_hostname kdumpctl: kexec: failed to load kdump kernel
Oct 19 23:18:32 my_hostname kdumpctl: Starting kdump: [FAILED]
Oct 19 23:18:32 my_hostname systemd: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 23:18:32 my_hostname systemd: kdump.service: Failed with result 'exit-code'.
Oct 19 23:18:32 my_hostname systemd: Failed to start Crash recovery kernel arming.
-- Subject: Unit kdump.service has failed
-- Defined-By: systemd
-- Support: https://access.redhat.com/support 
--
-- Unit kdump.service has failed.
--
-- The result is failed.
Oct 19 23:18:32 my_hostname sudo: pam_unix(sudo:session): session closed for user root

cat /proc/keys outputs:

00e8d728 I--Q---    14 perm 3f030000  1002    10 keyring   _ses: 1
029d6be0 I--Q---     1 perm 1f3f0000  1002 65534 keyring   _uid_ses.1002: 1
321674d8 I--Q---    11 perm 3f030000  1002    10 keyring   _ses: 1
37bb77f9 I--Q---     3 perm 1f3f0000  1002 65534 keyring   _uid.1002: empty
3b9154f0 I--Q---     8 perm 3f030000  1002    10 keyring   _ses: 1

rpm -q kexec-tools outputs:

kexec-tools-2.0.20-14.el8.x86_64

I have been trying to debug random system freezes when running the 4.14.93-rt kernel. To this end, I have enabled the lockup detector in the kernel using the following config: CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y CONFIG_LOCKUP_DETECTOR=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR_PERF=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 The goal is to trigger a kernel panic when a lockup occurs. I also enabled the NMI watchdog on the kernel cmdline: nmi_watchdog=1 Making use of kdump/kexec tools, I have configured the system to generate a kernel crash dump on kernel panic. The mechanism works when triggering a panic manually using: echo c > /proc/sysrq-trigger I can confirm that the system loads a dump-capture kernel in that case. However, when experiencing an actual lockup, the system just reboots when the watchdog kicks in. AFAIK there is no kernel panic occuring. There is no switch to the dump-capture kernel. No core dump, nothing stored in the logs. Note that I enabled all relevant sysctl options: kernel.panic = 1 kernel.panic_on_oops = 1 kernel.unknown_nmi_panic = 1 kernel.panic_on_unrecovered_nmi = 1 kernel.panic_on_io_nmi = 1 kernel.softlockup_panic = 1 kernel.hung_task_panic = 1 I see this behavior when experiencing a real-life system freeze. It also occurs when running a CPU hogging while-loop on all cores with high RT priority. I would expect this to be detected as a hung task and lead to a panic. What could cause a reboot in this case without triggering the panic/kdump mechanism?

I'm running Arch Linux and I've set up [kdump](https://wiki.archlinux.org/index.php/Kdump) so that when the current kernel panics(or I manually induce a crash via sysrq+c) then another kernel(the kexec kernel) starts up in order to create a crash dump so that I can later inspect it. The problem is that whether this triggers from console or from within Xorg, the same screen remains on the display for the entire duration of the kexec-ed kernel and I thus cannot see what it's doing. This isn't a problem on a non-i915 laptop that's using AMD/Radeon for example. I've tried the following kernel args for the kexec kernel and they've had no effect on this issue: 1. systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 2. systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0 The full ExecStart= line that I'm currently using and has no effect is: ExecStart=/usr/bin/kexec -p /boot/vmlinuz-linux-git --initrd=/boot/initramfs-linux-git.img --reuse-cmdline --reset-vga --console-vga "--append=root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0" So when kernel panics, the X or console screen that was present at panic time will remain on the screen until the kexec kernel is done saving the dump file and reboots. When crashkernel= arg for the primary kernel is too low, the kexec kernel can OOM during makedumpfile and thus I've no idea why it didn't reboot after x minutes because I can't see its screen. I guess I need some (working)way to switch to 80x25 mode or some way to tell kexec kernel to reset the i915 video card so it can re-init it again normally? **EDIT:** not using EFI, using grub+MBR also some primary kernel info:

[    0.275493] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-git root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a rw root_trim=yes rd.luks.allow-discards rd.luks.options=discard ipv6.disable=1 ipv6.disable_ipv6=1 ipv6.autoconf=0 loglevel=15 log_buf_len=16M ignore_loglevel printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=4 memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11 net.ifnames=0 nolvm dobtrfs console=tty1 earlyprintk=vga audit=0 systemd.log_target=kmsg systemd.journald.forward_to_console=1 enforcing=0 udev.children-max=1256 rd.udev.children-max=1256 nohz=on oops=panic crashkernel=1024M panic=0 page_poison=1 psi=1 sysrq_always_enabled random.trust_cpu=off logo.nologo lpj=0 mce=bootlog reboot=force,cold noexec=on nohibernate scsi_mod.use_blk_mq=1 consoleblank=120 mitigations=off nospectre_v1 nospectre_v2 spectre_v2=off nospec_store_bypass_disable kvm-intel.vmentry_l1d_flush=never l1tf=off nopti pti=off no_stf_barrier noibrs noibpb ssbd=force-off spectre_v2_user=off noretpoline mds=off rd.log=all noefi cpuidle.governor=menu zram.num_devices=3 zswap.enabled=0 zswap.same_filled_pages_enabled=1 zswap.compressor=zstd zswap.max_pool_percent=40 zswap.zpool=z3fold vsyscall=none i915.enable_fbc=1 i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1
[    0.845622] device: 'fbcon': device_add
[    0.845626] PM: Adding info for No Bus:fbcon
...
[    4.416734] fbcon: i915drmfb (fb0) is primary device
...
[    4.494499] i915 0000:00:02.0: fb0: i915drmfb frame buffer device

Here's a cmdline word diff between primary and kexec kernel:

diff --git a/home/user/logs/pri_kernel.log b/home/user/logs/kexeckernel.log
index e6d2815..9b90a12 100644
--- a/home/user/logs/pri_kernel.log
+++ b/home/user/logs/kexeckernel.log
@@ -1,2 +1,2 @@
 [    0.000000] Command line:
-BOOT_IMAGE=/boot/vmlinuz-linux-git
  root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a rw root_trim=yes rd.luks.allow-discards rd.luks.options=discard ipv6.disable=1 ipv6.disable_ipv6=1 ipv6.autoconf=0 loglevel=15 log_buf_len=16M ignore_loglevel printk.always_kmsg_dump=y printk.time=y printk.devkmsg=on mminit_loglevel=4 memory_corruption_check=1 fbcon=scrollback:4096k fbcon=font:ProFont6x11 net.ifnames=0 nolvm dobtrfs console=tty1 earlyprintk=vga audit=0 systemd.log_target=kmsg systemd.journald.forward_to_console=1 enforcing=0 udev.children-max=1256 rd.udev.children-max=1256 nohz=on oops=panic
-crashkernel=1024M
  panic=0 page_poison=1 psi=1 sysrq_always_enabled random.trust_cpu=off logo.nologo lpj=0 mce=bootlog reboot=force,cold noexec=on nohibernate scsi_mod.use_blk_mq=1 consoleblank=120 mitigations=off nospectre_v1 nospectre_v2 spectre_v2=off nospec_store_bypass_disable kvm-intel.vmentry_l1d_flush=never l1tf=off nopti pti=off no_stf_barrier noibrs noibpb ssbd=force-off spectre_v2_user=off noretpoline mds=off rd.log=all noefi cpuidle.governor=menu zram.num_devices=3 zswap.enabled=0 zswap.same_filled_pages_enabled=1 zswap.compressor=zstd zswap.max_pool_percent=40 zswap.zpool=z3fold vsyscall=none i915.enable_fbc=1 i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 
+root=UUID=2b8b9ab8-7ac5-4586-aa42-d7ffb12de92a systemd.unit=kdump-save.service irqpoll nr_cpus=1 reset_devices ipv6.disable=1 loglevel=9 i915.fastboot=0 i915.reset=1 i915.modeset=-1 i915.force_reset_modeset_test=true i915.verbose_state_checks=1 i915.enable_hangcheck=1 i915.error_capture=1 zram.num_devices=3 zswap.enabled=0 acpi_rsdp=0xf05b0 elfcorehdr=2588032K
~
 
~

There's no mention in kexec kernel dmesg of i915 except in cmdline.

I've installed a debug kernel and enabled kdump. The coredump was generated successfully, but when I try to load the vmcore after reboot, crash command just quit without prompt: # crash /usr/lib/debug/usr/lib/modules/3.10.0-693.11.6.el7.x86_64.debug/vmlinux /var/crash/127.0.0.1-2019-05-25-22\:55\:50/vmcore crash 7.2.3-8.el7 Copyright (C) 2002-2017 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... Any ideas? Is there any way to convert vmcore file to a coredump file so that I can load it directly with gdb?

I have a VPS server on amazon's AWS Lightsail service. I've been testing kdump using the following two commands(to trigger an automatic kernel crash): # echo 1 > /proc/sys/kernel/sysrq # echo c > /proc/sysrq-trigger The problem is that the system crashed and rebooted, but there's no dump saved. Here is a list of checking I've done: [centos@server crash]$ systemctl status kdump ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled) Active: active (exited) since Mon 2019-03-18 07:43:34 UTC; 5 days ago Process: 4119 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS) Main PID: 4119 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kdump.service Mar 18 07:43:32 ip-.ap-northeast-1.compute.internal systemd: Starting Crash recovery kernel arming... Mar 18 07:43:34 ip-.ap-northeast-1.compute.internal kdumpctl: kexec: loaded kdump kernel Mar 18 07:43:34 ip-.ap-northeast-1.compute.internal kdumpctl: Starting kdump: [OK] Mar 18 07:43:34 ip-.ap-northeast-1.compute.internal systemd: Started Crash recovery kernel arming. [centos@server crash]$ dmesg | grep Reserving [ 0.000000] Reserving 256MB of memory at 368MB for crashkernel (System RAM: 2047MB) [centos@server crash]$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10.0-957.1.3.el7.x86_64 root=UUID=f41e390f-835b-4223-a9bb-9b45984ddf8d ro console=tty0 crashkernel=256M console=ttyS0,115200 [centos@server crash]$ grep -v ^# /etc/kdump.conf path /var/crash core_collector makedumpfile -l --message-level 1 -d 31 default reboot There's no log of the crash in the /var/log/messages indicating any error there might be. So I wonder what I might have missed. Or an AWS Lightsail VPS is not capable of saving a kdump at all...?

I have made a custom board using Tegra TK1 ARM processor. I have compiled uboot and kernel for it and flashed into it. Now when it starts booting, sometimes it boots successfully while sometimes kernel crashes. Everytime it crashes at different address and start dumping. Every crash occur after the kernel mounts filesystem. It never crashes before mounting filesystem. I have also tested RAM using tool provided by NVIDIA and also tested RAM using stress utility, both tests complete successfully. So it seems there is no issue with RAM. Do anyone have any idea, I am sharing some of dumps here [ 13.044646] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM [ 13.044654] Modules linked in: [ 13.044668] CPU: 0 PID: 40 Comm: khubd Tainted: G W 3.10.40 #60 [ 13.044674] task: ed53dac0 ti: ed554000 task.ti: ed554000 [ 13.044692] PC is at hub_thread+0x64/0x174 [ 13.044698] LR is at hub_thread+0x144/0x174 [ 13.044704] pc : [] lr : [] psr: 60030113 [ 13.044704] sp : ed555f38 ip : 00000000 fp : 00000000 [ 13.044706] r10: 00000000 r9 : 00000000 r8 : c008da64 [ 13.044709] r7 : c0cad044 r6 : c0d310c8 r5 : ed554000 r4 : c0cad03c [ 13.044711] r3 : 40200040 r2 : ed53dac0 r1 : 20030113 r0 : c0cad044 [ 13.044716] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 13.044719] Control: 10c5387d Table: acc6006a DAC: 00000015 [ 13.044723] [ 13.044723] PC: 0xc04c0020: [ 13.044724] 0020 c0cf6e52 c0cf6daa c0cf6e22 c0cf6dc2 c0cf6e0a c0cf6db0 c0cf6e10 e92d41f0 [ 13.044738] 0040 e24dd018 e52de004 e8bd4000 e30d403c e1a0300d e3c35d7f e34c40ca e30160c8 [ 13.044748] 0060 e30d8a64 e2847008 e3c5503f e34c60d3 e34c8008 ebefd422 ebfffd79 e595200c [ 13.044759] 0080 e5941000 e592300c e1510004 e3833101 e582300c 0a00001d e595200c e592300c [ 13.044770] 00a0 ed53edcc ed555f88 00000000 00000000 e3c33101 e582300c f57ff05f e5963000 [ 13.044781] 00c0 e3530000 1a00000e ebef324e e3500000 0affffec e5943000 e1530004 1affffe9 [ 13.044792] 00e0 e3130004 1a000026 e3a00000 e28dd018 e8bd81f0 e595000c ebefd39b e3500000 [ 13.044803] 0100 0affffec e3a00000 ebefd3b2 eaffffe9 ebef3238 e3500000 1affffde e595200c . [ 12.020636] tegra-udc tegra-udc.0: USB cable/charger disconnected [ 12.020996] otg state changed: SUSPEND --> HOST [ 12.021715] tegra USB phy - inst platform info: [ 12.021719] port_otg: yes [ 12.021722] has_hostpc: yes [ 12.021725] phy_interface: USB_PHY_INTF_UTMI [ 12.021728] op_mode: TEGRA_USB_OPMODE_HOST [ 12.021731] qc2_voltage: 0 [ 12.021734] vbus_gpio: -1 [ 12.021739] hot_plug: disabled [ 12.021743] remote_wakeup: enabled [ 12.060761] mc-err: [mcerr] (ppcs) csw_ppcsahbslvw: EMEM decode error on PDE or PTE entry [ 12.060770] mc-err: [mcerr] status = 0x6003203c; addr = 0x7c0c9880[ 12.060779] mc-err: [mcerr] ss [ 12.062219] mc-err: [mcerr] (ppcs) csw_ppcsahbslvw: EMEM decode error on PDE or PTE entry [ 12.062226] mc-err: [mcerr] status = 0x6003203c; addr = 0x7c0c9880[ 12.062231] mc-err: [mcerr] ss [ 12.065313] mc-err: [mcerr] (ppcs) csw_ppcsahbslvw: EMEM decode error on PDE or PTE entry [ 12.065320] mc-err: [mcerr] status = 0x6003203c; addr = 0x7c0c9880[ 12.065326] mc-err: [mcerr] ss [ 12.065913] mc-err: [mcerr] (ppcs) csw_ppcsahbslvw: EMEM decode error on PDE or PTE entry [ 12.065919] mc-err: [mcerr] status = 0x6003203c; addr = 0x7c0c9880[ 12.065925] mc-err: [mcerr] ss [ 12.071274] Unable to handle kernel paging request at virtual address 00043884 [ 12.071280] pgd = ec534000 [ 12.071284] *pgd=ac4b0831, *pte=00000000, *ppte=00000000 [ 12.071305] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 12.071311] Modules linked in: [ 12.071325] CPU: 1 PID: 262 Comm: nvfb.sh Tainted: G W 3.10.40 #60 [ 12.071331] task: eca0ea80 ti: ec4a2000 task.ti: ec4a2000 [ 12.071351] PC is at part_round_stats_single+0x58/0x7c [ 12.071356] LR is at 0x1 [ 12.071364] pc : [] lr : [] psr: 00000113 [ 12.071364] sp : ec4a3c30 ip : fffb9b22 fp : c01bce5c [ 12.071368] r10: ece39e34 r9 : 00000003 r8 : ed06c400 [ 12.071373] r7 : 00000001 r6 : fffb9b27 r5 : 00000001 r4 : 0000010a [ 12.071377] r3 : 00043860 r2 : fffb9b27 r1 : ed0a4c40 r0 : 0125d000 [ 12.071386] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 12.071392] Control: 10c5387d Table: ac53406a DAC: 00000015 [ 12.071398] [ 12.071398] PC: 0xc029a1cc: [ 12.071402] a1cc e3a06000 eafffff5 c0d6f168 e52de004 e8bd4000 e590305c e5930214 e3500000 [ 12.071429] a1ec 128000d0 e12fff1e e92d4070 e52de004 e8bd4000 e591c1b0 e15c0002 08bd8070 [ 12.071456] a20c e59131b4 e591e1b8 e173000e 0a000012 e30a44e8 e59131bc e34c40bd e591e1b4 [ 12.071482] a22c e7940100 e042c00c e59151b8 e0833000 e5934024 e042c00c e59151b8 e0833000 [ 12.071506] a24c e5934024 e08ee005 e02c4e9c e583c024 e59131bc e080000c e5830020 e58121b0 [ 12.071532] a26c e8bd8070 e52de004 e8bd4000 e5903020 e1a01000 e590001c e3c33702 e5813020 [ 12.071558] a28c e590305c e3530000 012fff1e e12fff13 e52de004 e8bd4000 e5903070 e3530000 [ 12.071585] a2ac 0a000000 e12fff13 e1a00003 e12fff1e e52de004 e8bd4000 e1a0300d e307136 . [ 11.059198] systemd-udevd: starting version 215 [ 11.072135] systemd: Mounting /mnt/ramdisk... [ 11.086343] systemd: Starting Syslog Socket. [ 11.097780] systemd: Listening on Syslog Socket. [ 11.105728] systemd: Starting Sockets. [ 11.115019] systemd: Reached target Sockets. [ 11.122357] systemd: Starting Journal Service... [ 11.140562] systemd: Started Journal Service. [ 11.551550] systemd-journald: Received request to flush runtime journal1 [ 11.862564] Tegra cpuquiet clusterswitch enabled [ 11.882266] * [ 11.898914] -[ 11.936666] otg state changed: PERIPHERAL --> SUSPEND [ 11.936836] tegra-udc tegra-udc.0: USB cable/charger disconnected [ 11.937227] otg state changed: SUSPEND --> HOST [ 11.938022] tegra USB phy - inst platform info: [ 11.938029] port_otg: yes [ 11.938036] has_hostpc: yes [ 11.938042] phy_interface: USB_PHY_INTF_UTMI [ 11.938048] op_mode: TEGRA_USB_OPMODE_HOST [ 11.938055] qc2_voltage: 0 [ 11.938061] vbus_gpio: -1 [ 11.938068] hot_plug: disabled [ 11.938074] remote_wakeup: enabled [ 11.993244] *[ 12.147798] as3722-adc-extcon as3722-adc-extcon.2: USB-Host d [ 12.281049] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMPM [ 12.292012] Modules linked in: [ 12.298540] CPU: 0 PID: 309 Comm: cpufreq-set Tainted: G W 3.10.400 [ 12.309143] task: ec953ac0 ti: ec582000 task.ti: ec582000 [ 12.316158] PC is at 0xec583d40 [ 12.320913] LR is at tegra_update_cpu_speed+0x128/0x2f0 [ 12.327804] pc : [] lr : [] psr: 80000013 [ 12.327804] sp : ec583d08 ip : 00000000 fp : ed6bdd80 [ 12.342746] r10: c1df5568 r9 : 00000000 r8 : 001f845c [ 12.349718] r7 : c004b6e0 r6 : 001f845c r5 : 000a9ec0 r4 : 00000000 [ 12.358037] r3 : 00000004 r2 : 00000000 r1 : c1dfd37a r0 : 00000000 [ 12.366367] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 12.375367] Control: 10c5387d Table: ac8e006a DAC: 00000015 [ 12.383008] [ 12.383008] PC: 0xec583cc0: [ 12.390900] 3cc0 00000000 c1dfd37a 00000000 00000004 00000000 000a9ec0 001f0 [ 12.403102] 3ce0 001f845c 00000000 c1df5568 ed6bdd80 00000000 ec583d08 c0040 [ 12.415515] 3d00 80000013 ffffffff 001f845c 00000001 c0cee138 c004b758 c0d00 [ 12.428162] 3d20 ed6bdd80 c004bd3c ec583d30 00000002 00000014 001f845c 00004 [ 12.440884] 3d40 001f845c edaf2ac0 001f845c c05a73a0 00000003 ed6bdd80 00001 [ 12.453901] 3d60 c0ba1568 00000004 00000064 edaf2ac0 c0bd9cbc ed6bdd80 00008 [ 12.467055] 3d80 00000000 c05aff80 00000000 c1e10568 edaf2b80 c0b9fa78 c0bd0 [ 12.480321] 3da0 00bae062 00000000 c0bd9cbc c1df55d8 edaf2ac0 ed6bdd80 edaf8 [ 12.493747] [ 12.493747] LR: 0xc004b13c: [ 12.502907] b13c 0a000060 e596300c e3530002 0a000009 e30632b0 e3a01002 e34c0 [ 12.516329] b15c ebffa872 e2508000 1a00004f e59d0008 e3a03002 e586300c e59d0 [ 12.529856] b17c e1530000 0a00003a e1500003 8a000051 e30b3760 e3e02000 e34c0 [ 12.543566] b19c e3094cbc e5935000 e5282010 e34c40bd ea000003 e3a01000 e1a0f [ 12.557385] b1bc e59d2000 e2822001 e3a01004 e1a00005 eb098793 e5943000 e58d0 [ 12.571207] b1dc 8afffff3 e59d3008 e3a01ffa e5960024 e0010391 ebff75a9 e2500 [ 12.585024] b1fc 028d8010 05282010 0a000004 ea000053 e3a01001 e1a00008 eb150 [ 12.598840] b21c e2822001 e3a01004 e1a00005 eb09 Thanks

I'm trying to enable kdump on a server but in the grub configuration file, there are two entries for the crashkernel parameter for each OS entry. I know that this parameter is used to allocate memory to the crash kernel. I'm trying to understand what is the significance of having two entries for the crashkernel parameter in grub.conf. #splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.32-754.6.3.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-754.6.3.el6.x86_64 ro root=/dev/VG01/LV_ROOT LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto crashkernel=auto initrd /initramfs-2.6.32-754.6.3.el6.x86_64.img title Red Hat Enterprise Linux Server (2.6.32-696.30.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-696.30.1.el6.x86_64 ro root=/dev/VG01/LV_ROOT LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto crashkernel=auto initrd /initramfs-2.6.32-696.30.1.el6.x86_64.img title Red Hat Enterprise Linux Server (2.6.32-642.13.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-642.13.1.el6.x86_64 ro root=/dev/VG01/LV_ROOT LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto crashkernel=auto initrd /initramfs-2.6.32-642.13.1.el6.x86_64.img

Issue: SERVER:~ # systemctl start kdump.service Job for kdump.service failed because the control process exited with error code. See "systemctl status kdump.service" and "journalctl -xe" for details. SERVER:~ # systemctl status kdump.service ● kdump.service - Load kdump kernel on startup Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2018-10-17 12:29:34 EDT; 1s ago Process: 59804 ExecStart=/lib/kdump/load.sh (code=exited, status=1/FAILURE) Main PID: 59804 (code=exited, status=1/FAILURE) Oct 17 12:29:33 SERVER systemd: Starting Load kdump kernel on startup... Oct 17 12:29:34 SERVER load.sh: kexec_file_load failed: Cannot assign requested address Oct 17 12:29:34 SERVER systemd: kdump.service: Main process exited, code=exited, status=1/FAILURE Oct 17 12:29:34 SERVER systemd: Failed to start Load kdump kernel on startup. Oct 17 12:29:34 SERVER systemd: kdump.service: Unit entered failed state. Oct 17 12:29:34 SERVER systemd: kdump.service: Failed with result 'exit-code'. SERVER:~ # Logs: SERVER:~ # tail /var/log/messages 2018-10-17T12:29:33.980232-04:00 SERVER systemd: Starting Load kdump kernel on startup... 2018-10-17T12:29:34.133151-04:00 SERVER kdump: FAILED to load kdump kernel: /sbin/kexec -p /boot/vmlinuz-4.4.121-92.80-default --append="quiet console=tty0 console=ttyS0,9600 elevator=noop transparent_hugepage=never numa_balancing=disable intel_idle.max_cstate=1 elevator=deadline sysrq=yes reset_devices acpi_no_memhotplug cgroup_disable=memory irqpoll nr_cpus=1 root=kdump rootflags=bind rd.udev.children-max=8 disable_cpu_apicid=0 panic=1" --initrd=/boot/initrd-4.4.121-92.80-default-kdump -s, Result: kexec_file_load failed: Cannot assign requested address 2018-10-17T12:29:34.133560-04:00 SERVER load.sh: kexec_file_load failed: Cannot assign requested address 2018-10-17T12:29:34.133726-04:00 SERVER systemd: kdump.service: Main process exited, code=exited, status=1/FAILURE 2018-10-17T12:29:34.133958-04:00 SERVER systemd: Failed to start Load kdump kernel on startup. 2018-10-17T12:29:34.134105-04:00 SERVER systemd: kdump.service: Unit entered failed state. 2018-10-17T12:29:34.134233-04:00 SERVER systemd: kdump.service: Failed with result 'exit-code'. SERVER:~ # Infos for the versions: SERVER:~ # rpm -qa|grep -i kdump yast2-kdump-3.1.44-11.6.15.x86_64 kdump-0.8.15-28.5.x86_64 SERVER:~ # uname -a Linux SERVER 4.4.121-92.80-default #1 SMP Mon May 21 14:40:10 UTC 2018 (2afdd00) x86_64 x86_64 x86_64 GNU/Linux SERVER:~ # SERVER:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 12 (x86_64) VERSION = 12 PATCHLEVEL = 2 # This file is deprecated and will be removed in a future service pack or release. # Please check /etc/os-release for details about this release. SERVER:~ # **The question:** Why cannot the kdump.service start? What am I missing? AFAIK SLES 12 doesn't needs the kernel-kdump package or am I wrong? If yes, from where can I get the kernel-kdump package? Based on https://distrowatch.com/table-mobile.php?distribution=sle&pkglist=true&version=12-sp2 the kdump version looks OK. UPDATE on 2018 Dec 05: - rpm -V kdump-0.8.15-28.5.x86_64; echo $? -> it is 0, so ok - I found a machine with same kernel version, but there, kdump works! But cannot find the difference between healthy vs. this bad host.. - tried to replace initrd, but didn't helped. - tried to reinstall kdump, didn't helped: rpm -e yast2-kdump; rpm -e kdump; zypper in kdump - tried to do a "systemctl unmask kdump; systemctl enable kdump; systemctl restart kdump" and "systemctl daemon-reload", didn't helped. UPDATE on 2018 Dec 07: cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.4.121-92.80-default root=/dev/mapper/vg00-lv_root splash=silent quiet showopts console=tty0 console=ttyS0,9600 elevator=noop transparent_hugepage=never crashkernel=768M numa_balancing=disable intel_idle.max_cstate=1 UPDATE on 2018 Dec 11: posting /proc/iomem from a node that cannot start kdump: SERVER:~ # cat /proc/iomem 00000000-00000fff : reserved 00001000-0009bfff : System RAM 0009c000-0009ffff : reserved 000a0000-000bffff : PCI Bus 0000:00 000c0000-000c7fff : Video ROM 000cd800-000d53ff : Adapter ROM 000e0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-5eeb0fff : System RAM 01000000-015fbb30 : Kernel code 015fbb31-01d59b7f : Kernel data 01f6b000-021e8fff : Kernel bss 5eeb1000-66eb8fff : reserved 66eb9000-6a733fff : System RAM 6a734000-6a742fff : reserved 6a743000-6a743fff : System RAM 6a744000-7a7c4fff : reserved 7a7c5000-7cc82fff : System RAM 7cc83000-7ccb4fff : reserved 7ccb5000-a41b7fff : System RAM a41b8000-b93fefff : reserved b93ff000-bb3fefff : ACPI Non-volatile Storage bb3ff000-bb7fefff : ACPI Tables bb7ff000-bb7fffff : System RAM bb800000-cfffffff : reserved c0000000-cfffffff : PCI MMCONFIG 0000 [bus 00-ff] d0000000-e7ffbfff : PCI Bus 0000:00 d0000000-d01fffff : PCI Bus 0000:06 d0000000-d00fffff : 0000:06:00.0 d0100000-d01fffff : 0000:06:00.1 d0200000-d020ffff : 0000:00:11.0 d03fc000-d03fcfff : 0000:00:05.4 d03fe000-d03fe3ff : 0000:00:1a.0 d03fe000-d03fe3ff : ehci_hcd d03ff000-d03ff3ff : 0000:00:1d.0 d03ff000-d03ff3ff : ehci_hcd d0400000-d05fffff : PCI Bus 0000:0b d04f0000-d04fffff : 0000:0b:00.0 d04f0000-d04fffff : megasas: LSI d0500000-d05fffff : 0000:0b:00.0 d0600000-d0ffffff : PCI Bus 0000:11 d0600000-d0ffffff : PCI Bus 0000:12 d0600000-d06fffff : PCI Bus 0000:15 d06fe000-d06fefff : 0000:15:00.0 d06ff000-d06fffff : 0000:15:00.0 d0700000-d0ffffff : PCI Bus 0000:13 d0700000-d0ffffff : PCI Bus 0000:14 d07fc000-d07fffff : 0000:14:00.0 d07fc000-d07fffff : mgadrmfb_mmio d0800000-d0ffffff : 0000:14:00.0 d1000000-d1ffffff : PCI Bus 0000:11 d1000000-d1ffffff : PCI Bus 0000:12 d1000000-d1ffffff : PCI Bus 0000:13 d1000000-d1ffffff : PCI Bus 0000:14 d1000000-d1ffffff : 0000:14:00.0 d1000000-d1ffffff : mgadrmfb_vram d2000000-d5ffffff : PCI Bus 0000:06 d2000000-d3ffffff : 0000:06:00.0 d2000000-d3ffffff : mlx5_core d4000000-d5ffffff : 0000:06:00.1 d4000000-d5ffffff : mlx5_core e7ffc000-e7ffcfff : dmar1 e8000000-fbffbfff : PCI Bus 0000:80 e8000000-e81fffff : PCI Bus 0000:81 e8000000-e80fffff : 0000:81:00.0 e8100000-e81fffff : 0000:81:00.1 e9fff000-e9ffffff : 0000:80:05.4 ea000000-edffffff : PCI Bus 0000:81 ea000000-ebffffff : 0000:81:00.0 ea000000-ebffffff : mlx5_core ec000000-edffffff : 0000:81:00.1 ec000000-edffffff : mlx5_core fbffc000-fbffcfff : dmar0 fec00000-fecfffff : PNP0003:00 fec00000-fec003ff : IOAPIC 0 fec01000-fec013ff : IOAPIC 1 fec40000-fec403ff : IOAPIC 2 fed00000-fed003ff : HPET 0 fed00000-fed003ff : PNP0103:00 fed12000-fed1200f : pnp 00:01 fed12010-fed1201f : pnp 00:01 fed1b000-fed1bfff : pnp 00:01 fed1c000-fed1ffff : reserved fed1f410-fed1f414 : iTCO_wdt.0.auto fed45000-fed8bfff : pnp 00:01 fee00000-feefffff : pnp 00:01 fee00000-fee00fff : Local APIC ff000000-ffffffff : reserved ff000000-ffffffff : pnp 00:01 100000000-1003fffffff : System RAM 38000000000-3bfffffffff : PCI Bus 0000:00 38000000000-38000000fff : 0000:00:1f.6 3800000c000-3800000c00f : 0000:00:16.0 3800000d000-3800000d00f : 0000:00:16.1 3800000e000-3800000e0ff : 0000:00:1f.3 38000010000-3800001ffff : 0000:00:14.0 38000010000-3800001ffff : xhci-hcd 3c000000000-3ffffffffff : PCI Bus 0000:80 SERVER:~ #

I have read about the kexec/kdump facilities, we know that crashed/panic'ed kernel is made available via /proc/vmcore. I have heard people use kexec based booting to bypass EFI/BIOS/FW initialization stages to speed up their OS patching activities on production machines. This implies that those machines continue using the capture kernels for the rest of their processing/uptime. I could not find a clear mention of capture kernel's ability to reclaim the old memory areas that have been preserved for taking a kdump. Can the capture kernel discard those preserved memory contents after the dump has been saved? It's true that the capture kernel would be running from a "non-standard" memory location due to it being a "relocatable" kernel, but can it utilize/free up all other memory and continue to be used as the main kernel for production uses?

On my RHEL7.4 VM, in /etc/kdump.conf I have set the path /var/myorg/myhost. In /etc/sysctl.conf kernel.core_pattern = core.%e.%p.%h.%t. The generated vmcore name is not as mentioned in core_pattern but it's location and name as /var/myorg/myhost/127.0.0.1-2018-10-31-15:11:12/vmcore. Why does the vmcore name has no effect of kernel.core_pattern?

I am trying to start a crash kernel using Linux's Kernel Crash Dump. Both of the host and crash kernel are compiled linux-4.13.16 kernel. Unfortunately, the crash kernel fails to start after the crash occurs. iomem reports reserved space for crash kernel and kdump reports its ready for kdump: > 28000000-37ffffff : Crash kernel $ sudo kdump-config show DUMP_MODE: kdump USE_KDUMP: 1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR: /var/crash crashkernel addr: 0x28000000 /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.13.16ksa kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.13.16ksa current state: ready to kdump kexec command: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.13.16ksa root=UUID=3254c608-d885-4dfc-b20b-fa4e69564dca ro quiet splash vt.handoff=7 irqpoll noirqdistrib nr_cpus=1 nousb systemd.unit=kdump-tools.service" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.13.16ksa root=UUID=3254c608-d885-4dfc-b20b-fa4e69564dca ro quiet splash crashkernel=384M-2G:128M,2G-:256M vt.handoff=7 After triggering crash using sysrq-trigger, it doesn't load crash kernel. I have tested with a generic kernel, linux-4.8.0-36-generic, which successfully works. Syslog file are here . Both linux-4.8.0-36-generic and linux-4.13.16ksa has same .config file. Only difference I can see is that during boot, for linux-4.13.0-38, it loads the efi.signed vmlinuz(vmlinuz-4.13.0-38-generic.efi.signed) where as the compiled linux-4.13.16ksa is not efi signed. Can it be an issue? How can I resolve this?

I need to get a crash dump of my linux kernel. I am going to describe the scenario: 1. Hardware: Notebook Dell E5450. 2. Linux Distribution: Linux Mint 18.3 (Ubuntu 16.04). 3. SysRq: enabled by /etc/sysctl.d/10-magic-sysrq.conf. 4. Installed packages: linux-crashdump. 5. Grub2: added "crashkernel=384M-2G:64M,2G-:128M" 6. Kdump check: "kdump-config show" reports a working configuration. 7. File system: folder "/var/crash" exists. When I press "Alt+PrnScr+C" the system freezes without reboot and does not save any dump into /var/crash. Same thing sending "echo c | sudo tee /proc/sysrq-trigger". How could I fix this situation? Thank you so much!

After installing kdump-related packages and yet another hang, I now have a: /var/crash/kexec_cmd file. But what can I do with it? Should I use the command-line crash utility? I tried to, but it wanted my kernel file and didn't accept /vmlinuz. Is there other something else I can/should use?