0

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[1]: Starting Load kdump kernel on startup...
Oct 17 12:29:34 SERVER load.sh[59804]: kexec_file_load failed: Cannot assign requested address
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 17 12:29:34 SERVER systemd[1]: Failed to start Load kdump kernel on startup.
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Unit entered failed state.
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Failed with result 'exit-code'.
SERVER:~ # 

Logs:

SERVER:~ # tail /var/log/messages
2018-10-17T12:29:33.980232-04:00 SERVER systemd[1]: Starting Load kdump kernel on startup...
2018-10-17T12:29:34.133151-04:00 SERVER kdump[59974]: 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[59804]: kexec_file_load failed: Cannot assign requested address
2018-10-17T12:29:34.133726-04:00 SERVER systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
2018-10-17T12:29:34.133958-04:00 SERVER systemd[1]: Failed to start Load kdump kernel on startup.
2018-10-17T12:29:34.134105-04:00 SERVER systemd[1]: kdump.service: Unit entered failed state.
2018-10-17T12:29:34.134233-04:00 SERVER systemd[1]: 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:~ #
1

Let me answer as best as I can with the provided information.

First, SLES 12 (and beyond) indeed does not need a kernel-kdump package. This special kernel flavour was only needed in ancient times, because the panic kernel must be loaded at a different physical address than the running kernel, but the load address could be changed only at compile time (aka the kernel was not relocatable).

Second, kdump won't start, because the underlying kexec_file_load system call fails with EADDRNOTAVAIL. This happens if the system cannot allocate one or more buffers needed to load the panic kernel into RAM. Note that there may be theoretically enough reserved memory for the panic kernel, but since the allocation has some additional constraints imposed by the Linux kernel boot code and/or drivers, this RAM may not be usable for loading the panic kernel. The other system may be more lucky thanks to a different physical memory layout.

As a first step, I would try increasing the reserved memory size on the kernel command line (e.g. crashkernel=256M), reboot and see if it helps.

  • wow, thanks :) The current setting is crashkernel=768M but kdump still doesn't wants to start. Could a reboot help on the kdump? Or could a future kernel update help on the kdump? – KollarA Dec 7 '18 at 11:07
  • I'm not sure I understand your question regarding reboot. Of course, a reboot is always needed to change kernel parameters, so if you run with an increased crashkernel= reservation, then you have rebooted already, haven't you? – Petr Tesařík Dec 8 '18 at 13:03
  • Reboot was already done, thats why the crashkernel=768M is in the /proc/cmdline, ok. – KollarA Dec 10 '18 at 16:18
  • So even with crashkernel=768M (and a reboot) it still doesn't starts. Maybe crashkernel=auto would help? And what about if there will be later newer kernels? Would that fix the kdump issue? - Many thanks for the infos already provided! :) – KollarA Dec 10 '18 at 16:19
  • All right, it seems it isn't the amount of space, but rather its placement in RAM. Would you mind posting the output of cat /proc/iomem on your system? – Petr Tesařík Dec 11 '18 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.