This bug was fixed in the package kexec-tools - 1:2.0.10-1ubuntu2.5 --------------- kexec-tools (1:2.0.10-1ubuntu2.5) xenial; urgency=medium
* The default crashkernel parameter didn't work on any known arm64 systems, set a reasonable default instead (LP: #1763532). -- dann frazier <dann.fraz...@canonical.com> Fri, 13 Apr 2018 17:50:27 -0600 ** Changed in: kexec-tools (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/1763532 Title: set reasonable default cmdlines for arm64 Status in kexec-tools package in Ubuntu: Fix Released Status in makedumpfile package in Ubuntu: Fix Released Status in kexec-tools source package in Xenial: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in kexec-tools source package in Artful: Invalid Status in makedumpfile source package in Artful: Fix Released Status in makedumpfile package in Debian: Fix Released Bug description: [Impact] Crash dump support doesn't work by default on any known arm64 platform. Users have to figure out working incantations for the crashkernel= parameter and the parameters passed to the crash-dump kernel themselves and manual edit 2 different config files. *NOTE* one of these config files moved from kexec-tools to kdump-tools between xenial & artful - that's why kexec-tools is only updated for xenial. *NOTE* the debdiffs here are large because a few files have been renamed to "*.in" so they can be used as templates for generating per- architecture files at build time. [Test Case] Using either a Centriq 2400 or a Cavium ThunderX CRB (these platforms are known to support crashdump), and with a kernel >= 4.13 (xenial-ga did not support crashdump on arm64): sudo apt install kdump-tools (reboot, so crashkernel= is added to the kernel commandline) echo c | sudo tee /proc/sysrq-trigger Without having to edit any config files, crash dump should occur, with artifacts collected in /var/crash. If you want to verify that the dump is usable, install the corresponding linux-image-<ver>-dbgsym package and run: sudo crash /usr/lib/debug/boot/vmlinux-<ver> /var/crash/<crash>/dump.<crash> crash should successfully load, placing you at a "crash>" prompt. At that prompt, you can issue the 'bt' command to see a backtrace. Note: you need crash from zesty (7.1.8-1ubuntu1) or later. [Regression Risk] The biggest regression risk I see here is that we're introducing build-time mechanisms for generating config files per-architecture, and bugs in that implementation could lead to incorrect settings for non-arm64 architectures. To validate that, I've staged these update in a PPA (ppa:dannf/arm64-kdump), and I extracted those debs in a directory next to the current debs and diff'd the two trees[1]. Ignoring binary files, diff shows that only config files in the arm64 build are different, as intended. Note that, while this config file generation also exists in bionic, I modified it for these backports so that it retains the parameter order from the previous xenial/artful builds. This is so that the config files for non-arm64 architectures will be identical to the previous builds, and dpkg won't unnecessarily prompt admins to resolve conflicts if they've customized them. [1] $ for arch in amd64 arm64 armhf i386 ppc64el s390x; do diff -u0 -rpN ${arch}-cur ${arch}-new | grep -v ^Binary done To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1763532/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp